Revendications

Les revendications sont traitées d’abord dans la méthode d’authentification puis dans l’inscription d’application, où il est possible de décider quelles revendications sont transmises à l’étape suivante et d’effectuer des transformations de revendications et des tâches de revendications.

Toutes les comparaisons de revendications sont sensibles à la casse.

Le processus des revendications démarre dans la méthode d’authentification lorsqu’un utilisateur s’authentifie. Il est possible d’y effectuer des transformations de revendications et des tâches de revendications et de configurer quelles revendications doivent être transmises à l’étape suivante. Ensuite, le processus des revendications se poursuit dans l’inscription d’application où il est également possible d’effectuer des transformations de revendications et de configurer quelles revendications doivent être émises à l’application / l’API.

Dans un scénario Client Credentials Grant, le processus des revendications n’est réalisé que dans l’inscription d’application. Il en va de même pour les transformations de revendications et la configuration des revendications à émettre à l’application / l’API.

Méthode d’authentification

Dans une méthode d’authentification OpenID Connect ou SAML 2.0, les revendications sont transmises en les ajoutant à la liste Forward claims. Toutes les revendications sont transmises si un joker * est ajouté à la liste Forward claims.

Une méthode d’authentification émet deux revendications qui peuvent être lues dans l’inscription d’application et utilisées dans des transformations de revendications et des tâches de revendications. Les revendications s’appliquent toujours à la dernière méthode d’authentification.
Revendications émises par la méthode d’authentification (transmission par défaut) :

• auth_method contient le nom de la méthode d’authentification, le nom est unique dans un environnement.
• auth_method_type contient le type de méthode d’authentification : login, oidc, oauth2, saml2 ou env_link.

Une revendication sub et un jeton d’accès reçus d’un fournisseur d’identité externe sont imbriqués avec un symbole pipe (|) après le nom de l’up_party.
Exemples :

• Un sub externe avec la valeur afeda2a3-c08b-4bbb-ab77-35138dd2ef2d obtient la valeur imbriquée the-auth-method|afeda2a3-c08b-4bbb-ab77-35138dd2ef2d
• Un jeton d’accès externe avec la valeur eyJhG.cRwczov...nNjb3B.lIjoi est ajouté dans la revendication access_token avec la valeur imbriquée the-auth-method|eyJhG.cRwczov...nNjb3B.lIjoi

Inscription d’application

Dans une inscription d’application OpenID Connect, OAuth 2.0 ou SAML 2.0, les revendications sont émises à l’application / l’API en les ajoutant à la liste Issue claims. Toutes les revendications sont émises à l’application / l’API si un joker * est ajouté à la liste Issue claims.

Une inscription d’application OpenID Connect peut différencier si une revendication est émise uniquement dans le jeton d’accès ou aussi dans le jeton d’ID.

Une inscription d’application OpenID Connect et OAuth 2.0 peut également transmettre des revendications via un scope. Cela se fait en ajoutant la ou les revendications à la liste Voluntary claims d’un scope. Les revendications sont alors émises si l’application cliente demande ce scope.
Une inscription d’application OpenID Connect peut aussi, dans les revendications de scope volontaire, différencier si une revendication est émise uniquement dans le jeton d’accès ou aussi dans le jeton d’ID.