Revendications

Les revendications sont traitées d’abord dans la méthode d’authentification puis dans l’enregistrement 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’enregistrement 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’enregistrement d’application. Il en va de même pour les transformations de revendications et la configuration des revendications à émettre à l’application / l’API.

Pour les valeurs utilisées dans FoxIDs, choisissez _local: pour un ensemble de transformations, _internal: pour le flux d’authentification actuel, y compris les transformations d’application, ou _session: pour les connexions ultérieures par navigateur via la même méthode. Ces claims réservés ne sont pas émis aux applications. Consultez Claims locaux, internes et de session, notamment pour copier une valeur de session vers un claim interne utilisable par les transformations d’application.

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.

Les revendications suivantes identifient la dernière méthode d’authentification utilisée. Elles sont transmises par défaut et peuvent être lues dans l’enregistrement d’application et utilisées dans des transformations de revendications et des tâches de revendications :

auth_method contient le nom de la méthode d’authentification, qui est unique dans l’environnement.
auth_method_type contient le type de méthode d’authentification : login, oidc, oauth2, saml2, wsfed, env_link ou ext_login.
auth_profile_method contient le nom du profil de méthode d’authentification sélectionné. Cette revendication est incluse lorsqu’un profil est utilisé.

Une revendication sub et les jetons reçus d’un fournisseur d’identité externe sont imbriqués avec un symbole pipe (|) après le nom de la méthode d’authentification. 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
Si l’OpenID Provider externe retourne un refresh token, il peut être transféré dans la revendication refresh_token avec la valeur imbriquée the-auth-method|refresh-token-value

Enregistrement d’application

Dans un enregistrement 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.

Un enregistrement 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.

Un enregistrement 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. Un enregistrement 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.

Types des valeurs de claims

Les types des valeurs de claims JWT, notamment les objets JSON, tableaux, booléens et nombres, sont conservés lorsque les claims sont copiés par une transformation Map ou transitent par les sessions, Extended UI et les grants OAuth. OpenID Connect UserInfo renvoie ces valeurs avec leurs types JSON correspondants.

Les transformations qui produisent du nouveau texte, telles que le mappage regex et la concaténation, produisent des chaînes de caractères.

Le mappage de claims JWT/SAML préserve les types tels que les booléens et les nombres. Lors du mappage de JWT vers SAML, les valeurs JSON sont transmises sous forme de texte dans des attributs de chaîne. Lors du mappage de SAML vers JWT, les chaînes contenant des objets ou tableaux JSON valides deviennent des claims JSON.

Identités impersonées

Une méthode d’authentification peut sélectionner un autre utilisateur avec une transformation Impersonation. Les transformations de l’application reçoivent alors les claims de la cible et un claim act identifiant l’utilisateur authentifié d’origine. Les claims _impersonate: préparent la sélection dans les transformations de la méthode d’authentification ; les claims auxiliaires locaux conservent leurs noms réservés sous ce préfixe.

Dans les JWT, act est un objet JSON, par exemple {"sub":"original-user"}. Son mappage SAML par défaut est http://schemas.foxids.com/ws/identity/claims/act, modifiable dans les mappages de claims de l’environnement. Sélectionnez le claim mappé dans Issue claims de l’application SAML, ou utilisez *, pour émettre son texte JSON. Lorsqu’un attribut SAML contenant ce texte JSON est remappé vers act, FoxIDs l’émet comme objet JSON dans le JWT.

Revendications protégées

FoxIDs gère les revendications qui contrôlent les sessions, la validité des jetons et le routage entre les méthodes d’authentification. Ces revendications protégées ne peuvent pas être configurées comme sorties de transformations de revendications, utilisées dans des mappages personnalisés de revendications JWT/SAML ou associées à des valeurs statiques.

Les noms des revendications JWT protégées sont :

sid, iss, aud, exp, nbf, iat et auth_time.
client_id, azp, scope, nonce, at_hash et c_hash.
auth_method, auth_method_type, auth_profile_method et auth_method_issuer.

Les types de revendications SAML correspondants pour l’index de session, l’instant d’authentification, l’identifiant du client et la méthode d’authentification sont également protégés. Les mappages de protocoles intégrés à FoxIDs restent disponibles.

Les transformations peuvent lire les revendications protégées et copier leurs valeurs dans des revendications personnalisées. Une revendication protégée peut également être sélectionnée dans une liste de revendications à transmettre ou à émettre, sans fournir de valeurs statiques.

Les mêmes restrictions s’appliquent aux revendications personnalisées des utilisateurs internes et externes, aux revendications initiales de l’utilisateur du locataire, aux revendications des nœuds de la structure d’accès, aux revendications de sortie de l’interface utilisateur dynamique ainsi qu’aux revendications statiques des applications et des scopes.

Les revendications protégées renvoyées par une Claims API, une API de validation Extended UI, une External Login API ou une Directory Connector API sont supprimées. Les revendications protégées existantes dans le flux sont conservées. Les revendications protégées sélectionnées peuvent être envoyées à ces API en entrée.