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.
Autorisation avec Amazon Verified Permissions
Amazon Verified Permissions est un service d'autorisation pour les applications que vous créez. Lorsque vous ajoutez un groupe d'utilisateurs Amazon Cognito comme source d'identité, votre application peut transmettre des jetons d'accès au groupe d'utilisateurs ou d'identité (ID) à Verified Permissions pour une décision d'autorisation ou de refus. Verified Permissions prend en compte les propriétés de votre utilisateur et le contexte de la demande en fonction des politiques que vous rédigez en langage de politique Cedar
Votre application peut fournir l'identité de votre utilisateur ou des jetons d'accès aux autorisations vérifiées dans IsAuthorizedWithTokenou dans les BatchIsAuthorizedWithTokenAPIdemandes. Ces API opérations acceptent vos utilisateurs en tant que tels Principal
et prennent des décisions d'autorisation pour Resource
celui auquel ils souhaitent accéder. Action
Une personnalisation supplémentaire Context
peut contribuer à une décision d'accès détaillée.
Lorsque votre application présente un jeton dans une IsAuthorizedWithToken
API demande, Verified Permissions effectue les validations suivantes.
-
Votre groupe d'utilisateurs est une source d'identité Verified Permissions configurée pour le magasin de politiques demandé.
-
Le champ standard
client_id
ouaud
, dans votre jeton d'accès ou d'identité respectivement, correspond à l'ID client d'application de groupe d'utilisateurs que vous avez fourni à Verified Permissions. Pour vérifier ce champ standard, vous devez configurer la validation de l'ID client dans votre source d'identité Verified Permissions. -
Votre jeton n'a pas expiré.
-
La valeur de la
token_use
réclamation contenue dans votre jeton correspond aux paramètres que vous avez transmisIsAuthorizedWithToken
. Latoken_use
réclamation doit êtreaccess
si vous l'avez transmise auaccessToken
paramètre etid
si vous l'avez transmise auidentityToken
paramètre. -
La signature de votre jeton provient des clés JSON Web publiées (JWKs) de votre groupe d'utilisateurs. Vous pouvez consulter votre JWKs at
https://cognito-idp.
.Region
.amazonaws.com/your user pool ID
/.well-known/jwks.json
Jetons révoqués et utilisateurs supprimés
Verified Permissions ne valide que les informations qu'il obtient de votre source d'identité et depuis l'expiration du jeton de votre utilisateur. Verified Permissions ne recherche pas la révocation du jeton ni l'existence de l'utilisateur. Si vous avez révoqué le jeton de votre utilisateur ou supprimé le profil de votre utilisateur de votre groupe d'utilisateurs, Verified Permissions considère toujours le jeton comme valide jusqu'à son expiration.
Évaluation des politiques
Configurez votre groupe d'utilisateurs en tant que source d'identité pour votre magasin de politiques. Configurez votre application pour envoyer les jetons de vos utilisateurs dans les demandes à Verified Permissions. Pour chaque demande, Verified Permissions compare les champs standard du jeton à une politique. Une politique d'autorisations vérifiées est similaire à une IAM politique dans AWS. Elle déclare un principal, une ressource et une action. Verified Permissions répond à votre demande Allow
si elle correspond à une action autorisée et non à une Deny
action explicite ; sinon, elle répond parDeny
. Pour plus d'informations, consultez Politiques Amazon Verified Permissions dans le Guide de l'utilisateur Amazon Verified Permissions.
Personnalisation des jetons
Pour modifier, ajouter et supprimer les demandes d'utilisateur que vous souhaitez présenter à Verified Permissions, personnalisez le contenu de vos jetons d'accès et d'identité avec unDéclencheur Lambda avant génération de jeton. Un déclencheur avant génération de jeton vous permet d'ajouter et de modifier des champs standard dans vos jetons. Par exemple, vous pouvez interroger une base de données pour obtenir des attributs utilisateur supplémentaires et les encoder dans votre jeton d'identité.
Note
En raison de la façon dont Verified Permissions traite les champs standard, n'ajoutez pas de champs standard nommés cognito
, dev
ou custom
dans votre fonction avant génération de jeton. Lorsque vous présentez ces préfixes de champ standard réservés non pas dans un format délimité par des deux-points, tel que cognito:username
, mais sous forme de noms de champs standard complets, vos demandes d'autorisation échouent.
Ressources supplémentaires
APIautorisation avec autorisations vérifiées
Votre identifiant ou vos jetons d'accès peuvent autoriser les demandes adressées au back-end Amazon API Gateway REST APIs avec des autorisations vérifiées. Vous pouvez créer un magasin de politiques avec des liens immédiats vers votre groupe d'utilisateurs etAPI. Avec l'option de démarrage Configurer avec Cognito et API Gateway, Verified Permissions ajoute une source d'identité de groupe d'utilisateurs au magasin de politiques et un autorisateur Lambda au. API Lorsque votre application transmet un jeton porteur d'un pool d'utilisateurs auAPI, l'autorisateur Lambda invoque les autorisations vérifiées. L'autorisateur transmet le jeton en tant que principal et le chemin et la méthode de la demande en tant qu'action.
Le schéma suivant illustre le flux d'autorisation pour une API passerelle API avec des autorisations vérifiées. Pour une analyse détaillée, consultez les boutiques politiques API liées à -linked dans le guide de l'utilisateur Amazon Verified Permissions.
![Schéma illustrant le flux d'APIautorisation avec Amazon Verified Permissions. Une application envoie une demande à Amazon API GatewayAPI. APIInvoque un autorisateur Lambda. L'autorisateur fait une API demande à Verified Permissions. Verified Permissions vérifie la validité du jeton et renvoie une décision d'autorisation.](images/amazon-cognito-avp-use-case.png)
Les autorisations vérifiées structurent API l'autorisation en fonction des groupes de groupes d'utilisateurs. Étant donné que les jetons d'identification et d'accès incluent une cognito:groups
réclamation, votre magasin de politiques peut gérer le contrôle d'accès basé sur les rôles (RBAC) pour vous APIs dans divers contextes d'application.
Choix des paramètres du Policy Store
Lorsque vous configurez une source d'identité sur un magasin de politiques, vous devez choisir si vous souhaitez traiter l'accès ou les jetons d'identification. Cette décision est importante pour le fonctionnement de votre moteur de politiques. Les jetons d'identification contiennent des attributs utilisateur. Les jetons d'accès contiennent des informations de contrôle d'accès utilisateur : OAuth scopes. Bien que les deux types de jetons contiennent des informations sur l'appartenance à un groupe, nous recommandons généralement le jeton d'accès RBAC associé à un magasin de politiques d'autorisations vérifiées. Le jeton d'accès ajoute à l'appartenance au groupe des étendues qui peuvent contribuer à la décision d'autorisation. Les revendications contenues dans un jeton d'accès deviennent contextuelles dans la demande d'autorisation.
Vous devez également configurer les types d'entités d'utilisateur et de groupe lorsque vous configurez un groupe d'utilisateurs comme source d'identité. Les types d'entités sont des identifiants principaux, d'action et de ressources auxquels vous pouvez faire référence dans les politiques d'autorisations vérifiées. Les entités des magasins de politiques peuvent avoir une relation d'adhésion, dans laquelle une entité peut être membre d'une entité parent. Avec l'adhésion, vous pouvez référencer des groupes principaux, des groupes d'action et des groupes de ressources. Dans le cas de groupes de groupes d'utilisateurs, le type d'entité utilisateur que vous spécifiez doit être membre du type d'entité de groupe. Lorsque vous configurez un magasin de politiques API lié ou que vous suivez la procédure de configuration guidée dans la console des autorisations vérifiées, votre magasin de politiques entretient automatiquement cette relation parent-membre.
Le jeton d'identification peut être combiné RBAC avec le contrôle d'accès basé sur les attributs ()ABAC. Après avoir créé un magasin de règles API lié, vous pouvez améliorer vos politiques avec des attributs utilisateur et l'appartenance à un groupe. Les revendications d'attributs contenues dans un jeton d'identification deviennent les attributs principaux de la demande d'autorisation. Vos politiques peuvent prendre des décisions d'autorisation en fonction des principaux attributs.
Vous pouvez également configurer un magasin de politiques pour qu'il accepte les jetons avec une client_id
réclamation aud
ou une réclamation correspondant à une liste de clients d'applications acceptables que vous fournissez.
Exemple de politique d'autorisation basée sur les rôles API
L'exemple de politique suivant a été créé par la configuration d'un magasin de politiques d'autorisations vérifiées PetStorepar exemple RESTAPI.
permit( principal in PetStore::UserGroup::"us-east-1_EXAMPLE|MyGroup", action in [ PetStore::Action::"get /pets", PetStore::Action::"get /pets/{petId}" ], resource );
Verified Permissions renvoie une Allow
décision à la demande d'autorisation de votre application lorsque :
-
Votre application a transmis un identifiant ou un jeton d'accès dans un
Authorization
en-tête en tant que jeton porteur. -
Votre application a transmis un jeton avec une
cognito:groups
réclamation contenant la chaîneMyGroup
. -
Votre application a fait une
HTTP GET
demande à, par exemple,https://myapi.example.com/pets
ouhttps://myapi.example.com/pets/scrappy
.
Exemple de politique pour un utilisateur Amazon Cognito
Votre groupe d'utilisateurs peut également générer des demandes d'autorisation à Verified Permissions dans des conditions autres que les API demandes. Vous pouvez soumettre toutes les décisions de contrôle d'accès de votre application à votre magasin de politiques. Par exemple, vous pouvez renforcer la sécurité d'Amazon DynamoDB ou d'Amazon S3 par un contrôle d'accès basé sur les attributs avant que les demandes ne transitent par le réseau, réduisant ainsi l'utilisation des quotas.
L'exemple suivant utilise le langage de politique Cedarexample_image.png
. John, un utilisateur de votre application, reçoit un jeton d'identification de la part de votre client d'application et le transmet dans une GET demande à une URL personne nécessitant une autorisation,https://example.com/images/example_image.png
. Le jeton d'identité de John a un champ standard aud
de votre ID client d'application de groupe d'utilisateurs 1234567890example
. Votre fonction Lambda avant génération de jeton a également inséré un nouveau champ standard costCenter
avec une valeur, pour John, de Finance1234
.
permit ( principal, actions in [ExampleCorp::Action::"readFile", "writeFile"], resource == ExampleCorp::Photo::"example_image.png" ) when { principal.aud == "1234567890example" && principal.custom.costCenter like "Finance*" };
Le corps de demande suivant entraîne la réponse Allow
.
{ "accesstoken": "
[John's ID token]
", "action": { "actionId": "readFile", "actionType": "Action" }, "resource": { "entityId": "example_image.png", "entityType": "Photo" } }
Lorsque vous souhaitez spécifier un principal dans une politique Verified Permissions, utilisez le format suivant :
permit ( principal == [Namespace]::[Entity]::"[user pool ID]"|"[user sub]", action, resource );
Voici un exemple de principal pour un utilisateur d'un groupe d'utilisateurs dont l'ID us-east-1_Example
est accompagné d'un sub, ou d'un ID utilisateur,973db890-092c-49e4-a9d0-912a4c0a20c7
.
principal ==
ExampleCorp
::User
::"us-east-1_Example
|973db890-092c-49e4-a9d0-912a4c0a20c7
",
Lorsque vous souhaitez spécifier un groupe d'utilisateurs dans une politique d'autorisations vérifiées, utilisez le format suivant :
permit ( principal in [Namespace]::[Group Entity]::"[Group name]", action, resource );
Ce qui suit est un exemple
Contrôle d'accès basé sur les attributs
L'autorisation avec autorisations vérifiées pour vos applications et les attributs pour la fonctionnalité de contrôle d'accès des groupes d'identités Amazon Cognito pour les AWS informations d'identification sont deux formes de contrôle d'accès basé sur les attributs (). ABAC Vous trouverez ci-dessous une comparaison des fonctionnalités de Verified Permissions et d'Amazon CognitoABAC. DansABAC, un système examine les attributs d'une entité et prend une décision d'autorisation à partir des conditions que vous définissez.
Service | Processus | Résultat |
---|---|---|
Amazon Verified Permissions | Renvoie une Deny décision Allow ou issue de l'analyse d'un groupe d'utilisateursJWT. |
L'accès aux ressources des applications réussit ou échoue en fonction de l'évaluation des politiques de Cedar. |
Groupes d'identités Amazon Cognito (attributs pour le contrôle d'accès) | Attribue des balises de session à votre utilisateur en fonction de ses attributs. IAMles conditions de politique peuvent vérifier les balises Allow ou Deny l'accès des utilisateurs à AWS services. |
Une session balisée avec des AWS informations d'identification temporaires pour un IAM rôle. |