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. # 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.