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.

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

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

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

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

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

Voici un exemple de schéma pour un magasin de politiques 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, consultezReflète les attributs du jeton d'identification OIDC.

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 sont étroitement liés aux jetons d'accès Amazon Cognito. 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 decontext.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, 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 OIDC.

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 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. Pour de plus amples informations, veuillez consulter Cartographie des jetons d'accès.

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 :

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