Gestion de la cartographie des consentements

Les autorisations accordées sont enregistrées et peuvent être gérées; voir la section « Gestion des autorisations de confidentialité ». De plus, le champ d'application autorisé peut être lié à une finalité relative à la protection de la vie privée. Voir la section « Gestion des finalités de traitement ».

Les détails d'autorisation correspondent à des autorisations très précises; par conséquent, les détails des autorisations accordées par l'utilisateur sont également enregistrés et peuvent être gérés. Tout comme les champs d'application, les détails relatifs aux autorisations accordées peuvent également être associés à une finalité en matière de protection de la vie privée.

Cependant, contrairement aux champs d'application qui sont des chaînes de caractères, les informations d'autorisation sont des objets JSON. Il est complexe de déterminer si deux objets JSON sont égaux. L'implémentation par défaut ne prend en charge qu'un nombre limité de méthodes de comparaison.
  • La première approche consiste full hashà générer une valeur de hachage à partir de l'objet JSON sérialisé, puis à l'utiliser pour comparer deux objets JSON de détails d'autorisation de même type.
  • La deuxième approche consiste à common fields hash. Dans cette approche, la valeur de hachage est calculée à partir des champs de données communs de l'objet JSON. Les champs de données communs sont locations, actions, datatypes, identifier et privileges. N'utilisez cette approche que si votre objet JSON contenant les informations d'autorisation comporte ces champs.
  • La dernière approche est advanced. Cette approche utilise le langage de script CELx pour définir la logique de comparaison. Par exemple, lorsque les détails de l'autorisation correspondent à un transaction et comportent une propriété unique transactionID , cette propriété peut être utilisée à la place des méthodes décrites précédemment.
Remarque : l'objet JSON est accessible dans le script via requestContext.ad la clé. Si vous souhaitez renvoyer la transactionID propriété de l'objet JSON, vous pouvez utiliser requestContext.ad.transactionID dans le script. La structure générale et l'utilisation de requestContext sont décrites dans la section « Contexte de requête HTTP » de la rubrique « Fonctions d'attribut ».

Cartographie personnalisée des consentements

Vous pouvez choisir de ne pas utiliser l'implémentation par défaut pour diverses raisons, telles que :

  • Vous pouvez associer une politique de confidentialité aux informations relatives à l'autorisation demandée.
  • Vous pouvez associer des propriétés supplémentaires à l'élément de consentement demandé. Par exemple, le consentement devrait être accordé automatiquement ou être obligatoire. Le tableau suivant présente les propriétés pouvant être associées à l'élément de consentement.
Vous pouvez choisir de définir un mappage de consentement personnalisé et de spécifier un script CELx pour renvoyer un objet JSON. L'objet JSON peut comporter les propriétés suivantes :
Propriété Type Obligatoire ? Descriptif
purpose chaîne Oui Gestion des objectifs de confidentialité
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. Si elle n'est pas fournie, ladefault valeur est utilisée.
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 option est disponible pour être affichée dans la page de consentement sous forme de macros de modèle.
claims Objet JSON. La valeur de la propriété JSON peut être de n'importe quel type. Non Si la demande est autorisée, les demandes correspondantes sont ajoutées au jeton d'ID émis.
required booléen Non Si required cette option est activée, l'utilisateur doit alors 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. Ce paramètre s'applique aux éléments nécessitant un consentement, tels que les documents relatifs aux 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.
Voici un exemple du JSON renvoyé par le mappage de consentement personnalisé :
    {
    "purpose": "marketing",
    "attribute": "email",
    "accessType": "read",
    "value": "jhill@ibm.com",
    "custom": {
        "type": "personal"
    },
    "autoGrant": true,
    "required": false
}