

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.

# Utilisation du contrôle d'accès basé sur les rôles
<a name="role-based-access-control"></a>

Les groupes d'identités Amazon Cognito attribuent à vos utilisateurs authentifiés un ensemble d'informations d'identification temporaires à privilèges limités pour accéder à vos ressources. AWS Les autorisations pour chaque utilisateur sont contrôlées via des [rôles IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) que vous créez. Vous pouvez définir des règles pour choisir le rôle pour chaque utilisateur en fonction de demandes dans le jeton d'ID de l'utilisateur. Vous pouvez définir un rôle par défaut pour les utilisateurs authentifiés. Vous pouvez également définir un rôle IAM distinct avec des autorisations limitées pour les utilisateurs invités qui ne sont pas authentifiés.

## Création de rôles pour le mappage de rôles
<a name="creating-roles-for-role-mapping"></a>

Il est important d'ajouter la politique d'approbation appropriée pour chaque rôle afin que celui-ci puisse uniquement être assumé par Amazon Cognito pour les utilisateurs authentifiés dans votre groupe d'identités. Voici un exemple d'une telle politique d'approbation :

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Federated": "cognito-identity.amazonaws.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "cognito-identity.amazonaws.com:aud": "us-east-1:12345678-corner-cafe-123456790ab"
        },
        "ForAnyValue:StringLike": {
          "cognito-identity.amazonaws.com:amr": "authenticated"
        }
      }
    }
  ]
}
```

------

Cette politique autorise les utilisateurs fédérés à partir de `cognito-identity.amazonaws.com` (diffuseur du jeton OpenID Connect) à assumer ce rôle. En outre, la politique restreint le paramètre `aud` du jeton (dans ce cas, l'ID du groupe d'identités) pour qu'il corresponde au groupe d'identités. Enfin, la politique spécifie que l'un des membres du tableau de la revendication `amr` de valeur multiple du jeton émis par l'action API `GetOpenIdToken` Amazon Cognito possède la valeur `authenticated`.

## Octroi d'une autorisation de transmission de rôle
<a name="granting-pass-role-permission"></a>

Pour permettre à un utilisateur de définir des rôles avec des autorisations dépassant les autorisations existantes de l'utilisateur sur un groupe d'identités, accordez-leur l'autorisation `iam:PassRole` pour transmettre le rôle à l'API `set-identity-pool-roles`. Par exemple, si l'utilisateur ne peut pas écrire dans Amazon S3 mais que le rôle IAM que l'utilisateur définit sur le groupe d'identités accorde une autorisation en écriture dans Amazon S3, l'utilisateur peut définir ce rôle uniquement si une autorisation `iam:PassRole` est octroyée pour le rôle. L'exemple de politique suivant montre comment accorder l'autorisation `iam:PassRole`.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "Stmt1",
            "Effect": "Allow",
            "Action": [
                "iam:PassRole"
            ],
            "Resource": [
                "arn:aws:iam::123456789012:role/myS3WriteAccessRole"
            ]
        }
    ]
}
```

------

Dans cet exemple de politique, l'autorisation `iam:PassRole` est accordée pour le rôle `myS3WriteAccessRole`. Le rôle a été spécifié à l'aide de l'Amazon Resource Name (ARN) du rôle. Vous devez également attacher cette politique à votre utilisateur. Pour plus d'informations, consultez [Utilisation des politiques gérées](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-using.html).

