Personnalisation des jetons

Avec le service App ID, des jetons sont employés pour identifier les utilisateurs et sécuriser vos ressources. Vous pouvez éventuellement personnaliser les informations injectées dans les jetons. En injectant les informations dans vos jetons, elles sont disponibles pour votre application au moment de l'exécution, sans que vous ayez à configurer des appels réseau supplémentaires. Pour plus d'informations sur les jetons et leur utilisation dans le service App ID, voir Jetons.

La personnalisation de la configuration de vos jetons vous permet de répondre à vos besoins en termes de sécurité et d'expérience utilisateur. Cependant, en cas de compromission d'un jeton, un utilisateur malveillant pourrait bénéficier de plus d'informations ou de temps pour nuire à votre application. N'oubliez pas d'évaluer les conséquences sur la sécurité des personnalisations que vous souhaitez apporter avant de les appliquer.

Comprendre le mappage des revendications personnalisées

Une revendication (claim) est une déclaration qu'une entité fait à son sujet ou au nom de quelqu'un d'autre. Par exemple, si vous vous êtes connecté à une application à l'aide d'un fournisseur d'identité, le fournisseur doit envoyer un groupe de revendications ou de déclarations vous concernant à l'application de sorte qu'elle puisse les regrouper avec les informations qu'elle détient déjà à votre sujet. Ainsi, lorsque vous vous connectez, l'application est configurée avec vos informations, telle que vous l'avez configurée.

Quels types de revendication puis-je définir ?

Les revendications fournies par App ID appartiennent à plusieurs catégories qui se différencient par leur niveau de personnalisation.

Revendications normalisées
Dans chaque jeton d'identité se trouve un ensemble de revendications reconnu par App ID comme étant normalisé. Lorsque les revendications sont disponibles, elles sont directement mappées de votre fournisseur d'identité au jeton par défaut. Les revendications ne peuvent pas être omises explicitement mais elles peuvent être remplacées dans votre jeton par des revendications personnalisées. Les revendications (claims) comprennent les éléments suivants : name, email, picture et locale.
Revendications restreintes
Les revendications restreintes sont celles qui ont des possibilités de personnalisation restreintes et ne peuvent pas être remplacées par des mappages personnalisés. Pour un jeton d'accès, la seule revendication restreinte est scope. Bien qu'elle ne puisse pas être remplacée, elle peut être étendue en fonction de votre propre portée (scope). Lorsqu'une portée est mappée à un jeton d'accès, la valeur doit être une chaîne et ne peut pas commencer par le préfixe appid_ ou est ignorée. Dans les jetons d'identité, les revendications identities et oauth_clients ne peuvent être ni modifiées ni remplacées.
Revendications enregistrées
Les revendications enregistrées se trouvent dans vos jetons d'accès et d'identité et sont définies par App ID. Elles ne peuvent pas être remplacées par des mappages personnalisés. Ces revendications sont ignorées par le service et comprennent iss, aud, sub, iat, exp, amr et tenant.

La définition d'une revendication pour votre jeton ne change pas et n'élimine pas l'attribut. Elle modifie les informations qui figurent dans le jeton lors de l'exécution.

Comment les revendications sont-elles mappées à des jetons ?

Chaque mappage est défini par un objet de source de données et une clé qui est utilisée pour extraire la revendication. Vous pouvez injecter jusqu'à 100 revendications dans chaque jeton si la charge maximale reste inférieure à 100 ko. Si vous souhaitez utiliser des revendications imbriquées, vous pouvez les inclure en utilisant la syntaxe dot. Par exemple, nested.attribute.

Les revendications sont définies pour chaque jeton séparément et appliquées de manière séquentielle comme indiqué dans l'exemple suivant.

{
  "accessTokenClaims": [
    {
      "source": "saml",
      "sourceClaim": "moderator"
    },
    {
      "source": "saml",
      "sourceClaim": "viewer",
      "destinationClaim": "reader"
    }
  ],
  "idTokenClaims": [
    {
      "source": "saml",
      "sourceClaim": "attributes.uid"
    },
    {
      "source": "saml",
      "sourceClaim": "Name",
      "destinationClaim": "firstName"
    },
    {
      "source": "saml",
      "sourceClaim": "Country"
    }
  ]
}
Explication des variables de la cartographie des sinistres
Objet Description
source Définit la source de la revendication. Les options comprennent : saml, cloud_directory, facebook, google, appid_custom et attributes.
sourceClaim Définit la revendication telle qu'elle est fournie par la source. Peut faire référence aux informations utilisateur du fournisseur d'identité ou aux attributs personnalisés App ID de l'utilisateur.
destinationClaim Facultatif : définit l'attribut personnalisé pouvant remplacer la revendication actuelle dans le jeton.

Configuration des jetons

