Associer les jetons du fournisseur d'identité au schéma - Amazon Verified Permissions
Ce qu'il faut savoir sur le mappage de schémasJetons d'identification de mappageCartographie des jetons d'accèsNotation alternative pour les réclamations séparées par des deux-points sur Amazon Cognito

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Associer les jetons du fournisseur d'identité au schéma

Vous souhaiterez peut-être ajouter une source d'identité à un magasin de politiques et mapper les revendications du fournisseur dans le schéma de votre magasin de politiques. Vous pouvez automatiser ce processus ou mettre à jour votre schéma manuellement. Une fois que vous avez mappé les jetons au schéma, vous pouvez créer des politiques qui les référencent.

Cette section du guide de l'utilisateur contient les informations suivantes :

  • Quand vous pouvez renseigner automatiquement les attributs d'un schéma de magasin de politiques

  • Comment utiliser Amazon Cognito et les demandes de OIDC jetons dans vos politiques d'autorisations vérifiées

  • Comment créer manuellement un schéma pour une source d'identité

APILes magasins de politiques liés et les magasins de politiques dotés d'une source d'identité via la configuration guidée ne nécessitent pas de mappage manuel des attributs des jetons d'identité (ID) avec le schéma. Vous pouvez fournir des autorisations vérifiées avec les attributs de votre groupe d'utilisateurs ou vos OIDC jetons et créer un schéma renseigné avec les attributs utilisateur. Dans l'autorisation par jeton d'identification, Verified Permissions associe les revendications aux attributs d'une entité principale. Vous devrez peut-être mapper manuellement les jetons Amazon Cognito à votre schéma dans les conditions suivantes :

  • Vous avez créé un magasin de politiques vide ou un magasin de politiques à partir d'un échantillon.

  • Vous souhaitez étendre votre utilisation des jetons d'accès au-delà du contrôle d'accès basé sur les rôles ()RBAC.

  • Vous créez des magasins de politiques avec les autorisations vérifiées REST API AWS SDK, un ou le AWS CDK.

Pour utiliser Amazon Cognito ou un fournisseur d'OIDCidentité (IdP) comme source d'identité dans votre magasin de politiques d'autorisations vérifiées, vous devez avoir des attributs de fournisseur dans votre schéma. Si vous avez créé votre magasin de politiques de manière à remplir automatiquement votre schéma à partir des informations du fournisseur contenues dans un jeton d'identification, vous êtes prêt à écrire des politiques. Si vous créez un magasin de politiques sans schéma pour votre source d'identité, vous devez ajouter des attributs de fournisseur au schéma. Votre schéma doit correspondre aux entités que les jetons du fournisseur créent IsAuthorizedWithTokenou BatchIsAuthorizedWithTokenAPIdemandent. Vous pouvez ensuite écrire des politiques à l'aide des attributs du jeton du fournisseur.

Pour plus d'informations sur l'utilisation de l'identifiant Amazon Cognito et des jetons d'accès pour les utilisateurs authentifiés dans le cadre des autorisations vérifiées, consultez la section Autorisation avec autorisations vérifiées Amazon dans le guide du développeur Amazon Cognito.

Ce qu'il faut savoir sur le mappage de schémas

Le mappage des attributs diffère selon les types de jetons

Dans l'autorisation du jeton d'accès, Verified Permissions associe les revendications au contexte. Dans l'autorisation par jeton d'identification, Verified Permissions associe les revendications aux attributs principaux. Pour les magasins de politiques que vous créez dans la console Verified Permissions, seuls les magasins de politiques vides et d'exemple ne vous laissent aucune source d'identité et vous obligent à renseigner votre schéma avec les attributs du groupe d'utilisateurs pour l'autorisation par jeton d'identification. L'autorisation des jetons d'accès est basée sur un contrôle d'accès basé sur les rôles (RBAC) avec des revendications d'appartenance à un groupe et ne met pas automatiquement en correspondance les autres revendications avec le schéma de la banque de politiques.

Les attributs de source d'identité ne sont pas obligatoires

Lorsque vous créez une source d'identité dans la console Verified Permissions, aucun attribut n'est marqué comme obligatoire. Cela évite que les demandes manquantes ne provoquent des erreurs de validation dans les demandes d'autorisation. Vous pouvez définir les attributs comme obligatoires selon vos besoins, mais ils doivent être présents dans toutes les demandes d'autorisation.