**Note**  
Les fonctions Lambda utilisent des politiques basées sur des ressources, où la politique est attachée directement à la fonction Lambda. Lorsque vous créez une règle qui appelle une fonction Lambda, vous ne transmettez pas de rôle, et l'utilisateur qui crée la règle n'a donc pas besoin de l'autorisation `iam:PassRole`. Pour plus d'informations sur l'autorisation de fonctions Lambda, consultez [Gestion des autorisations : utilisation d'une politique de fonction Lambda](https://docs.aws.amazon.com/lambda/latest/dg/intro-permission-model.html#intro-permission-model-access-policy).

## Utilisation de jetons pour attribuer des rôles aux utilisateurs
<a name="using-tokens-to-assign-roles-to-users"></a>

Pour les utilisateurs qui se connectent via les groupes d'utilisateurs Amazon Cognito, des rôles peuvent être transmis dans le jeton d'identification qui a été affecté par le groupe d'utilisateurs. Les rôles apparaissent dans les demandes suivantes dans le jeton d'ID :
+ La demande `cognito:preferred_role` est l'ARN du rôle.
+ La `cognito:roles` réclamation est une chaîne séparée par des virgules contenant un ensemble de rôles autorisés. ARNs

Les demandes sont définies comme suit :
+ La demande `cognito:preferred_role` est définie sur le rôle du groupe avec la meilleure valeur pour `Precedence` (la valeur la plus faible). S'il n'existe qu'un seul rôle autorisé, `cognito:preferred_role` est défini sur ce rôle. S'il existe plusieurs rôles et qu'aucun rôle ne dispose de la meilleure priorité, cette demande n'est pas définie.
+ La demande `cognito:roles` est définie, s'il existe a au moins un rôle.

Lorsque des jetons sont utilisés pour attribuer des rôles, s'il existe plusieurs rôles pouvant être affectés à l'utilisateur, la fonctionnalité de Groupes d'identités Amazon Cognito (identités fédérées) choisit le rôle comme suit :
+ Utilisez le [GetCredentialsForIdentity](https://docs.aws.amazon.com/cognitoidentity/latest/APIReference/API_GetCredentialsForIdentity.html)`CustomRoleArn`paramètre s'il est défini et qu'il correspond à un rôle dans la `cognito:roles` réclamation. Si ce paramètre ne correspond pas à un rôle dans `cognito:roles`, l'accès est refusé.
+ Si la demande `cognito:preferred_role` est définie, elle est utilisée.
+ Si la `cognito:preferred_role` réclamation n'est pas définie, la `cognito:roles` réclamation est définie et n'`CustomRoleArn`est pas spécifiée dans l'appel à`GetCredentialsForIdentity`, puis le paramètre de **résolution des rôles** dans la console ou le `AmbiguousRoleResolution` champ (dans le `RoleMappings` paramètre de l'[SetIdentityPoolRoles](https://docs.aws.amazon.com/cognitoidentity/latest/APIReference/API_SetIdentityPoolRoles.html)API) est utilisé pour déterminer le rôle à attribuer.

## Utilisation du mappage basé sur des règles pour attribuer des rôles aux utilisateurs
<a name="using-rules-to-assign-roles-to-users"></a>

Les règles vous permettent de mapper des revendications d'un jeton de fournisseur d'identité à des rôles IAM.

Chaque règle spécifie une demande de jeton (par exemple, un attribut utilisateur dans le jeton d'ID d'un groupe d'utilisateurs Amazon Cognito), un type de correspondance, une valeur et un rôle IAM. Le type de correspondance peut être `Equals`, `NotEqual`, `StartsWith` ou `Contains`. Si un utilisateur a une valeur correspondante pour la demande, il peut assumer ce rôle lorsqu'il obtient les informations d'identification. Par exemple, vous pouvez créer une règle qui accorde un rôle IAM spécifique pour les utilisateurs avec une valeur d'attribut personnalisé `custom:dept` `Sales`. 

**Note**  
Dans les paramètres de la règle, les attributs personnalisés ont besoin du préfixe `custom:` pour se distinguer des attributs standard.

Les règles sont évaluées dans l'ordre, et le rôle IAM pour la première règle correspondante est utilisé, sauf si `CustomRoleArn` a été spécifié pour modifier l'ordre. Pour plus d'informations sur les attributs utilisateur dans les groupes d'utilisateurs Amazon Cognito, consultez [Utilisation des attributs utilisateur](user-pool-settings-attributes.md).

Vous pouvez définir plusieurs règles pour un fournisseur d'authentification dans la console de groupe d'identités (Identités fédérées). Les règles sont appliquées dans l'ordre. Vous pouvez faire glisser les règles pour changer leur ordre. La première règle correspondante a la priorité. Si le type de correspondance est `NotEqual` et que la demande n'existe pas, la règle n'est pas évaluée. Si aucune règle ne correspond, le paramètre **Résolution de rôle** est appliqué à **Utiliser le rôle authentifié par défaut** ou **Refuser la demande**.

Dans l'API et la CLI, vous pouvez spécifier le rôle à attribuer lorsqu'aucune règle ne correspond dans le `AmbiguousRoleResolution` champ du [RoleMapping](https://docs.aws.amazon.com/cognitoidentity/latest/APIReference/API_RoleMapping.html)type spécifié dans le `RoleMappings` paramètre de l'[SetIdentityPoolRoles](https://docs.aws.amazon.com/cognitoidentity/latest/APIReference/API_SetIdentityPoolRoles.html)API.

**Pour ajouter un mappage basé sur des règles à un fournisseur d'identité dans la console Amazon Cognito, ajoutez ou mettez à jour un IdP et **sélectionnez Choisir un rôle avec des règles sous Sélection du rôle**.** À partir de là, vous pouvez ajouter des règles que le fournisseur de cartes prétend appliquer aux rôles IAM.

Vous pouvez configurer un mappage basé sur des règles pour les fournisseurs d'identité dans l'API AWS CLI or avec le `RulesConfiguration` champ du [RoleMapping](https://docs.aws.amazon.com/cognitoidentity/latest/APIReference/API_RoleMapping.html)type. Vous pouvez spécifier ce champ dans le `RoleMappings` paramètre de l'[SetIdentityPoolRoles](https://docs.aws.amazon.com/cognitoidentity/latest/APIReference/API_SetIdentityPoolRoles.html)API.

Par exemple, la AWS CLI commande suivante ajoute une règle qui attribue le rôle `arn:aws:iam::123456789012:role/Sacramento_team_S3_admin` aux utilisateurs de votre site de Sacramento qui ont été authentifiés par OIDC IdP : `arn:aws:iam::123456789012:oidc-provider/myOIDCIdP`

```
aws cognito-identity set-identity-pool-roles --region us-east-1 --cli-input-json file://role-mapping.json
```

**Contenu de `role-mapping.json`** :

```
{
    "IdentityPoolId": "us-east-1:12345678-corner-cafe-123456790ab",
    "Roles": {
        "authenticated": "arn:aws:iam::123456789012:role/myS3WriteAccessRole",
        "unauthenticated": "arn:aws:iam::123456789012:role/myS3ReadAccessRole"
    },
    "RoleMappings": {
        "arn:aws:iam::123456789012:oidc-provider/myOIDCIdP": {
            "Type": "Rules",
            "AmbiguousRoleResolution": "AuthenticatedRole",
            "RulesConfiguration": {
                "Rules": [
                    {
                        "Claim": "locale",
                        "MatchType": "Equals",
                        "Value": "Sacramento",
                        "RoleARN": "arn:aws:iam::123456789012:role/Sacramento_team_S3_admin"
                    }
                ]
            }
        }
    }
}
```

Pour chaque groupe d'utilisateurs ou autre fournisseur d'authentification que vous configurez pour un groupe d'identités, vous pouvez créer jusqu'à 25 règles. Cette limite n’est pas réglable. Pour plus d'informations, consultez [Quotas dans Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html).

## Demandes de jetons à utiliser dans le mappage basé sur des règles
<a name="token-claims-for-role-based-access-control"></a>

**Amazon Cognito**

Un jeton d'identification Amazon Cognito est représenté comme un jeton web JSON (JSON Web Token, JWT). Il contient les demandes sur l'identité de l'utilisateur authentifié, par exemple `name`, `family_name` et `phone_number`. Pour plus d'informations sur les demandes standard, consultez la [spécification OpenID Connect](http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). Hormis les revendications standard, les revendications suivantes sont spécifiques d'Amazon Cognito: :
+ `cognito:groups`
+ `cognito:roles`
+ `cognito:preferred_role`

**Amazon**

Les demandes suivantes, ainsi que les valeurs possibles pour ces demandes, peuvent être utilisées avec Login with Amazon :
+ `iss` : www.amazon.com
+ `aud` : ID d'application
+ `sub` : `sub` du jeton Login with Amazon

**Facebook**

Les demandes suivantes, ainsi que les valeurs possibles pour ces demandes, peuvent être utilisées avec Facebook :
+ `iss` : graph.facebook.com
+ `aud` : ID d'application
+ `sub` : `sub` du jeton Facebook

**Google**

Jeton Google contenant les demandes standard émanant de la [spécification OpenID Connect](http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). Toutes les demandes contenues dans le jeton OpenID sont disponibles pour le mappage basé sur des règles. Consultez le site [OpenID Connect](https://developers.google.com/identity/protocols/OpenIDConnect) de Google pour connaître les demandes disponibles grâce au jeton Google.

**Apple**

Jeton Apple contenant les demandes standards émanant de la [spécification OpenID Connect](http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). Veuillez consulter [Authenticating Users with Sign in with Apple](https://developer.apple.com/documentation/signinwithapple/authenticating-users-with-sign-in-with-apple) dans la documentation Apple pour en savoir plus sur la demande disponible avec le jeton Apple. Le jeton Apple ne contient pas toujours `email`.

**OpenID**

Toutes les demandes contenues dans le jeton Open Id sont disponibles pour le mappage basé sur des règles. Pour plus d'informations sur les demandes standard, consultez la [spécification OpenID Connect](http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). Consultez la documentation de votre fournisseur OpenID pour connaître les demandes supplémentaires disponibles.

**SAML**

Les demandes sont analysées à partir de l'assertion SAML. Toutes les demandes disponibles dans l'assertion SAML peuvent être utilisées pour le mappage basé sur des règles.

## Bonnes pratiques pour le contrôle d'accès basé sur les rôles
<a name="best-practices-for-role-based-access-control"></a>

**Important**  
Si la demande qui vous mappez à un rôle peut être modifiée par l'utilisateur final, tout utilisateur final peut assumer votre rôle et définir la politique en conséquence. Mappez uniquement les demandes qui ne peuvent pas être définies directement par l'utilisateur final à des rôles avec des autorisations de niveau élevé. Dans un groupe d'utilisateurs Amazon Cognito, vous pouvez définir des autorisations de lecture et d'écriture par application pour chaque attribut utilisateur.

**Important**  
Si vous définissez des rôles pour des groupes dans un groupe d'utilisateurs Amazon Cognito, ces rôles sont transmis via le jeton d'identification de l'utilisateur. Pour utiliser ces rôles, vous devez également définir **Choose role from token (Choisir un rôle à partir d'un jeton)** pour la sélection de rôle authentifié pour le groupe d'identités.  
Vous pouvez utiliser le paramètre de **résolution des rôles** de la console et le `RoleMappings` paramètre de l'[SetIdentityPoolRoles](https://docs.aws.amazon.com/cognitoidentity/latest/APIReference/API_SetIdentityPoolRoles.html)API pour spécifier le comportement par défaut lorsque le rôle correct ne peut pas être déterminé à partir du jeton.