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. Le contexte de la demande peut inclure un identifiant pour le document, l'image ou toute autre ressource demandée, ainsi que l'action que l'utilisateur souhaite effectuer sur la ressource.

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.

1. Votre groupe d'utilisateurs est une source d'identité Verified Permissions configurée pour le magasin de politiques demandé.

2. Le champ standard client_id ou aud, 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.

3. Votre jeton n'a pas expiré.

4. La valeur de la token_use réclamation contenue dans votre jeton correspond aux paramètres que vous avez transmisIsAuthorizedWithToken. La token_use réclamation doit être access si vous l'avez transmise au accessToken paramètre et id si vous l'avez transmise au identityToken paramètre.

5. La signature de votre jeton provient des clés JSON Web publiées (JWKs) de votre groupe d'utilisateurs. Vous pouvez consulter votre JWKs athttps://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

• Associer les jetons Amazon Cognito au schéma d'autorisations vérifiées

• Autoriser API Gateway APIs à l'aide d'Amazon Verified Permissions et d'Amazon Cognito

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.

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 :

1. Votre application a transmis un identifiant ou un jeton d'accès dans un Authorization en-tête en tant que jeton porteur.

2. Votre application a transmis un jeton avec une cognito:groups réclamation contenant la chaîneMyGroup.

3. 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 Cedar pour permettre aux utilisateurs du service financier qui s'authentifient à l'aide d'un client d'application de groupe d'utilisateurs de lire et d'écrire example_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.