Mappage de demande OpenID Connect pour le contexte d'autorisation

Modifier en ligne

En fonction de la configuration, les flux OAuth ou Open ID Connect dans IBM® Verify peuvent effectuer des actions d'autorisation.

Les flux peuvent inclure ces actions.

  • Évaluez la règle d'accès.
  • Calculez les valeurs de réclamation qui sont stockées dans l'octroi d'autorisation et utilisées pour générer des jetons d'ID et la réponse de l'introspection.

La règle de mappage des demandes de contexte fournit un mécanisme pour étendre le contexte collecté à partir de la demande d'autorisation. Par exemple, la demande d'autorisation peut contenir un paramètre de demande personnalisé appelé contextID. La règle personnalisée peut inclure contextID dans une requête HTTP sur un nœud final externe. Le résultat de cette demande HTTP est un objet qui peut être décompressé et ajouté au requestContext utilisé lors de l'évaluation de la règle d'accès et de l'enrichissement de l'octroi. Voir r_attr_functions.html

La règle peut être écrite à l'aide d'un langage simple d'expression à une seule ligne ou d'un document YAML multiligne plus avancé. Voir « Exécuteur de règles multilignes ».

Objets d'entrée disponibles

Étant donné que la règle personnalisée est exécutée après l'authentification mais avant l'autorisation, les informations disponibles ne comprennent pas tous les objets de domaine possibles. Ils sont limités aux objets suivants.
Contexte de demande HTTP
Lorsqu'un utilisateur se connecte à Verify, le contexte de requête HTTP entrant est accessible dans la règle de mappage des demandes. Tous les paramètres de requête OAuth, tels que claims et scope, sont disponibles dans cette requestContext. La structure générale et l'utilisation de requestContext sont décrites dans la section « HTTP Request Context » du document r_attr_functions.html.
Pour l'accès, certaines valeurs sont préétablies dans requestContext. Le paramètre de requête claims est généralement représenté comme un fichier JSON comme l'exemple suivant.

{
    "id_token": { 
        "claim_name": { 
            "essential": false, 
            "value": "some_value"
        }
    },
    "userinfo": {
        "claim_name": { 
            "essential": false, 
            "value": "some_value"
        }
    }
}

Ce format peut être difficile d'accès. La clé utilisée dans requestContext est au format claims_claimType_claimName. claimType est userinfo ou idtoken (remarquez le trait de soulignement manquant). Par conséquent, à l'aide de l'exemple précédent, la valeur claim_name peut être obtenue à l'aide de requestContext.getValue('claims_idtoken_claim_name').

De même, scope est divisé par le séparateur d'espace pour générer un tableau de chaînes.

Donnée d'identification de la source d'identité
Lorsqu'un utilisateur se connecte à Verify, les attributs de données d'identification source d'identité sont ajoutés à la session de connexion et sont accessibles dans la règle de mappage des demandes.
L'objet de domaine idsuser est disponible sous la forme d'une mappe avec une clé de chaîne et une valeur de tableau de chaînes. Par exemple :

{
  "realmName": ["cloudIdentityRealm"],
  "displayName": ["Jessica J. Hill"],
  "phone": ["+12324321234"]
}
Voir r_attr_functions.html.
Autres fonctions et opérateurs
Les opérateurs et fonctions standard sont disponibles dans la règle de mappage. Le client HTTP est également disponible pour effectuer des demandes sortantes. Les autres fonctions prises en charge incluent le hachage et les horodatages. Consultez les sections correspondantes sur r_attr_functions.html.

Objet de retour

Cette règle personnalisée est censée renvoyer un objet JSON et la valeur de chaque propriété JSON doit être un tableau de chaînes.

L'exemple suivant est un objet de retour.

{
   "ageRange": ["toddler"],
   "interests": ["sleeping", "other_misc_activities"]
}
Cette valeur de retour est traitée et peut être ensuite accessible dans les attributs de règle avancés à l'aide de requestContext.ageRange et de requestContext.interests. Les attributs de règle avancés peuvent être utilisés dans des règles d'accès telles que {{requestContext.ageRange[0] != 'toddler'}} ou pour mapper des attributs dans la subvention d'autorisation requestContext.interests.

Exemple - Ajouter des passe-temps au jeton d'ID

Le code suivant est un exemple de règle personnalisée pour le mappage des demandes qui ajoute hobbies au jeton d'ID.

statements:
- context: "contextData := hc.getAsJSON('https://jke.com/users/' + idsuser.getValue('uid'), { 'Authorization': 'apikey supersecretkey' })"
- return: >-
   {
      "hobbies": request.Context.interests.filter(x, x != 'other')
   }
Dans cet exemple, la règle appelle un nœud final d'utilisateur externe pour obtenir des informations supplémentaires sur l'utilisateur. Il utilise l'objet idsuser, qui représente la session authentifiée de l'utilisateur sous Verify. Enfin, la règle extrait hobbies de la réponse.
Remarque : cette règle n'effectue aucune validation et n'est pas prête à être utilisée en production.
Les méthodes suivantes permettent d'accéder à hobbies.