Configuration des demandes renvoyées par le noeud final UserInfo

Vous pouvez configurer le fournisseur OpenID Connect Liberty afin de personnaliser les demandes qui sont renvoyées par le noeud final UserInfo.

Pourquoi et quand exécuter cette tâche

Vous pouvez configurer les demandes qui sont renvoyées par le fournisseur OpenID Connect d'un serveur Liberty en utilisant les sous-éléments scopeToClaimMap et claimToUserRegistryMap de l'élément openidConnectProvider dans le fichier server.xml.

Le noeud final UserInfo OpenID Connect accepte un jeton d'accès en entrée et renvoie un ensemble de demandes concernant l'utilisateur pour lequel le jeton d'accès a été crée. Les demandes qui sont renvoyées sont déterminées par :
  1. Les portées dans le jeton d'accès

    UN jeton d'accès peut avoir plusieurs portées. Les portées dans un jeton d'accès sont les portées qui sont fournies dans l'appel du noeud final d'autorisation qui a créé le jeton d'accès.

  2. Les demandes qui sont associées aux portées

    Chaque portée peut avoir plusieurs demandes qui lui sont associées.

  3. Les propriétés de référentiel fédéré qui sont associées à la demande

    Une demande peut avoir une seule propriété de référentiel fédéré qui lui est associée.

  4. Les attributs de registre d'utilisateurs qui sont associés aux propriétés du référentiel fédéré

    Une propriété de référentiel fédéré peut avoir un seul attribut de registre d'utilisateurs qui lui est associé.

Remarque : Le seul type de registre d'utilisateurs qui prend en charge l'extraction des demandes UserInfo est LDAP.

Liberty définit les portées par défaut, les demandes, les propriétés de registre fédéré et les mappages par défaut.

Tableau 1. Mappages par défaut pour les portées, les demandes et les propriétés de registre fédéré
Portée Demandes Propriété de registre fédéré
profil name, given_name, picture displayName, givenName, photoURL
courrier électronique email mail
address address postalAddress
téléphone phone_number telephoneNumber

Chacune des étapes ci-après est facultative. Le serveur Liberty définit les portées par défaut, les demandes, les propriétés de registre fédéré et les mappages par défaut. Vous ne devez suivre ces étapes que lorsque vous voulez modifier un mappage par défaut ou définir un portée ou une demande personnalisée.

Procédure

  1. Configurez les demandes qui sont associées aux portées. Une portée peut être mappée à plusieurs demandes, et plusieurs demandes peuvent être séparées par des virgules.
    Dans l'exemple ci-après, la portée CUSTOM_SCOPE1 est associée à deux demandes, CUSTOM_CLAIM1 et language, et la portée CUSTOM_SCOPE2 est associée à la demande CUSTOM_CLAIM2.
    <scopeToClaimMap CUSTOM_SCOPE1="CUSTOM_CLAIM1, language"
                     CUSTOM_SCOPE2="CUSTOM_CLAIM2" />
    Remarque : Les noms de demande et de portée sont sensibles à la casse, CUSTOM_SCOPE1 et custom_scope1 sont des portées différentes.
    1. Pour définir des portées portant le même nom mais dans une casse différente, vous devez utiliser le sous-élément property. Dans l'exemple ci-après, les portées CUSTOM_SCOPE1 et custom_scope1 sont définies.
      <scopeToClaimMap CUSTOM_SCOPE1="CUSTOM_CLAIM1, language" > 
          <property name="custom_scope1" value="custom_claim1,mobile"/> 
      </scopeToClaimMap>
  2. Configurez les propriétés de référentiel fédéré qui sont associées aux demandes. Une demande ne peut être mappée qu'à une seule propriété de référentiel fédéré.
    Dans l'exemple suivant, la demande CUSTOM_CLAIM1 est associée à la propriété de référentiel fédéré departmentNumber. La demande language est associée à la caractéristique de référentiel fédéré preferredLanguage, et la demande CUSTOM_CLAIM2 est associée à la propriété de référentiel fédéré mail.
    <claimToUserRegistryMap CUSTOM_CLAIM1="departmentNumber"
                            language="preferredLanguage" 
                            CUSTOM_CLAIM2="mail" />
    1. Pour définir des demandes portant le même nom mais dans une casse différente, vous devez utiliser le sous-élément property. Dans l'exemple ci-après, les demandes CUSTOM_CLAIM1 et custom_claim1 sont définies.
      <claimToUserRegistryMap CUSTOM_CLAIM1="departmentNumber" >
          <property name="custom_claim1" value="employeeType" />
      </claimToUserRegistryMap>
  3. Configurez les attributs de registre d'utilisateurs qui sont associés aux propriétés de référentiel fédéré.
    Dans l'exemple suivant, la propriété de référentiel fédéré photoURL est associée à l'attribut de registre LDAP ldapPersonPicture
    <ldapRegistry...>
      ...
        <attributeConfiguration>
            <attribute name="ldapPersonPicture" 
                       propertyName="photoURL" 
                       entityType="PersonAccount" />
        </attributeConfiguration>
       ...
    </ldapRegistry>
    Remarque : L'attribut LDAP doit être défini dans le schéma du registre LDAP.

Résultats

Vous avez maintenant terminé la configuration obligatoire pour personnaliser les demandes qui sont renvoyées par le noeud final UserInfo.

Icône indiquant le type de rubrique Rubrique Tâche



Icône d'horodatage Dernière mise à jour: Tuesday, 6 December 2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=twlp_config_scopes_claims_userinfo
Nom du fichier : twlp_config_scopes_claims_userinfo.html