RBACne nécessite pas d'attributs dans le schéma

Les schémas des sources d'identité dépendent des associations d'entités que vous créez lorsque vous ajoutez votre source d'identité. Une source d'identité associe une réclamation à un type d'entité utilisateur et une réclamation à un type d'entité de groupe. Ces mappages d'entités sont au cœur d'une configuration identité-source. Avec ces informations minimales, vous pouvez rédiger des politiques qui exécutent des actions d'autorisation pour des utilisateurs spécifiques et des groupes spécifiques dont les utilisateurs peuvent être membres, dans un modèle de contrôle d'accès basé sur les rôles (RBAC). L'ajout de revendications de jetons au schéma étend le champ d'autorisation de votre magasin de politiques. Les attributs utilisateur issus des jetons d'identification contiennent des informations sur les utilisateurs qui peuvent contribuer à l'autorisation du contrôle d'accès basé sur les attributs (ABAC). Les attributs contextuels des jetons d'accès contiennent des informations telles que les étendues OAuth 2.0 qui peuvent fournir des informations de contrôle d'accès supplémentaires de la part de votre fournisseur, mais nécessitent des modifications de schéma supplémentaires.

Les options Configurer avec une API passerelle et une source d'identité et Configuration guidée de la console Verified Permissions attribuent des demandes de jeton d'identification au schéma. Ce n'est pas le cas pour les demandes de jetons d'accès. Pour ajouter des revendications de jeton d'accès non groupé à votre schéma, vous devez modifier votre schéma en JSON mode et ajouter des attributs. commonTypes Pour de plus amples informations, veuillez consulter Cartographie des jetons d'accès.

OIDCles groupes affirment qu'ils prennent en charge plusieurs formats

Lorsque vous ajoutez un OIDC fournisseur, vous pouvez choisir le nom du groupe revendiqué sous forme d'identifiant ou de jetons d'accès que vous souhaitez associer à l'appartenance au groupe d'un utilisateur dans votre magasin de politiques. Les autorisations vérifiées reconnaissent les demandes de groupes dans les formats suivants :

  1. Chaîne sans espaces : "groups": "MyGroup"

  2. Liste délimitée par des espaces :. "groups": "MyGroup1 MyGroup2 MyGroup3" Chaque chaîne est un groupe.

  3. JSONliste (séparée par des virgules) : "groups": ["MyGroup1", "MyGroup2", "MyGroup3"]

Note

Verified Permissions interprète chaque chaîne d'une réclamation de groupe séparée par des espaces comme un groupe distinct. Pour interpréter un nom de groupe comportant un espace comme un groupe unique, remplacez ou supprimez l'espace dans la réclamation. Par exemple, formatez un groupe nommé My Group commeMyGroup.

Choisissez un type de jeton

La façon dont votre magasin de politiques fonctionne avec votre source d'identité dépend d'une décision clé en matière de configuration de la source d'identité : traiter les identifiants ou les jetons d'accès. Avec un fournisseur d'identité Amazon Cognito, vous pouvez choisir le type de jeton lorsque vous créez un magasin de politiques API lié à un lien. Lorsque vous créez un magasin de politiques API lié, vous devez choisir si vous souhaitez configurer l'autorisation pour les jetons d'identification ou d'accès. Ces informations affectent les attributs de schéma que Verified Permissions applique à votre magasin de politiques, ainsi que la syntaxe de l'autorisateur Lambda pour votre passerelle. API API Avec un OIDC fournisseur, vous devez choisir un type de jeton lorsque vous ajoutez la source d'identité. Vous pouvez choisir un identifiant ou un jeton d'accès, et votre choix exclut le type de jeton non choisi du traitement dans votre magasin de polices. En particulier, si vous souhaitez bénéficier du mappage automatique des demandes de jeton d'identification aux attributs dans la console Verified Permissions, déterminez rapidement le type de jeton que vous souhaitez traiter avant de créer votre source d'identité. La modification du type de jeton nécessite des efforts considérables pour refactoriser vos politiques et votre schéma. Les rubriques suivantes décrivent l'utilisation des jetons d'identification et d'accès avec les magasins de politiques.

L'analyseur Cedar nécessite des crochets pour certains caractères

