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

Associer les jetons Amazon Cognito 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 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 :

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

Pour 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 IsAuthorizedWithTokenou dans les demandes BatchIsAuthorizedWithTokend'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 dans le guide du développeur Amazon Cognito.

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

Les jetons d'identification Amazon Cognito fonctionnent avec la plupart des bibliothèques dépendantes OIDC. 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 dans le manuel Amazon Cognito Developer Guide.

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

Notation alternative pour les demandes délimitées par des deux-points sur Amazon Cognito

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

Vous pouvez continuer à utiliser la notation par points dans le schéma et les politiques créés manuellement pour les sources d'identité Amazon Cognito. Vous ne pouvez pas utiliser la notation par points : ou tout autre caractère non alphanumérique dans le schéma ou les politiques pour tout autre type d'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, voirUtilise la notation par points pour référencer les attributs.

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

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

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

Choisissez un type de jeton

La façon dont votre magasin de politiques fonctionne avec votre source d'identité dépend d'une décision clé en matière de configuration de la source d'identité : traiter les identifiants ou les jetons d'accès. Avec un fournisseur d'identité Amazon Cognito, vous pouvez choisir le type de jeton lorsque vous créez un magasin de politiques lié à une API. Lorsque vous créez un magasin de politiques lié à une API, 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 queprincipal.username. Dans le cas de la plupart des caractères non alphanumériques tels / que :., ou susceptibles d'apparaître dans les noms de réclamation de jetons, Verified Permissions ne peut pas analyser une valeur de condition telle que ou. principal.cognito:username context.ip-address Vous devez plutôt mettre en forme ces conditions avec une notation entre crochets dans le format principal["cognito:username"] oucontext["ip-address"], respectivement. Le caractère de soulignement _ est un caractère valide dans les noms des demandes et constitue la seule exception non alphanumérique à cette exigence.

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

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

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

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

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