Avec l'API, vous pouvez personnaliser les informations renvoyées dans vos jetons App ID.

Si vous souhaitez configurer le cycle de vie de votre jeton, vous pouvez effectuer ces modifications rapidement via le tableau de bord du service. Pour plus d'informations, voir Gestion de l'authentification.

  1. Dans le terminal, exécutez la commande suivante pour obtenir une clé d'API.

    ibmcloud iam api-key-create NAME [-d DESCRIPTION] [-f, --file FILE]
    
    Comprendre les options de la commande de création d'une clé API
    Option Description
    NAME Nom que vous voulez attribuer à votre clé. Par exemple, myKey.
    DESCRIPTION Description de la clé ou de son utilisation. Par exemple, "This is my App ID API key".
    FILE Emplacement où vous souhaitez stocker votre clé. Par exemple, key_file.
  2. Procurez-vous un jeton IAM en utilisant la clé d'API que vous avez obtenue à l'étape précédente.

    curl -k -X POST "https://iam.cloud.ibm.com/identity/token" \
    --header "Content-Type: application/x-www-form-urlencoded" \
    --header "Accept: application/json" \
    --data-urlencode "grant_type=urn:ibm:params:oauth:grant-type:apikey" \
    --data-urlencode "apikey=<apiKey>"
    
  3. Récupérez l'ID titulaire (tenant ID) pour votre instance du service. Vous pouvez trouver cette valeur dans les données d'identification de votre service ou de votre application.

  4. Envoyez une demande PUT au noeud final /config/tokens avec votre configuration de jeton.

    curl -X PUT "https://<region>.appid.cloud.ibm.com/management/v4/<tenantID>/config/tokens" \
    -H 'Content-Type: application/json' \
    -H "Authorization: Bearer <IAMToken>" \
    -d '{
       "access": {
             "expires_in": 3600
       },
       "refresh": {
             "enabled": true,
             "expires_in": 2592001
       },
       "anonymousAccess": {
             "enabled": false
       },
       "accessTokenClaims": [
             {
             "source": "roles"
             },
             {
             "source": "saml",
             "sourceClaim": "name_id",
             "destinationClaim": "id"
             }
       ],
       "idTokenClaims": [
             {
             "source": "saml",
             "sourceClaim": "attributes.uid"
             }
       ]
    }'
    
    Comprendre la configuration des jetons
    Variable Description
    access: expires_in Durée de validité des jetons d'accès. Plus la valeur est petite, plus la protection est importante en cas de vol de jetons. La valeur est indiquée en secondes et peut comprendre tout nombre entier compris entre 300 et 86400. La valeur par défaut est 3600.
    refresh: expires_in Durée de validité des jetons d'actualisation. Plus la valeur est petite, plus la protection est importante en cas de vol de jetons. La valeur est indiquée en secondes et peut comprendre tout nombre entier compris entre 86400 et 7776000. La valeur par défaut est 2592000 (30 jours).
    anonymousAccess Durée de validité d'un jeton anonyme. Des jetons anonymes sont affectés aux utilisateurs dès qu'ils commencent à interagir avec votre application. Lorsqu'un utilisateur se connecte, les informations contenues dans le jeton anonyme sont alors transférées au jeton associé à l'utilisateur. La valeur est indiquée en secondes et peut comprendre tout nombre entier compris entre 86400 et 7776000. La valeur par défaut est 2592000 (30 jours).
    accessTokenClaims Tableau contenant les objets créés lors du mappage des revendications liées aux jetons d'accès. Vous souhaiterez peut-être inclure des informations sur des rôles ou des attributs spécifiques renvoyés par le fournisseur d'identité d'un utilisateur sélectionné. Remarque : Si vous utilisez déjà une demande personnalisée avec le titre "Rôles" de votre fournisseur d'identité, veillez à utiliser une demande de destination pour voir les deux valeurs.
    idTokenClaims Tableau contenant les informations présentes dans les jetons lorsque vous mappez des revendications à des jetons d'identité. En fonction de votre configuration, vous pouvez également choisir d'avoir l'intitulé "roles" dans votre jeton d'identité.

    Vous devez définir la durée de vie du jeton dans chacune de vos demandes. Si une valeur n'est pas définie, la valeur par défaut est utilisée. Chaque demande de personnalisation remplace ce qui a déjà été configuré. Notez que les spécifications de configuration de durée de vie sont différentes dans l'API et dans le tableau de bord du service.

  5. Une fois le jeton renvoyé et après l'avoir décodé, vous obtenez un résultat semblable à l'exemple suivant :

    {
       "sub" : "1234567890",
       "name" : "John Doe",
       "exp" : 1564566,
       "roles" : ["admin", "manager"],
       "id": "<nameIDFromSaml>",
       "attributes.uid": "<uidFromSaml>"
       ...
    }