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.
# Sécurisez vos applications avec des sources d'identité et des jetons
Sécurisez rapidement vos applications en créant une *source d'identité* représentant un fournisseur d'identité externe (IdP) dans Amazon Verified Permissions. Les sources d'identité fournissent des informations provenant d'un utilisateur qui s'est authentifié auprès d'un IdP ayant une relation de confiance avec votre magasin de politiques. Lorsque votre application fait une demande d'autorisation à l'aide d'un jeton provenant d'une source d'identité, votre magasin de politiques peut prendre des décisions d'autorisation à partir des propriétés des utilisateurs et des autorisations d'accès. Vous pouvez ajouter un groupe d'utilisateurs Amazon Cognito ou un IdP OpenID Connect (OIDC) personnalisé comme source d'identité.
Vous pouvez utiliser les fournisseurs d'identité [OpenID Connect (OIDC)](https://openid.net/specs/openid-connect-core-1_0.html) (IdPs) dotés d'autorisations vérifiées. Votre application peut générer des demandes d'autorisation à l'aide de jetons Web JSON (JWTs) générés par un fournisseur d'identité conforme à l'OIDC. L'identité de l'utilisateur figurant dans le jeton est mappée à l'identifiant principal. Avec les jetons d'identification, Verified Permissions associe les revendications d'attributs aux attributs principaux. Avec les jetons d'accès, ces revendications sont mises en correspondance avec le [contexte](context.md). Avec les deux types de jetons, vous pouvez associer une réclamation `groups` à un groupe principal et élaborer des politiques qui évaluent le contrôle d'accès basé sur les rôles (RBAC).
**Note**
Verified Permissions prend des décisions d'autorisation sur la base des informations provenant d'un jeton IdP, mais n'interagit en aucune façon directement avec l'IdP.
Pour découvrir comment créer step-by-step une logique d'autorisation pour Amazon API Gateway REST à APIs l'aide d'un pool Amazon Cognito d'utilisateurs ou d'un fournisseur d'identité OIDC, consultez la section [Autoriser à l'aide des autorisations vérifiées par API Gateway APIs Amazon avec Amazon Cognito ou apportez votre propre fournisseur d'identité](https://aws.amazon.com/blogs/security/authorize-api-gateway-apis-using-amazon-verified-permissions-and-amazon-cognito/) sur le blog de *AWS sécurité*.
**Topics**
+ [
## Choisir le bon fournisseur d'identité
](#choosing-identity-source)
+ [
# Travailler avec des sources Amazon Cognito d'identité
](identity-sources-cognito.md)
+ [
# Travailler avec les sources d'identité OIDC
](identity-sources-oidc.md)
## Choisir le bon fournisseur d'identité
Bien que les autorisations vérifiées fonctionnent avec de nombreuses IdPs options, tenez compte des points suivants lorsque vous décidez laquelle utiliser dans votre application :
À utiliser Amazon Cognito lorsque :
+ Vous créez de nouvelles applications sans infrastructure d'identité existante
+ Vous voulez des groupes d'utilisateurs AWS gérés avec des fonctionnalités de sécurité intégrées
+ Vous avez besoin de l'intégration d'un fournisseur d'identité sociale
+ Vous souhaitez une gestion simplifiée des jetons
Utilisez les fournisseurs OIDC lorsque :
+ Vous disposez d'une infrastructure d'identité existante (Auth0, Okta, Azure AD)
+ Vous devez maintenir une gestion centralisée des utilisateurs
+ Vous avez des exigences de conformité spécifiques IdPs
# Travailler avec des sources Amazon Cognito d'identité
Verified Permissions travaille en étroite collaboration avec les groupes d'utilisateurs d'Amazon Cognito. Amazon Cognito JWTs ont une structure prévisible. Verified Permissions reconnaît cette structure et tire le meilleur parti des informations qu'elle contient. Par exemple, vous pouvez implémenter un modèle d'autorisation de contrôle d'accès basé sur les rôles (RBAC) avec des jetons d'identification ou des jetons d'accès.
Une nouvelle source d'identité de pool d'utilisateurs Amazon Cognito a besoin des informations suivantes :
+ Le Région AWS.
+ ID du groupe d'utilisateurs.
+ Le type d'entité principal que vous souhaitez associer à votre source d'identité, par exemple`MyCorp::User`.
+ Le type d'entité de groupe principal que vous souhaitez associer à votre source d'identité, par exemple`MyCorp::UserGroup`.
+ Le client IDs de votre groupe d'utilisateurs que vous souhaitez autoriser à envoyer des demandes à votre magasin de politiques.
Comme les autorisations vérifiées ne fonctionnent qu'avec les groupes d'utilisateurs Amazon Cognito appartenant au même groupe Compte AWS, vous ne pouvez pas spécifier de source d'identité dans un autre compte. Les autorisations vérifiées définissent le *préfixe d'entité* (identifiant de source d'identité auquel vous devez faire référence dans les politiques qui agissent sur les principes du groupe d'utilisateurs) à l'ID de votre groupe d'utilisateurs, par exemple. `us-west-2_EXAMPLE` Dans ce cas, vous devez faire référence à un utilisateur de ce groupe d'utilisateurs dont l'identifiant est `a1b2c3d4-5678-90ab-cdef-EXAMPLE22222` `us-west-2_EXAMPLE|a1b2c3d4-5678-90ab-cdef-EXAMPLE22222`
Les *demandes* de jetons du pool d'utilisateurs peuvent contenir des attributs, des étendues, des groupes, des clients IDs et des données personnalisées. [Amazon Cognito JWTs](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html)ont la capacité d'inclure une variété d'informations susceptibles de contribuer aux décisions d'autorisation dans les autorisations vérifiées. Il s’agit des licences suivantes :
1. Nom d'utilisateur et réclamations groupées avec un `cognito:` préfixe
1. [Attributs utilisateur personnalisés](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html#user-pool-settings-custom-attributes) avec `custom: prefix`
1. Réclamations personnalisées ajoutées au moment de l'exécution
1. Les allégations standard de l'OIDC telles que `sub` et `email`
Nous abordons ces réclamations en détail et expliquons comment les gérer dans les politiques d'autorisations vérifiées, dans[Mappage Amazon Cognito des jetons au schéma](cognito-map-token-to-schema.md).
**Important**
Bien que vous puissiez révoquer les Amazon Cognito jetons avant leur expiration, ils JWTs sont considérés comme des ressources apatrides dotées d'une signature et d'une validité autonomes. Les services conformes [au jeton Web JSON RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519) sont censés valider les jetons à distance et ne sont pas tenus de les valider auprès de l'émetteur. Cela signifie qu'il est possible pour les autorisations vérifiées d'accorder l'accès en fonction d'un jeton révoqué ou émis pour un utilisateur qui a ensuite été supprimé. Pour atténuer ce risque, nous vous recommandons de créer vos jetons avec la durée de validité la plus courte possible et de révoquer les jetons d'actualisation lorsque vous souhaitez supprimer l'autorisation de poursuivre la session d'un utilisateur. Pour plus d'informations, voir [Fin des sessions utilisateur par révocation de jetons](https://docs.aws.amazon.com/cognito/latest/developerguide/token-revocation.html)
L'exemple suivant montre comment vous pouvez créer une politique qui fait référence à certaines réclamations des groupes d'utilisateurs Amazon Cognito associées à un mandant.
```
permit(
principal,
action,
resource == ExampleCo::Photo::"VacationPhoto94.jpg"
)
when {
principal["cognito:username"]) == "alice" &&
principal["custom:department"]) == "Finance"
};
```
L'exemple suivant montre comment créer une politique qui fait référence à un principal qui est un utilisateur d'un groupe d'utilisateurs Cognito. Notez que l'identifiant principal prend la forme de`"|"`.
```
permit(
principal == ExampleCo::User::"us-east-1_example|a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
action,
resource == ExampleCo::Photo::"VacationPhoto94.jpg"
);
```
Les politiques de Cedar relatives aux sources d'identité des groupes d'utilisateurs dans Verified Permissions utilisent une syntaxe spéciale pour les noms de demandes contenant des caractères autres que des caractères alphanumériques et un trait de soulignement ()`_`. Cela inclut les revendications de préfixes du groupe d'utilisateurs qui contiennent un `:` caractère, comme `cognito:username` et`custom:department`. Pour rédiger une condition de politique qui fait référence à la `custom:department` réclamation `cognito:username` ou, écrivez-les respectivement sous la forme `principal["cognito:username"]` et`principal["custom:department"]`.
**Note**
Si un jeton contient une réclamation avec le `custom:` préfixe `cognito:` ou et un nom de réclamation avec la valeur littérale `cognito` ou`custom`, une demande d'autorisation avec un [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)échouera avec un. `ValidationException`
Pour plus d'informations sur le mappage des réclamations, consultez[Mappage Amazon Cognito des jetons au schéma](cognito-map-token-to-schema.md). Pour plus d'informations sur l'autorisation des Amazon Cognito utilisateurs, consultez la section [Autorisation avec autorisations vérifiées par Amazon](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html) dans le manuel *Amazon Cognito Developer Guide*.
**Topics**
+ [
# Création de sources d' Amazon Cognito identité Amazon Verified Permissions
](cognito-create.md)
+ [
# Modification des sources d' Amazon Cognito identité Amazon Verified Permissions
](cognito-edit.md)
+ [
# Mappage Amazon Cognito des jetons au schéma
](cognito-map-token-to-schema.md)
+ [
# Validation du client et du public pour Amazon Cognito
](cognito-validation.md)
# Création de sources d' Amazon Cognito identité Amazon Verified Permissions
La procédure suivante ajoute une source d'identité à un magasin de politiques existant.
Vous pouvez également créer une source d'identité lorsque vous [créez un nouveau magasin de politiques](policy-stores-create.md) dans la console Verified Permissions. Au cours de ce processus, vous pouvez importer automatiquement les revendications contenues dans vos jetons de source d'identité dans les attributs des entités. Choisissez l'option **Configuration guidée ou Configuration** **avec API Gateway un fournisseur d'identité**. Ces options créent également des politiques initiales.
**Note**
**Les sources d'identité** ne sont pas disponibles dans le volet de navigation de gauche tant que vous n'avez pas créé un magasin de politiques. Les sources d'identité que vous créez sont associées au magasin de politiques actuel.
Vous pouvez omettre le type d'entité principal lorsque vous créez une source d'identité [create-identity-source](https://docs.aws.amazon.com/cli/latest/reference/verifiedpermissions/create-identity-source.html)dans AWS CLI ou [CreateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_CreateIdentitySource.html)dans l'API Verified Permissions. Toutefois, un type d'entité vide crée une source d'identité avec un type d'entité de`AWS::Cognito`. Ce nom d'entité n'est pas compatible avec le schéma Policy Store. Pour intégrer les Amazon Cognito identités à votre schéma de magasin de politiques, vous devez définir le type d'entité principal sur une entité de magasin de politiques prise en charge.
------
#### [ AWS Management Console ]
**Pour créer une source d'identité pour un pool d'utilisateurs Amazon Cognito**
1. Ouvrez la [console des autorisations vérifiées](https://console.aws.amazon.com/verifiedpermissions/). Choisissez votre magasin de polices.
1. Dans le volet de navigation de gauche, choisissez **Identity sources**.
1. Choisissez **Créer une source d'identité**.
1. Dans **Détails du groupe d'utilisateurs Cognito**, sélectionnez Région AWS et entrez l'**ID du groupe d'utilisateurs** pour votre source d'identité.
1. Dans **Configuration principale**, pour **Type principal**, choisissez le type d'entité pour les principaux à partir de cette source. Les identités issues des groupes d'utilisateurs Amazon Cognito connectés seront mappées au type principal sélectionné.
1. Dans **Configuration du groupe**, sélectionnez **Utiliser le groupe Cognito** si vous souhaitez mapper la réclamation du groupe d'utilisateurs. `cognito:groups` Choisissez un type d'entité parent du type principal.
1. Dans **Validation de l'application client**, choisissez si vous souhaitez valider l'application client IDs.
+ Pour valider l'application client IDs, sélectionnez **Accepter uniquement les jetons avec l'application client correspondante IDs**. Choisissez **Ajouter un nouvel ID d'application client** pour chaque ID d'application client à valider. Pour supprimer un ID d'application client qui a été ajouté, choisissez **Supprimer** à côté de l'ID d'application client.
+ Choisissez **Ne pas valider l'application cliente IDs** si vous ne souhaitez pas valider l'application cliente IDs.
1. Choisissez **Créer une source d'identité**.
1. (Facultatif) Si votre magasin de politiques possède un schéma, avant de pouvoir référencer les attributs que vous extrayez des jetons d'identité ou d'accès dans vos politiques Cedar, vous devez mettre à jour votre schéma pour informer Cedar du type de principal créé par votre source d'identité. Cet ajout au schéma doit inclure les attributs auxquels vous souhaitez faire référence dans vos politiques Cedar. Pour plus d'informations sur le mappage des attributs des Amazon Cognito jetons aux attributs principaux de Cedar, consultez[Mappage Amazon Cognito des jetons au schéma](cognito-map-token-to-schema.md).
**Note**
Lorsque vous créez un [magasin de politiques lié à une API](policy-stores-api-userpool.md) ou que vous utilisez **Configurer avec API Gateway un fournisseur d'identité** pour créer des magasins de politiques, Verified Permissions interroge votre groupe d'utilisateurs pour les attributs utilisateur et crée un schéma dans lequel votre type principal est renseigné avec les attributs du groupe d'utilisateurs.
1. Créez des politiques qui utilisent les informations des jetons pour prendre des décisions d'autorisation. Pour de plus amples informations, veuillez consulter [Création de politiques statiques relatives aux autorisations vérifiées par Amazon](policies-create.md).
Maintenant que vous avez créé une source d'identité, mis à jour le schéma et créé des politiques, les décisions `IsAuthorizedWithToken` d'autorisation sont prises par Verified Permissions. Pour plus d'informations, consultez le *guide [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)de référence de l'API Amazon Verified Permissions*.
------
#### [ AWS CLI ]
**Pour créer une source d'identité pour un pool d'utilisateurs Amazon Cognito**
Vous pouvez créer une source d'identité à l'aide de cette [CreateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_CreateIdentitySource.html)opération. L'exemple suivant crée une source d'identité qui peut accéder aux identités authentifiées à partir d'un groupe Amazon Cognito d'utilisateurs.
1. Créez un `config.txt` fichier contenant les informations suivantes sur le groupe Amazon Cognito d'utilisateurs à utiliser par le `--configuration` paramètre de la `create-identity-source` commande.
```
{
"cognitoUserPoolConfiguration": {
"userPoolArn": "arn:aws:cognito-idp:us-west-2:123456789012:userpool/us-west-2_1a2b3c4d5",
"clientIds":["a1b2c3d4e5f6g7h8i9j0kalbmc"],
"groupConfiguration": {
"groupEntityType": "MyCorp::UserGroup"
}
}
}
```
1. Exécutez la commande suivante pour créer une source Amazon Cognito d'identité.
```
$ aws verifiedpermissions create-identity-source \
--configuration file://config.txt \
--principal-entity-type "User" \
--policy-store-id 123456789012
{
"createdDate": "2023-05-19T20:30:28.214829+00:00",
"identitySourceId": "ISEXAMPLEabcdefg111111",
"lastUpdatedDate": "2023-05-19T20:30:28.214829+00:00",
"policyStoreId": "PSEXAMPLEabcdefg111111"
}
```
1. (Facultatif) Si votre magasin de politiques possède un schéma, avant de pouvoir référencer les attributs que vous extrayez des jetons d'identité ou d'accès dans vos politiques Cedar, vous devez mettre à jour votre schéma pour informer Cedar du type de principal créé par votre source d'identité. Cet ajout au schéma doit inclure les attributs auxquels vous souhaitez faire référence dans vos politiques Cedar. Pour plus d'informations sur le mappage des attributs des Amazon Cognito jetons aux attributs principaux de Cedar, consultez[Mappage Amazon Cognito des jetons au schéma](cognito-map-token-to-schema.md).
**Note**
Lorsque vous créez un [magasin de politiques lié à une API](policy-stores-api-userpool.md) ou que vous utilisez **Configurer avec API Gateway un fournisseur d'identité** pour créer des magasins de politiques, Verified Permissions interroge votre groupe d'utilisateurs pour les attributs utilisateur et crée un schéma dans lequel votre type principal est renseigné avec les attributs du groupe d'utilisateurs.
1. Créez des politiques qui utilisent les informations des jetons pour prendre des décisions d'autorisation. Pour de plus amples informations, veuillez consulter [Création de politiques statiques relatives aux autorisations vérifiées par Amazon](policies-create.md).
Maintenant que vous avez créé une source d'identité, mis à jour le schéma et créé des politiques, les décisions `IsAuthorizedWithToken` d'autorisation sont prises par Verified Permissions. Pour plus d'informations, consultez le *guide [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)de référence de l'API Amazon Verified Permissions*.
------
Pour plus d'informations sur l'utilisation des jetons d'accès et d'identité Amazon Cognito pour les utilisateurs authentifiés dans Verified Permissions, consultez la section Autorisation [avec Amazon Verified Permissions](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html) dans le guide du développeur *Amazon* Cognito.
# Modification des sources d' Amazon Cognito identité Amazon Verified Permissions
Vous pouvez modifier certains paramètres de votre source d'identité après l'avoir créée. Vous ne pouvez pas modifier le type de source d'identité, vous devez supprimer la source d'identité et en créer une nouvelle pour passer de l'OIDC à l'OIDC ou Amazon Cognito à l'OIDC. Amazon Cognito Si le schéma de votre magasin de politiques correspond aux attributs de votre source d'identité, notez que vous devez mettre à jour votre schéma séparément pour refléter les modifications que vous apportez à votre source d'identité.
------
#### [ AWS Management Console ]
**Pour mettre à jour une source Amazon Cognito d'identité**
1. Ouvrez la [console des autorisations vérifiées](https://console.aws.amazon.com/verifiedpermissions/). Choisissez votre magasin de polices.
1. Dans le volet de navigation de gauche, choisissez **Identity sources**.
1. Choisissez l'ID de la source d'identité à modifier.
1. Choisissez **Modifier**.
1. Dans **Détails du groupe d'utilisateurs Cognito**, sélectionnez Région AWS et saisissez l'**ID du groupe d'utilisateurs** pour votre source d'identité.
1. Dans **Détails du principal**, vous pouvez mettre à jour le **type principal** pour la source d'identité. Les identités issues des groupes d'utilisateurs Amazon Cognito connectés seront mappées au type principal sélectionné.
1. Dans **Configuration du groupe**, sélectionnez **Utiliser les groupes Cognito** si vous souhaitez mapper la réclamation du groupe d'utilisateurs. `cognito:groups` Choisissez un type d'entité parent du type principal.
1. Dans **Validation de l'application client**, choisissez si vous souhaitez valider l'application client IDs.
+ Pour valider l'application client IDs, sélectionnez **Accepter uniquement les jetons avec l'application client correspondante IDs**. Choisissez **Ajouter un nouvel ID d'application client** pour chaque ID d'application client à valider. Pour supprimer un ID d'application client qui a été ajouté, choisissez **Supprimer** à côté de l'ID d'application client.
+ Choisissez **Ne pas valider l'application cliente IDs** si vous ne souhaitez pas valider l'application cliente IDs.
1. Sélectionnez **Enregistrer les modifications**.
1. Si vous avez modifié le type principal de la source d'identité, vous devez mettre à jour votre schéma pour qu'il reflète correctement le type principal mis à jour.
Vous pouvez supprimer une source d'identité en cliquant sur le bouton radio à côté d'une source d'identité, puis en choisissant **Supprimer la source d'identité**. Tapez `delete` dans la zone de texte, puis choisissez **Supprimer la source d'identité** pour confirmer la suppression de la source d'identité.
------
#### [ AWS CLI ]
**Pour mettre à jour une source Amazon Cognito d'identité**
Vous pouvez mettre à jour une source d'identité à l'aide de [UpdateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_UpdateIdentitySource.html)cette opération. L'exemple suivant met à jour la source d'identité spécifiée pour utiliser un autre groupe Amazon Cognito d'utilisateurs.
1. Créez un `config.txt` fichier contenant les informations suivantes sur le groupe Amazon Cognito d'utilisateurs à utiliser par le `--configuration` paramètre de la `update-identity-source` commande.
```
{
"cognitoUserPoolConfiguration": {
"userPoolArn": "arn:aws:cognito-idp:us-west-2:123456789012:userpool/us-west-2_1a2b3c4d5",
"clientIds":["a1b2c3d4e5f6g7h8i9j0kalbmc"],
"groupConfiguration": {
"groupEntityType": "MyCorp::UserGroup"
}
}
}
```
1. Exécutez la commande suivante pour mettre à jour une source Amazon Cognito d'identité.
```
$ aws verifiedpermissions update-identity-source \
--update-configuration file://config.txt \
--policy-store-id 123456789012
{
"createdDate": "2023-05-19T20:30:28.214829+00:00",
"identitySourceId": "ISEXAMPLEabcdefg111111",
"lastUpdatedDate": "2023-05-19T20:30:28.214829+00:00",
"policyStoreId": "PSEXAMPLEabcdefg111111"
}
```
**Note**
Si vous modifiez le type principal de la source d'identité, vous devez mettre à jour votre schéma pour qu'il reflète correctement le type principal mis à jour.
------
# Mappage Amazon Cognito des jetons au schéma
Vous souhaiterez peut-être ajouter une source d'identité à un magasin de politiques et mapper les revendications, ou jetons, des fournisseurs de polices au schéma de votre magasin de politiques. Vous pouvez automatiser ce processus en utilisant la [configuration guidée](policy-stores-create.md) pour créer votre magasin de politiques avec une source d'identité, ou en mettant à jour votre schéma manuellement une fois le magasin de politiques créé. 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 les demandes de Amazon Cognito jetons dans vos politiques d'autorisations vérifiées
+ Comment créer manuellement un schéma pour une source d'identité
Les [magasins de politiques liés à l'API](policy-stores-api-userpool.md) et les magasins de politiques dotés d'une source d'identité créés par le biais de la [configuration guidée](policy-stores-create.md) 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 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 Amazon Cognito jetons à 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 à l'aide de l'API REST Verified Permissions, d'un AWS SDK ou du AWS CDK.
Pour l'utiliser Amazon Cognito 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. Le schéma est fixe et doit correspondre aux entités créées par les jetons du fournisseur [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)ou dans les demandes [BatchIsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_BatchIsAuthorizedWithToken.html)d'API. 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 au schéma des attributs de fournisseur qui correspondent aux entités créées à l'aide de demandes d'API. 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](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html) dans le guide du développeur *Amazon* Cognito.
**Topics**
+ [
## Associer les jetons d'identification au schéma
](#cognito-map-id-token)
+ [
## Cartographie des jetons d'accès
](#cognito-map-access-token)
+ [
## Notation alternative pour les revendications délimitées par des Amazon Cognito deux-points
](#cognito-colon-claims)
+ [
## Ce qu'il faut savoir sur le mappage de schémas
](#cognito-map-token-to-schema-things-to-know)
## 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 basé sur les attributs* (ABAC). 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é.
Amazon Cognito Les jetons d'identification fonctionnent avec la plupart des bibliothèques [dépendantes de l'OIDC](https://openid.net/developers/certified-openid-connect-implementations/). Ils étendent les fonctionnalités de l'OIDC avec des allégations supplémentaires. Votre application peut authentifier l'utilisateur à l'aide des opérations de l'API d'authentification 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 de l'API et des points de terminaison](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pools-API-operations.html) dans le *Guide du Amazon Cognito développeur*.Réclamations utiles sous forme de jetons Amazon Cognito d'identification
*`cognito:username` et `preferred_username`*
Variantes du nom d'utilisateur de l'utilisateur.
*`sub`*
Identifiant utilisateur unique (UUID) de l'utilisateur
*Réclamations comportant un `custom:` préfixe*
Un préfixe pour les attributs personnalisés du groupe d'utilisateurs tels que`custom:employmentStoreCode`.
*Réclamations standard*
Les allégations standard de l'OIDC telles que `email` et. `phone_number` Pour plus d'informations, consultez la section [Réclamations standard](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) d'*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](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-pre-token-generation.html). Les réclamations transitoires ressemblent aux réclamations standard mais ne sont pas conformes à la norme, par exemple `tenant` ou`department`.
Dans les politiques qui font référence à des Amazon Cognito attributs dotés d'un `:` séparateur, référencez les attributs dans le 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](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-id-token.html) dans le guide du *Amazon Cognito développeur*.
L'exemple de jeton d'identification suivant possède chacun des quatre types d'attributs. Elle inclut la réclamation Amazon Cognito spécifique`cognito:username`, la réclamation personnalisée`custom:employmentStoreCode`, la réclamation `email` standard et la réclamation 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 Amazon Cognito d'utilisateurs, vous spécifiez le type d'entité principale avec laquelle 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, consultez[Modification des schémas du magasin de politiques](schema-edit.md). Si la configuration de votre source d'identité spécifie le type principal`User`, 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, consultez[Reflète les attributs des jetons d' Amazon Cognito identification](policies-examples.md#policies-examples-cognito-id).
## 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 l'accès aux API. 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.
Amazon Cognito les jetons d'accès ont des revendications qui peuvent être utilisées à des fins d'autorisation :Réclamations utiles concernant les jetons Amazon Cognito d'accès
*`client_id`*
L'ID de l'application cliente d'une partie utilisatrice de l'OIDC. Avec 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](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3) 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](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-pre-token-generation.html). Les réclamations transitoires ressemblent aux réclamations standard mais ne sont pas conformes à la norme, par exemple `tenant` ou`department`. 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](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-access-token.html) dans le Guide du *Amazon Cognito développeur*.
Un jeton d' Amazon Cognito accè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 de`context.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, consultez[Modification des schémas du magasin de politiques](schema-edit.md).
```
{
"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, consultez[Reflète les attributs des jetons d' Amazon Cognito accès](policies-examples.md#policies-examples-cognito-access).
## Notation alternative pour les revendications délimitées par des Amazon Cognito deux-points
Au moment du lancement de Verified Permissions, le schéma recommandé pour les Amazon Cognito jetons réclamait `cognito:groups` et `custom:store` convertissait ces chaînes séparées par des points afin d'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](#cognito-map-token-to-schema-things-to-know). 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 Amazon Cognito d'identité. 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'IdP OIDC.
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, voir[Utilise la notation par points pour référencer les attributs](policies-examples.md#policies-examples-dot).
## 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](context.md). 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 le contrôle d'accès basé sur les rôles (RBAC) avec les demandes d'adhésion à un groupe et n'associe pas automatiquement les autres revendications au schéma du magasin 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.
**Le RBAC ne 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 **Set up with API Gateway and a identity provider** et **Guided setup** de la console Verified Permissions attribuent des droits 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 mode JSON et ajouter des attributs CommonTypes.](https://docs.cedarpolicy.com/schema/json-schema.html#schema-commonTypes) Pour de plus amples informations, veuillez consulter [Cartographie des jetons d'accès](#cognito-map-access-token).
**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 Amazon Cognito d'identité, vous avez le choix du type de jeton lorsque vous créez un magasin de politiques lié à une API. Lorsque vous créez un [magasin de politiques lié à une API](policy-stores-api-userpool.md), 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 API. API Gateway 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 que`principal.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"]` ou`context["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, consultez[Utilise la notation entre crochets pour référencer les attributs des jetons](policies-examples.md#policies-examples-brackets).
# Validation du client et du public pour Amazon Cognito
Lorsque vous ajoutez une source d'identité à un magasin de politiques, Verified Permissions propose des options de configuration qui vérifient que les jetons d'identification et d'accès sont utilisés comme prévu. Cette validation intervient lors du traitement `IsAuthorizedWithToken` des demandes `BatchIsAuthorizedWithToken` d'API. Le comportement diffère entre les jetons d'identification et d'accès, Amazon Cognito et entre les sources d'identité OIDC. Avec les fournisseurs de groupes d'utilisateurs Amazon Cognito, Verified Permissions peut valider l'ID client à la fois sous forme d'ID et de jetons d'accès. Avec les fournisseurs OIDC, Verified Permissions peut valider l'identifiant du client sous forme de jetons d'identification et l'audience sous forme de jetons d'accès.
Un *ID client* est un identifiant associé à l'instance du fournisseur d'identité utilisée par votre application, par exemple`1example23456789`. Une *audience* est un chemin d'URL associé à la *partie utilisatrice* prévue, ou à la destination, du jeton d'accès, par exemple`https://mytoken.example.com`. Lorsque vous utilisez des jetons d'accès, la `aud` réclamation est toujours associée au public.
Amazon Cognito Les jetons d'identification comportent une `aud` réclamation contenant l'ID du [client de l'application](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-client-apps.html). Les jetons d'accès ont une `client_id` réclamation qui contient également l'ID du client de l'application.
Lorsque vous entrez une ou plusieurs valeurs pour la **validation de l'application cliente** dans votre source d'identité, Verified Permissions compare cette liste de clients d'applications IDs à la demande de jeton d'identification ou à la `aud` demande de jeton `client_id` d'accès. Les autorisations vérifiées ne valident pas l'URL d'une audience tierce pour Amazon Cognito les sources d'identité.
## Autorisation côté client pour JWTs
Vous souhaiterez peut-être traiter les jetons Web JSON dans votre application et transmettre leurs demandes à Verified Permissions sans utiliser de source d'identité de magasin de politiques. Vous pouvez extraire les attributs de votre entité d'un jeton Web JSON (JWT) et les analyser en autorisations vérifiées.
Cet exemple montre comment vous pouvez appeler Verified Permissions depuis une application utilisant un JWT.¹
```
async function authorizeUsingJwtToken(jwtToken) {
const payload = await verifier.verify(jwtToken);
let principalEntity = {
entityType: "PhotoFlash::User", // the application needs to fill in the relevant user type
entityId: payload["sub"], // the application need to use the claim that represents the user-id
};
let resourceEntity = {
entityType: "PhotoFlash::Photo", //the application needs to fill in the relevant resource type
entityId: "jane_photo_123.jpg", // the application needs to fill in the relevant resource id
};
let action = {
actionType: "PhotoFlash::Action", //the application needs to fill in the relevant action id
actionId: "GetPhoto", //the application needs to fill in the relevant action type
};
let entities = {
entityList: [],
};
entities.entityList.push(...getUserEntitiesFromToken(payload));
let policyStoreId = "PSEXAMPLEabcdefg111111"; // set your own policy store id
const authResult = await client
.isAuthorized({
policyStoreId: policyStoreId,
principal: principalEntity,
resource: resourceEntity,
action: action,
entities,
})
.promise();
return authResult;
}
function getUserEntitiesFromToken(payload) {
let attributes = {};
let claimsNotPassedInEntities = ['aud', 'sub', 'exp', 'jti', 'iss'];
Object.entries(payload).forEach(([key, value]) => {
if (claimsNotPassedInEntities.includes(key)) {
return;
}
if (Array.isArray(value)) {
var attibuteItem = [];
value.forEach((item) => {
attibuteItem.push({
string: item,
});
});
attributes[key] = {
set: attibuteItem,
};
} else if (typeof value === 'string') {
attributes[key] = {
string: value,
}
} else if (typeof value === 'bigint' || typeof value ==='number') {
attributes[key] = {
long: value,
}
} else if (typeof value === 'boolean') {
attributes[key] = {
boolean: value,
}
}
});
let entityItem = {
attributes: attributes,
identifier: {
entityType: "PhotoFlash::User",
entityId: payload["sub"], // the application needs to use the claim that represents the user-id
}
};
return [entityItem];
}
```
¹ Cet exemple de code utilise la [aws-jwt-verify](https://github.com/awslabs/aws-jwt-verify)bibliothèque pour vérifier la JWTs signature par OIDC compatible IdPs.
# Travailler avec les sources d'identité OIDC
Vous pouvez également configurer n'importe quel IdP OpenID Connect (OIDC) conforme comme source d'identité d'un magasin de politiques. Les fournisseurs OIDC sont similaires aux groupes d'utilisateurs d'Amazon Cognito : ils JWTs produisent leurs produits en tant que produit d'authentification. Pour ajouter un fournisseur OIDC, vous devez fournir l'URL de l'émetteur
Une nouvelle source d'identité OIDC nécessite les informations suivantes :
+ URL de l'émetteur. Les autorisations vérifiées doivent être en mesure de découvrir un `.well-known/openid-configuration` point de terminaison à cette URL.
+ Enregistrements CNAME qui n'incluent pas de caractères génériques. Par exemple, ne `a.example.com` peut pas être mappé à`*.example.net`. Inversement, ne `*.example.com` peut pas être mappé à. `a.example.net`
+ Type de jeton que vous souhaitez utiliser dans les demandes d'autorisation. Dans ce cas, vous avez choisi le **jeton d'identité**.
+ Le type d'entité utilisateur que vous souhaitez associer à votre source d'identité, par exemple`MyCorp::User`.
+ Le type d'entité de groupe que vous souhaitez associer à votre source d'identité, par exemple`MyCorp::UserGroup`.
+ Exemple de jeton d'identification ou définition des revendications contenues dans le jeton d'identification.
+ Préfixe que vous souhaitez appliquer à l'entité IDs utilisateur et groupe. Dans la CLI et l'API, vous pouvez choisir ce préfixe. Dans les magasins de politiques que vous créez à l'aide de l'option **Set up with API Gateway and an identity provider** ou de l'option de **configuration guidée**, Verified Permissions attribue un préfixe au nom de l'émetteur moins`https://`, par exemple. `MyCorp::User::"auth.example.com|a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"`
Pour plus d'informations sur l'utilisation des opérations d'API pour autoriser les demandes provenant de sources OIDC, consultez[Opérations d'API disponibles pour l'autorisation](authorization.md#authorization-operations).
L'exemple suivant montre comment vous pouvez créer une politique qui autorise l'accès aux rapports de fin d'année aux employés du service de comptabilité, qui ont une classification confidentielle et qui ne travaillent pas dans un bureau satellite. Verified Permissions dérive ces attributs des allégations contenues dans le jeton d'identification du principal.
Notez que lorsque vous référencez un groupe dans le principal, vous devez utiliser l'`in`opérateur pour que la politique soit correctement évaluée.
```
permit(
principal in MyCorp::UserGroup::"MyOIDCProvider|Accounting",
action,
resource in MyCorp::Folder::"YearEnd2024"
) when {
principal.jobClassification == "Confidential" &&
!(principal.location like "SatelliteOffice*")
};
```
**Topics**
+ [
# Création de sources d'identité OIDC Amazon Verified Permissions
](oidc-create.md)
+ [
# Modification des sources d'identité OIDC d'Amazon Verified Permissions
](oidc-edit.md)
+ [
# Mappage des jetons OIDC au schéma
](oidc-map-token-to-schema.md)
+ [
# Validation du client et du public pour les fournisseurs OIDC
](oidc-validation.md)
# Création de sources d'identité OIDC Amazon Verified Permissions
La procédure suivante ajoute une source d'identité à un magasin de politiques existant.
Vous pouvez également créer une source d'identité lorsque vous [créez un nouveau magasin de politiques](policy-stores-create.md) dans la console Verified Permissions. Au cours de ce processus, vous pouvez importer automatiquement les revendications contenues dans vos jetons de source d'identité dans les attributs des entités. Choisissez l'option **Configuration guidée ou Configuration** **avec API Gateway un fournisseur d'identité**. Ces options créent également des politiques initiales.
**Note**
**Les sources d'identité** ne sont pas disponibles dans le volet de navigation de gauche tant que vous n'avez pas créé un magasin de politiques. Les sources d'identité que vous créez sont associées au magasin de politiques actuel.
Vous pouvez omettre le type d'entité principal lorsque vous créez une source d'identité [create-identity-source](https://docs.aws.amazon.com/cli/latest/reference/verifiedpermissions/create-identity-source.html)dans AWS CLI ou [CreateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_CreateIdentitySource.html)dans l'API Verified Permissions. Cependant, un type d'entité vide crée une source d'identité avec un type d'entité de`AWS::Cognito`. Ce nom d'entité n'est pas compatible avec le schéma Policy Store. Pour intégrer les Amazon Cognito identités à votre schéma de magasin de politiques, vous devez définir le type d'entité principal sur une entité de magasin de politiques prise en charge.
------
#### [ AWS Management Console ]
**Pour créer une source d'identité OpenID Connect (OIDC)**
1. Ouvrez la [console des autorisations vérifiées](https://console.aws.amazon.com/verifiedpermissions/). Choisissez votre magasin de polices.
1. Dans le volet de navigation de gauche, choisissez **Identity sources**.
1. Choisissez **Créer une source d'identité**.
1. Choisissez un **fournisseur OIDC externe**.
1. Dans **URL de l'émetteur**, entrez l'URL de votre émetteur OIDC. Il s'agit du point de terminaison du service qui fournit le serveur d'autorisation, les clés de signature et d'autres informations sur votre fournisseur, par exemple`https://auth.example.com`. L'URL de votre émetteur doit héberger un document de découverte OIDC à l'adresse. `/.well-known/openid-configuration`
1. Dans **Type de jeton**, choisissez le type de JWT OIDC que vous souhaitez que votre demande soumette pour autorisation. Pour de plus amples informations, veuillez consulter [Mappage des jetons OIDC au schéma](oidc-map-token-to-schema.md).
1. Dans **Map token claims to schema entities**, choisissez une **entité User** et **User claim** pour la source d'identité. L'**entité utilisateur** est une entité de votre magasin de politiques à laquelle vous souhaitez faire référence aux utilisateurs de votre fournisseur OIDC. La **réclamation de l'utilisateur** est généralement `sub` une réclamation provenant de votre identifiant ou de votre jeton d'accès qui contient l'identifiant unique de l'entité à évaluer. Les identités de l'IdP OIDC connecté seront mappées au type principal sélectionné.
1. (Facultatif) Dans les **revendications de jeton de carte relatives à des entités de schéma**, choisissez une **entité** de **groupe et une revendication** de groupe pour la source d'identité. L'**entité Group** est le [parent](https://docs.cedarpolicy.com/overview/terminology.html#term-group) de l'**entité User**. Les revendications de groupe sont mappées à cette entité. La **réclamation de groupe** est généralement `groups` une réclamation provenant de votre identifiant ou de votre jeton d'accès qui contient une chaîne, un JSON ou une chaîne de noms de groupes d'utilisateurs délimitée par des espaces pour l'entité à évaluer. Les identités de l'IdP OIDC connecté seront mappées au type principal sélectionné.
1. Dans **Validation (facultatif)**, entrez le client IDs ou le public URLs que vous souhaitez que votre magasin de politiques accepte dans les demandes d'autorisation, le cas échéant.
1. Choisissez **Créer une source d'identité**.
1. (Facultatif) Si votre magasin de politiques possède un schéma, avant de pouvoir référencer les attributs que vous extrayez des jetons d'identité ou d'accès dans vos politiques Cedar, vous devez mettre à jour votre schéma pour informer Cedar du type de principal créé par votre source d'identité. Cet ajout au schéma doit inclure les attributs auxquels vous souhaitez faire référence dans vos politiques Cedar. Pour plus d'informations sur le mappage des attributs des jetons OIDC aux attributs principaux de Cedar, consultez[Mappage des jetons OIDC au schéma](oidc-map-token-to-schema.md).
1. Créez des politiques qui utilisent les informations des jetons pour prendre des décisions d'autorisation. Pour de plus amples informations, veuillez consulter [Création de politiques statiques relatives aux autorisations vérifiées par Amazon](policies-create.md).
Maintenant que vous avez créé une source d'identité, mis à jour le schéma et créé des politiques, les décisions `IsAuthorizedWithToken` d'autorisation sont prises par Verified Permissions. Pour plus d'informations, consultez le *guide [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)de référence de l'API Amazon Verified Permissions*.
------
#### [ AWS CLI ]
**Pour créer une source d'identité OIDC**
Vous pouvez créer une source d'identité à l'aide de cette [CreateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_CreateIdentitySource.html)opération. L'exemple suivant crée une source d'identité qui peut accéder aux identités authentifiées auprès d'un fournisseur d'identité OIDC (IdP).
1. Créez un `config.txt` fichier contenant les détails suivants d'un IdP OIDC à utiliser par `--configuration` le paramètre de `create-identity-source` la commande.
```
{
"openIdConnectConfiguration": {
"issuer": "https://auth.example.com",
"tokenSelection": {
"identityTokenOnly": {
"clientIds":["1example23456789"],
"principalIdClaim": "sub"
},
},
"entityIdPrefix": "MyOIDCProvider",
"groupConfiguration": {
"groupClaim": "groups",
"groupEntityType": "MyCorp::UserGroup"
}
}
}
```
1. Exécutez la commande suivante pour créer une source d'identité OIDC.
```
$ aws verifiedpermissions create-identity-source \
--configuration file://config.txt \
--principal-entity-type "User" \
--policy-store-id 123456789012
{
"createdDate": "2023-05-19T20:30:28.214829+00:00",
"identitySourceId": "ISEXAMPLEabcdefg111111",
"lastUpdatedDate": "2023-05-19T20:30:28.214829+00:00",
"policyStoreId": "PSEXAMPLEabcdefg111111"
}
```
1. (Facultatif) Si votre magasin de politiques possède un schéma, avant de pouvoir référencer les attributs que vous extrayez des jetons d'identité ou d'accès dans vos politiques Cedar, vous devez mettre à jour votre schéma pour informer Cedar du type de principal créé par votre source d'identité. Cet ajout au schéma doit inclure les attributs auxquels vous souhaitez faire référence dans vos politiques Cedar. Pour plus d'informations sur le mappage des attributs des jetons OIDC aux attributs principaux de Cedar, consultez[Mappage des jetons OIDC au schéma](oidc-map-token-to-schema.md).
1. Créez des politiques qui utilisent les informations des jetons pour prendre des décisions d'autorisation. Pour de plus amples informations, veuillez consulter [Création de politiques statiques relatives aux autorisations vérifiées par Amazon](policies-create.md).
Maintenant que vous avez créé une source d'identité, mis à jour le schéma et créé des politiques, les décisions `IsAuthorizedWithToken` d'autorisation sont prises par Verified Permissions. Pour plus d'informations, consultez le *guide [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)de référence de l'API Amazon Verified Permissions*.
------
# Modification des sources d'identité OIDC d'Amazon Verified Permissions
Vous pouvez modifier certains paramètres de votre source d'identité après l'avoir créée. Vous ne pouvez pas modifier le type de source d'identité, vous devez supprimer la source d'identité et en créer une nouvelle pour passer de l'OIDC à l'OIDC ou Amazon Cognito à l'OIDC. Amazon Cognito Si le schéma de votre magasin de politiques correspond aux attributs de votre source d'identité, notez que vous devez mettre à jour votre schéma séparément pour refléter les modifications que vous apportez à votre source d'identité.
------
#### [ AWS Management Console ]
**Pour mettre à jour une source d'identité OIDC**
1. Ouvrez la [console des autorisations vérifiées](https://console.aws.amazon.com/verifiedpermissions/). Choisissez votre magasin de polices.
1. Dans le volet de navigation de gauche, choisissez **Identity sources**.
1. Choisissez l'ID de la source d'identité à modifier.
1. Choisissez **Modifier**.
1. Dans les **détails du fournisseur OIDC**, modifiez l'**URL de l'émetteur selon vos besoins**.
1. Dans **Map token claims to schema attributes**, modifiez les associations entre les revendications d'utilisateur et de groupe et les types d'entités du policy store, selon les besoins. Après avoir modifié les types d'entités, vous devez mettre à jour vos politiques et les attributs de schéma pour les appliquer aux nouveaux types d'entités.
1. Dans **Validation** de l'audience, ajoutez ou supprimez les valeurs d'audience que vous souhaitez appliquer.
1. Sélectionnez **Enregistrer les modifications**.
Vous pouvez supprimer une source d'identité en cliquant sur le bouton radio à côté d'une source d'identité, puis en choisissant **Supprimer la source d'identité**. Tapez `delete` dans la zone de texte, puis choisissez **Supprimer la source d'identité** pour confirmer la suppression de la source d'identité.
------
#### [ AWS CLI ]
**Pour mettre à jour une source d'identité OIDC**
Vous pouvez mettre à jour une source d'identité à l'aide de [UpdateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_UpdateIdentitySource.html)cette opération. L'exemple suivant met à jour la source d'identité spécifiée pour utiliser un autre fournisseur OIDC.
1. Créez un `config.txt` fichier contenant les détails suivants d'un IdP OIDC à utiliser par `--configuration` le paramètre de `update-identity-source` la commande.
```
{
"openIdConnectConfiguration": {
"issuer": "https://auth2.example.com",
"tokenSelection": {
"identityTokenOnly": {
"clientIds":["2example10111213"],
"principalIdClaim": "sub"
},
},
"entityIdPrefix": "MyOIDCProvider",
"groupConfiguration": {
"groupClaim": "groups",
"groupEntityType": "MyCorp::UserGroup"
}
}
}
```
1. Exécutez la commande suivante pour mettre à jour une source d'identité OIDC.
```
$ aws verifiedpermissions update-identity-source \
--update-configuration file://config.txt \
--policy-store-id 123456789012
{
"createdDate": "2023-05-19T20:30:28.214829+00:00",
"identitySourceId": "ISEXAMPLEabcdefg111111",
"lastUpdatedDate": "2023-05-19T20:30:28.214829+00:00",
"policyStoreId": "PSEXAMPLEabcdefg111111"
}
```
**Note**
Si vous modifiez le type principal de la source d'identité, vous devez mettre à jour votre schéma pour qu'il reflète correctement le type principal mis à jour.
------
# Mappage des jetons OIDC au schéma
Vous souhaiterez peut-être ajouter une source d'identité à un magasin de politiques et mapper les revendications, ou jetons, des fournisseurs de polices au schéma de votre magasin de politiques. Vous pouvez automatiser ce processus en utilisant la [configuration guidée](policy-stores-create.md) pour créer votre magasin de politiques avec une source d'identité, ou en mettant à jour votre schéma manuellement une fois le magasin de politiques créé. 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 créer manuellement un schéma pour une source d'identité
Les [magasins de politiques liés à l'API](policy-stores-api-userpool.md) et les magasins de politiques dotés d'une source d'identité créés par le biais de la [configuration guidée](policy-stores-create.md) 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 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.
Pour utiliser un fournisseur d'identité OIDC (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. Le schéma est fixe et doit correspondre aux entités créées par les jetons du fournisseur [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)ou dans les demandes [BatchIsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_BatchIsAuthorizedWithToken.html)d'API. 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 au schéma des attributs de fournisseur qui correspondent aux entités créées à l'aide de demandes d'API. Vous pouvez ensuite écrire des politiques à l'aide des attributs du jeton du fournisseur.
**Topics**
+ [
## Associer les jetons d'identification au schéma
](#oidc-map-id-token)
+ [
## Cartographie des jetons d'accès
](#oidc-map-access-token)
+ [
## Ce qu'il faut savoir sur le mappage de schémas
](#oidc-map-token-to-schema-things-to-know)
## 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 basé sur les attributs* (ABAC). 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é.
Travailler avec des jetons d'identification d'un fournisseur OIDC revient à peu près à travailler avec des jetons Amazon Cognito d'identification. La différence réside dans les réclamations. Votre IdP peut présenter des [attributs OIDC standard](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) 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 d'identité OIDC avec un exemple de jeton d'identification, ou vous pouvez associer manuellement les demandes de jeton 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](policy-stores-create.md).
Voici un exemple de schéma pour un magasin de politiques avec une source d'identité OIDC.
```
"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, consultez[Reflète les attributs du jeton d'identification OIDC](policies-examples.md#policies-examples-oidc-id).
## 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 l'accès aux API. 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.
La plupart des jetons d'accès provenant de fournisseurs OIDC externes s'alignent étroitement sur les jetons d' Amazon Cognito accès. Un jeton d'accès OIDC 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 de`context.token.attribute_name`. L'exemple de jeton d'accès OIDC 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, consultez[Modification des schémas du magasin de politiques](schema-edit.md).
```
{
"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, consultez[Reflète les attributs du jeton d'accès OIDC](policies-examples.md#policies-examples-oidc-access).
## 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](context.md). 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 le contrôle d'accès basé sur les rôles (RBAC) avec les demandes d'adhésion à un groupe et n'associe pas automatiquement les autres revendications au schéma du magasin 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.
**Le RBAC ne 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 **Set up with API Gateway and a identity provider** et **Guided setup** de la console Verified Permissions attribuent des droits 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 mode JSON et ajouter des attributs CommonTypes.](https://docs.cedarpolicy.com/schema/json-schema.html#schema-commonTypes) Pour de plus amples informations, veuillez consulter [Cartographie des jetons d'accès](#oidc-map-access-token).
**Les groupes OIDC affirment prendre en charge plusieurs formats**
Lorsque vous ajoutez un fournisseur OIDC, vous pouvez choisir le nom de la réclamation du groupe 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"`
1. Liste délimitée par des espaces :. `"groups": "MyGroup1 MyGroup2 MyGroup3"` Chaque chaîne est un groupe.
1. Liste JSON (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` comme`MyGroup`.
**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 OIDC, 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 que`principal.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"]` ou`context["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, consultez[Utilise la notation entre crochets pour référencer les attributs des jetons](policies-examples.md#policies-examples-brackets).
# Validation du client et du public pour les fournisseurs OIDC
Lorsque vous ajoutez une source d'identité à un magasin de politiques, Verified Permissions propose des options de configuration qui vérifient que les jetons d'identification et d'accès sont utilisés comme prévu. Cette validation intervient lors du traitement `IsAuthorizedWithToken` des demandes `BatchIsAuthorizedWithToken` d'API. Le comportement diffère entre les jetons d'identification et d'accès, Amazon Cognito et entre les sources d'identité OIDC. Avec les fournisseurs de groupes d'utilisateurs Amazon Cognito, Verified Permissions peut valider l'ID client à la fois sous forme d'ID et de jetons d'accès. Avec les fournisseurs OIDC, Verified Permissions peut valider l'identifiant du client sous forme de jetons d'identification et l'audience sous forme de jetons d'accès.
Un *ID client* est un identifiant associé à l'instance du fournisseur d'identité utilisée par votre application, par exemple`1example23456789`. Une *audience* est un chemin d'URL associé à la *partie utilisatrice* prévue, ou à la destination, du jeton d'accès, par exemple`https://mytoken.example.com`. Lorsque vous utilisez des jetons d'accès, la `aud` réclamation est toujours associée au public.
Les jetons d'identification OIDC ont une `aud` réclamation qui contient un client IDs, telle que`1example23456789`.
Les jetons d'accès OIDC ont une `aud` réclamation qui contient l'URL d'audience du jeton, telle que`https://myapplication.example.com`, et une `client_id` réclamation qui contient le client IDs, telle que`1example23456789`.
Lorsque vous configurez votre magasin de politiques, entrez une ou plusieurs valeurs pour la **validation d'audience** que votre magasin de politiques utilisera pour valider l'audience d'un jeton.
+ **Jetons d'identification** — Verified Permissions valide l'identifiant du client en vérifiant qu'au moins un membre du client indiqué IDs dans la `aud` réclamation correspond à une valeur de validation d'audience.
+ **Jetons d'accès** : les autorisations vérifiées valident l'audience en vérifiant que l'URL figurant dans la `aud` réclamation correspond à une valeur de validation de l'audience. Si aucune `aud` réclamation n'existe, l'audience peut être validée à l'aide des `client_id` revendications `cid` or. Vérifiez auprès de votre fournisseur d'identité la bonne déclaration d'audience et le bon format.
## Autorisation côté client pour JWTs
Vous souhaiterez peut-être traiter les jetons Web JSON dans votre application et transmettre leurs demandes à Verified Permissions sans utiliser de source d'identité de magasin de politiques. Vous pouvez extraire les attributs de votre entité d'un jeton Web JSON (JWT) et les analyser en autorisations vérifiées.
Cet exemple montre comment vous pouvez appeler Verified Permissions depuis une application utilisant un JWT.¹
```
async function authorizeUsingJwtToken(jwtToken) {
const payload = await verifier.verify(jwtToken);
let principalEntity = {
entityType: "PhotoFlash::User", // the application needs to fill in the relevant user type
entityId: payload["sub"], // the application need to use the claim that represents the user-id
};
let resourceEntity = {
entityType: "PhotoFlash::Photo", //the application needs to fill in the relevant resource type
entityId: "jane_photo_123.jpg", // the application needs to fill in the relevant resource id
};
let action = {
actionType: "PhotoFlash::Action", //the application needs to fill in the relevant action id
actionId: "GetPhoto", //the application needs to fill in the relevant action type
};
let entities = {
entityList: [],
};
entities.entityList.push(...getUserEntitiesFromToken(payload));
let policyStoreId = "PSEXAMPLEabcdefg111111"; // set your own policy store id
const authResult = await client
.isAuthorized({
policyStoreId: policyStoreId,
principal: principalEntity,
resource: resourceEntity,
action: action,
entities,
})
.promise();
return authResult;
}
function getUserEntitiesFromToken(payload) {
let attributes = {};
let claimsNotPassedInEntities = ['aud', 'sub', 'exp', 'jti', 'iss'];
Object.entries(payload).forEach(([key, value]) => {
if (claimsNotPassedInEntities.includes(key)) {
return;
}
if (Array.isArray(value)) {
var attibuteItem = [];
value.forEach((item) => {
attibuteItem.push({
string: item,
});
});
attributes[key] = {
set: attibuteItem,
};
} else if (typeof value === 'string') {
attributes[key] = {
string: value,
}
} else if (typeof value === 'bigint' || typeof value ==='number') {
attributes[key] = {
long: value,
}
} else if (typeof value === 'boolean') {
attributes[key] = {
boolean: value,
}
}
});
let entityItem = {
attributes: attributes,
identifier: {
entityType: "PhotoFlash::User",
entityId: payload["sub"], // the application needs to use the claim that represents the user-id
}
};
return [entityItem];
}
```
¹ Cet exemple de code utilise la [aws-jwt-verify](https://github.com/awslabs/aws-jwt-verify)bibliothèque pour vérifier la JWTs signature par OIDC compatible IdPs.