Les politiques font généralement référence aux attributs du schéma dans un format tel queprincipal.username. Dans le cas de la plupart des caractères non alphanumériques tels / que :., ou susceptibles d'apparaître dans les noms de réclamation de jetons, Verified Permissions ne peut pas analyser une valeur de condition telle que ou. principal.cognito:username context.ip-address Vous devez plutôt mettre en forme ces conditions avec une notation entre crochets dans le format principal["cognito:username"] oucontext["ip-address"], respectivement. Le caractère de soulignement _ est un caractère valide dans les noms des demandes et constitue la seule exception non alphanumérique à cette exigence.

Voici un exemple de schéma partiel pour un attribut principal de ce type :

"User": {
   "shape": {
      "type": "Record",
      "attributes": {
         "cognito:username": {
            "type": "String",
            "required": true
         },
         "custom:employmentStoreCode": {
            "type": "String",
            "required": true,
         },
         "email": {
            "type": "String",
            "required": false
         }
      }
   }
}

Voici un exemple de schéma partiel pour un attribut de contexte de ce type :

"GetOrder": {
   "memberOf": [],
   "appliesTo": {
      "resourceTypes": [
         "Order"
      ],
      "context": {
         "type": "Record",
         "attributes": {
            "ip-address": {
               "required": false,
               "type": "String"
            }
		 }
	  },
      "principalTypes": [
         "User"
      ]
   }
}

Pour un exemple de politique qui sera validée par rapport à ce schéma, consultezUtilise la notation entre crochets pour référencer les attributs des jetons.

Associer les jetons d'identification au schéma

Verified Permissions traite les demandes de jetons d'identification en tant qu'attributs de l'utilisateur : ses noms et titres, son appartenance à un groupe, ses coordonnées. Les jetons d'identification sont particulièrement utiles dans un modèle d'autorisation de contrôle d'accès (ABAC) basé sur les attributs. Lorsque vous souhaitez que les autorisations vérifiées analysent l'accès aux ressources en fonction de l'auteur de la demande, choisissez des jetons d'identification pour votre source d'identité.

Jetons d'identification Amazon Cognito

Les jetons d'identification Amazon Cognito fonctionnent avec la plupart des bibliothèques utilisatricesOIDC. Ils étendent les fonctionnalités de OIDC avec des réclamations supplémentaires. Votre application peut authentifier l'utilisateur à l'aide des opérations d'APIauthentification des groupes d'utilisateurs Amazon Cognito ou à l'aide de l'interface utilisateur hébergée par les groupes d'utilisateurs. Pour plus d'informations, consultez la section Utilisation des points de terminaison API et dans le manuel Amazon Cognito Developer Guide.

Réclamations utiles concernant les jetons d'identification Amazon Cognito
cognito:username et preferred_username

Variantes du nom d'utilisateur de l'utilisateur.

sub

L'identifiant utilisateur unique de l'utilisateur (UUID)

Réclamations avec custom: préfixe

Un préfixe pour les attributs personnalisés du groupe d'utilisateurs tels quecustom:employmentStoreCode.

Réclamations standard

Des OIDC affirmations standard comme email etphone_number. Pour plus d'informations, consultez la section Réclamations standard dans OpenID Connect Core 1.0 incorporant le jeu d'errata 2.

cognito:groups

Appartenances à un groupe d'utilisateurs. Dans un modèle d'autorisation basé sur le contrôle d'accès basé sur les rôles (RBAC), cette affirmation présente les rôles que vous pouvez évaluer dans vos politiques.

Réclamations transitoires

Réclamations qui ne sont pas une propriété de l'utilisateur, mais qui sont ajoutées au moment de l'exécution par un groupe d'utilisateurs. Déclencheur Lambda pré-génération de jetons. Les réclamations transitoires ressemblent aux réclamations standard mais ne sont pas conformes à la norme, par exemple tenant oudepartment.

Dans les politiques qui font référence à des attributs Amazon Cognito dotés d'un : séparateur, référencez les attributs au format. principal["cognito:username"] La revendication des rôles cognito:groups constitue une exception à cette règle. Verified Permissions associe le contenu de cette réclamation aux entités parentes de l'entité utilisateur.

Pour plus d'informations sur la structure des jetons d'identification issus des groupes d'utilisateurs Amazon Cognito, consultez la section Utilisation du jeton d'identification dans le manuel Amazon Cognito Developer Guide.

