Mappage de demande OpenID Connect pour les demandes de consentement

Modifier en ligne

Le flux d'autorisation OAuth et Open ID Connect peut présenter aux utilisateurs une invite de consentement qui demande l'autorisation.

Les flux d'autorisation peuvent demander l'autorisation pour effectuer les actions suivantes.
  • Partager les données du profil de l'utilisateur, telles que l'adresse électronique. Cette demande peut éventuellement être complétée par des informations indiquant le but dans lequel les données sont partagées.
  • Exécuter des actions pour le compte de l'utilisateur, telles que démarrer son véhicule et le chauffage lors d'un jour froid ou lancer un paiement.
En général, les applications demandent l'action sous la forme du scope paramètre. Il arrive toutefois que la requête doive être modifiée. Par exemple :
  • Vérifiez toujours le statut d'autorisation de l'utilisateur conformément au contrat de licence.
  • Filtrez les valeurs scope spécifiques en fonction de la session d'authentification de l'utilisateur.
  • Ajoutez plus de contexte qui indique la raison pour laquelle les données sont demandées, qu'elles soient codées dans l'scope (par exemple, email_for_billing) ou qu'elles soient disponibles dans le cadre d'un autre paramètre de demande (tel que authorization_details).

Ce type de modification peut être obtenu à l'aide de la règle personnalisée du paramètre de demande de consentement. Voir « Fonctions d'attribut ». 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 Programme d'exécution de règle multiligne.

Objets d'entrée disponibles

Étant donné que cette 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 types 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 « Contexte de requête HTTP » de la documentation sur les fonctions d'attribut.
Pour simplifier l'accès, certaines valeurs sont précalculées dans requestContext. Le paramètre de claims requête est représenté au format JSON, comme dans l'exemple suivant.
{
    "id_token": { 
        "claim_name": { 
            "essential": false, 
            "value": "some_value"
        }
    },
    "userinfo": {
        "claim_name": { 
            "essential": false, 
            "value": "some_value"
        }
    }
}

Cet élément JSON peut être difficile d'accès et la clé utilisée dans le fichier requestContext est donc au format claims_claimType_claimName. claimType est userinfo ou idtoken. Notez le trait de soulignement manquant. Ainsi, avec 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 calculé et divisé par un 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"]
}
Pour plus d'informations, consultez la section « Fonctions d'attribut ».
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 dans la rubrique « Fonctions d'attribut ».

Objet de retour

La règle personnalisée doit renvoyer un tableau contenant des chaînes ou des objets. Les chaînes sont des portées, tandis que les objets sont des portées avec des informations supplémentaires pour les associer à une fin de confidentialité. Voir … /tasks/t_manage_purposes.html.

Le code suivant est un exemple d'objet de retour. marketingLorsque l'utilisateur donne son consentement à la première requête, un consentement est créé pour l'attribut email . En outre, la portée personal:email est accordée et la réclamation personal_email_allowed est ajoutée au jeton d'ID.

[
	{
		"purpose": "marketing",
		"attribute": "email",
		"accessType": "read",
		"value": "jhill@ibm.com",
		"custom": {
			"type": "personal"
		},
		"claims": {
			"personal_email_allowed": true
		},
		"scope": "personal:email"
	},
    {
        "purpose": "defaultEULA"
    },
	"profile",
	"email"
] + requestContext.scope
Remarque :

La liste ici remplace complètement les portées demandées et est utilisée pour construire la page de consentement. Voir « Modifier l'authentification unique pour les pages OpenID ». Si l'intention est de demander plus de consentement à l'utilisateur, vous devez ajouter requestScope.scope comme indiqué dans l'exemple d'ajout et de suppression de portées.

Dans l'exemple, le tableau peut accepter deux types : la portée OAuth comme une chaîne et un objet qui a plus de contexte et donne un enregistrement d'autorisation de consentement à granularité plus fine. Ces propriétés sont les propriétés autorisées dans l'objet.

Propriété Type Obligatoire ? Descriptif
purpose Chaîne Oui ../tasks/t_manage_purposes.html
attribute Chaîne Dépend de l'objectif Gestion des attributs
accessType Chaîne Dépend de l'objectif Le type d'accès est configuré avec l'objectif de confidentialité des données. La valeur par défaut est default si elle n'est pas fournie.
value Chaîne Non Indique une demande de consentement plus spécifique. Par exemple, le consentement pour un e-mail spécifique.
custom Objet JSON. Le type de valeur de propriété JSON est une chaîne. Non Toute information contextuelle supplémentaire à ajouter au consentement. Cette propriété peut être affichée sur la page de consentement sous forme de macros de modèle.
claim Objet JSON. Le type de valeur de propriété JSON est une chaîne. Non Si la demande est autorisée, les demandes correspondantes sont ajoutées au jeton d'ID émis.
scope Chaîne Non Si la demande est autorisée, cette valeur est ajoutée aux portées accordées.
required Booléen Non Si required cette option est activée, l'utilisateur doit donner son accord. Ce consentement n'est pas requis si la politique de confidentialité précise que le consentement ne peut en aucun cas être accepté.
autoGrant Booléen Non Si autoGrant cette option est définie sur « true », l'utilisateur n'est pas invité à donner son consentement et l'élément de consentement est automatiquement autorisé.
global Booléen Non Si global cette option est définie sur « true », le consentement enregistré s'applique à toutes les applications. Cette propriété s'applique aux éléments nécessitant un consentement, tels que les conditions générales que l'utilisateur n'accepte qu'une seule fois.
audience Chaîne Non Si la demande est autorisée, cette valeur est ajoutée aux audiences accordées, en plus de la liste des audiences configurées dans l'application et de l'identifiant client par défaut.
Exemple d'ajout et de suppression de portées
Dans cet exemple, un nouvel objet de demande de consentement est ajouté et une portée est supprimée.
[
   {
       "purpose": "defaultEula",
       "scope": "eula:default"
   }
] + requestContext.scope.filter(x, x != "badscope")

Cette règle accorde la portée eula:default à l'autorisation et l'associe au consentement EULA. Il filtre également badscope des portées demandées.

La page de consentement peut être personnalisée pour afficher les détails de la demande de consentement qui ont été ajoutés via cette règle de mappage. Vous trouverez un exemple à l'adresse suivante : OpenID Mappage des requêtes « Connect » à l'identifiant d'intention Open Banking.