L'exemple de jeton d'identification suivant possède chacun des quatre types d'attributs. Elle inclut la réclamation spécifique à Amazon Cognitocognito:username, la réclamation personnaliséecustom:employmentStoreCode, la réclamation standard et la réclamation email transitoire. tenant

{
    "sub": "91eb4550-XXX",
    "cognito:groups": [
        "Store-Owner-Role",
        "Customer"
    ],
    "email_verified": true,
    "clearance": "confidential",
    "iss": "https://cognito-idp.us-east-2.amazonaws.com/us-east-2_EXAMPLE",
    "cognito:username": "alice",
    "custom:employmentStoreCode": "petstore-dallas",
    "origin_jti": "5b9f50a3-05da-454a-8b99-b79c2349de77",
    "aud": "1example23456789",
    "event_id": "0ed5ad5c-7182-4ecf-XXX",
    "token_use": "id",
    "auth_time": 1687885407,
    "department": "engineering",
    "exp": 1687889006,
    "iat": 1687885407,
    "tenant": "x11app-tenant-1",
    "jti": "a1b2c3d4-e5f6-a1b2-c3d4-TOKEN1111111",
    "email": "alice@example.com"
}

Lorsque vous créez une source d'identité avec votre groupe d'utilisateurs Amazon Cognito, vous spécifiez le type d'entité principale que Verified Permissions génère dans les demandes d'autorisation. IsAuthorizedWithToken Vos politiques peuvent ensuite tester les attributs de ce principal dans le cadre de l'évaluation de cette demande. Votre schéma définit le type et les attributs principaux d'une source d'identité, puis vous pouvez les référencer dans vos politiques Cedar.

Vous spécifiez également le type d'entité de groupe que vous souhaitez obtenir à partir de la réclamation des groupes de jetons d'identification. Dans les demandes d'autorisation, Verified Permissions associe chaque membre du groupe à ce type d'entité de groupe. Dans les politiques, vous pouvez faire référence à cette entité de groupe en tant que principale.

L'exemple suivant montre comment refléter les attributs de l'exemple de jeton d'identité dans votre schéma d'autorisations vérifiées. Pour plus d'informations sur la modification de votre schéma, consultezModification des schémas du magasin de politiques en mode JSON. Si la configuration de votre source d'identité spécifie le type principalUser, vous pouvez inclure quelque chose de similaire à l'exemple suivant pour mettre ces attributs à la disposition de Cedar.

"User": {
   "shape": {
      "type": "Record",
      "attributes": {
         "cognito:username": {
            "type": "String",
            "required": false
         },
         "custom:employmentStoreCode": {
            "type": "String",
            "required": false
         },
         "email": {
            "type": "String"
         },
         "tenant": {
            "type": "String",
            "required": true
         }
      }
   }
}

Pour un exemple de politique qui sera validée par rapport à ce schéma, consultezReflète les attributs du jeton d'identification Amazon Cognito.

OIDCJetons d'identification

L'utilisation des jetons d'identification d'un OIDC fournisseur est similaire à celle des jetons d'identification Amazon Cognito. La différence réside dans les réclamations. Votre IdP peut présenter des OIDCattributs standard ou avoir un schéma personnalisé. Lorsque vous créez un nouveau magasin de politiques dans la console Verified Permissions, vous pouvez ajouter une source OIDC d'identité avec un exemple de jeton d'identification, ou vous pouvez associer manuellement les demandes de jetons aux attributs utilisateur. Comme Verified Permissions ne connaît pas le schéma d'attributs de votre IdP, vous devez fournir ces informations.

Pour de plus amples informations, veuillez consulter Création de magasins de politiques d'autorisations vérifiées.

Voici un exemple de schéma pour un magasin de politiques doté d'une source OIDC d'identité.

"User": {
   "shape": {
      "type": "Record",
      "attributes": {
         "email": {
            "type": "String"
         },
         "email_verified": {
            "type": "Boolean"
         },
         "name": {
            "type": "String",
            "required": true
         },
         "phone_number": {
            "type": "String"
         },
         "phone_number_verified": {
            "type": "Boolean"
         }
      }
   }
}

Pour un exemple de politique qui sera validée par rapport à ce schéma, consultezReflète les attributs des jetons d'OIDCidentification.

Cartographie des jetons d'accès

Verified Permissions traite les demandes de jetons d'accès autres que celles revendiquées par les groupes en tant qu'attributs de l'action ou en tant qu'attributs contextuels. Outre l'appartenance à un groupe, les jetons d'accès de votre IdP peuvent contenir des informations sur API l'accès. Les jetons d'accès sont utiles dans les modèles d'autorisation qui utilisent le contrôle d'accès basé sur les rôles ()RBAC. Les modèles d'autorisation qui reposent sur des revendications de jetons d'accès autres que l'appartenance à un groupe nécessitent des efforts supplémentaires pour configurer le schéma.

Cartographie des jetons d'accès Amazon Cognito

Les jetons d'accès Amazon Cognito contiennent des revendications qui peuvent être utilisées à des fins d'autorisation :

Réclamations utiles concernant les jetons d'accès Amazon Cognito
client_id

L'ID de l'application client d'une partie OIDC utilisatrice. À l'aide de l'ID client, Verified Permissions peut vérifier que la demande d'autorisation provient d'un client autorisé pour le magasin de politiques. Dans le machine-to-machine cadre de l'autorisation (M2M), le système demandeur autorise une demande avec un secret client et fournit l'identifiant du client et les champs d'application comme preuve d'autorisation.

scope

Les étendues OAuth 2.0 qui représentent les autorisations d'accès du porteur du jeton.

cognito:groups

Appartenances à un groupe d'utilisateurs. Dans un modèle d'autorisation basé sur le contrôle d'accès basé sur les rôles (RBAC), cette affirmation présente les rôles que vous pouvez évaluer dans vos politiques.

Réclamations transitoires

Réclamations qui ne constituent pas une autorisation d'accès, mais qui sont ajoutées au moment de l'exécution par un groupe d'utilisateurs. Déclencheur Lambda avant la génération de jetons. Les réclamations transitoires ressemblent aux réclamations standard mais ne sont pas conformes à la norme, par exemple tenant oudepartment. La personnalisation des jetons d'accès augmente le coût de votre AWS facture.

Pour plus d'informations sur la structure des jetons d'accès issus des groupes d'utilisateurs Amazon Cognito, consultez la section Utilisation du jeton d'accès dans le manuel Amazon Cognito Developer Guide.

Un jeton d'accès Amazon Cognito est mappé à un objet de contexte lorsqu'il est transmis à Verified Permissions. Les attributs du jeton d'accès peuvent être référencés à l'aide decontext.token.attribute_name. L'exemple de jeton d'accès suivant inclut à la fois les scope revendications client_id et.

{
    "sub": "91eb4550-9091-708c-a7a6-9758ef8b6b1e",
    "cognito:groups": [
        "Store-Owner-Role",
        "Customer"
    ],
    "iss": "https://cognito-idp.us-east-2.amazonaws.com/us-east-2_EXAMPLE",
    "client_id": "1example23456789",
    "origin_jti": "a1b2c3d4-e5f6-a1b2-c3d4-TOKEN1111111",
    "event_id": "bda909cb-3e29-4bb8-83e3-ce6808f49011",
    "token_use": "access",
    "scope": "MyAPI/mydata.write",
    "auth_time": 1688092966,
    "exp": 1688096566,
    "iat": 1688092966,
    "jti": "a1b2c3d4-e5f6-a1b2-c3d4-TOKEN2222222",
    "username": "alice"
}

L'exemple suivant montre comment refléter les attributs de l'exemple de jeton d'accès dans votre schéma d'autorisations vérifiées. Pour plus d'informations sur la modification de votre schéma, consultezModification des schémas du magasin de politiques en mode JSON.

{
   "MyApplication": {
      "actions": {
         "Read": {
            "appliesTo": {
               "context": {
                  "type": "ReusedContext"
               },
               "resourceTypes": [
                  "Application"
               ],
               "principalTypes": [
                  "User"
               ]
            }
         }
      },
      ...
      ...
      "commonTypes": {
         "ReusedContext": {
            "attributes": {
               "token": {
                  "type": "Record",
                  "attributes": {
                     "scope": {
                        "type": "Set",
                        "element": {
                           "type": "String"
                        }
                     },
                     "client_id": {
                        "type": "String"
                     }
                  }
               }
            },
            "type": "Record"
         }
      }
   }
}

Pour un exemple de politique qui sera validée par rapport à ce schéma, consultezReflète les attributs du jeton d'accès Amazon Cognito.

Cartographie des jetons OIDC d'accès

La plupart des jetons d'accès provenant de OIDC fournisseurs externes sont étroitement liés aux jetons d'accès Amazon Cognito. Un jeton d'OIDCaccès est mappé à un objet de contexte lorsqu'il est transmis à Verified Permissions. Les attributs du jeton d'accès peuvent être référencés à l'aide decontext.token.attribute_name. L'exemple de jeton OIDC d'accès suivant inclut des exemples de revendications de base.

{
    "sub": "91eb4550-9091-708c-a7a6-9758ef8b6b1e",
    "groups": [
        "Store-Owner-Role",
        "Customer"
    ],
    "iss": "https://auth.example.com",
    "client_id": "1example23456789",
    "aud": "https://myapplication.example.com"
    "scope": "MyAPI-Read",
    "exp": 1688096566,
    "iat": 1688092966,
    "jti": "a1b2c3d4-e5f6-a1b2-c3d4-TOKEN2222222",
    "username": "alice"
}

L'exemple suivant montre comment refléter les attributs de l'exemple de jeton d'accès dans votre schéma d'autorisations vérifiées. Pour plus d'informations sur la modification de votre schéma, consultezModification des schémas du magasin de politiques en mode JSON.

{
   "MyApplication": {
      "actions": {
         "Read": {
            "appliesTo": {
               "context": {
                  "type": "ReusedContext"
               },
               "resourceTypes": [
                  "Application"
               ],
               "principalTypes": [
                  "User"
               ]
            }
         }
      },
      ...
      ...
      "commonTypes": {
         "ReusedContext": {
            "attributes": {
               "token": {
                  "type": "Record",
                  "attributes": {
                     "scope": {
                        "type": "Set",
                        "element": {
                           "type": "String"
                        }
                     },
                     "client_id": {
                        "type": "String"
                     }
                  }
               }
            },
            "type": "Record"
         }
      }
   }
}

Pour un exemple de politique qui sera validée par rapport à ce schéma, consultezReflète les attributs des jetons d'OIDCaccès.

Notation alternative pour les réclamations séparées par des deux-points sur Amazon Cognito

Au moment du lancement de Verified Permissions, le schéma recommandé pour le jeton Amazon Cognito prétendait aimer cognito:groups et custom:store convertir ces chaînes séparées par des points pour utiliser le . caractère comme séparateur hiérarchique. Ce format est appelé notation par points. Par exemple, une référence à cognito:groups est devenue principal.cognito.groups dans vos politiques. Bien que vous puissiez continuer à utiliser ce format, nous vous recommandons de créer votre schéma et vos politiques avec la notation entre crochets. Dans ce format, une référence à cognito:groups apparaît principal["cognito:groups"] dans vos politiques. Les schémas générés automatiquement pour les jetons d'identification du groupe d'utilisateurs à partir de la console Verified Permissions utilisent la notation entre crochets.

Vous pouvez continuer à utiliser la notation par points dans le schéma et les politiques créés manuellement pour les sources d'identité Amazon Cognito. Vous ne pouvez pas utiliser la notation par points : ou tout autre caractère non alphanumérique dans le schéma ou les politiques pour tout autre type d'OIDCIdP.

Un schéma de notation par points imbrique chaque instance d'un : caractère en tant qu'enfant de la phrase custom initiale cognito ou de la phrase initiale, comme le montre l'exemple suivant :

"CognitoUser": {
   "shape": {
      "type": "Record",
      "attributes": {
         "cognito": {
            "type": "Record",
            "required": true,
            "attributes": {
               "username": {
                  "type": "String",
                  "required": true
               }
            }
         },
         "custom": {
            "type": "Record",
            "required": true,
            "attributes": {
               "employmentStoreCode": {
                  "type": "String",
                  "required": true
               }
            }
         },
         "email": {
            "type": "String"
         },
         "tenant": {
            "type": "String",
            "required": true
         }
      }
   }
}

Pour un exemple de politique qui sera validée par rapport à ce schéma et utilisera la notation par points, voirUtilise la notation par points pour référencer les attributs.