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.
# Octroi d’autorisations à un utilisateur pour endosser un rôle
Lorsqu'un administrateur [crée un rôle pour un accès intercompte](id_roles_create_for-user.md), il établit une relation d'approbation entre le compte propriétaire du rôle et des ressources (compte d'approbation) et le compte qui contient les utilisateurs (compte approuvé). Pour cela, l'administrateur du compte d'approbation spécifie le numéro du compte approuvé en tant que `Principal` dans la politique d'approbation du rôle. Cela permet *potentiellement* à n'importe quel utilisateur du compte approuvé d'endosser le rôle. Pour achever la configuration, l'administrateur du compte approuvé doit accorder l'autorisation d'endosser ce rôle à des groupes ou utilisateurs spécifiques du compte.
**Pour accorder l'autorisation de passer à un rôle**
1. En tant qu'administrateur du compte approuvé, créez une nouvelle politique pour l'utilisateur ou modifiez une politique existante pour y ajouter les éléments requis. Pour en savoir plus, consultez [Création ou modification de la politique](#roles-usingrole-createpolicy).
1. Choisissez ensuite la manière dont vous souhaitez partager les informations du rôle :
+ **Lien du rôle :** envoyez aux utilisateurs un lien qui les dirige vers la page **Switch Role** (Changer de rôle) dans laquelle tous les détails sont déjà remplis.
+ **ID ou alias du compte :** donnez à chaque utilisateur le nom du rôle ainsi que l'ID ou l'alias du compte. L'utilisateur accède ensuite à la page **Switch Role (Changer de rôle)** et ajoute les détails manuellement.
Pour en savoir plus, consultez [Fourniture d'informations à l'utilisateur](#roles-usingrole-giveuser).
Notez que vous ne pouvez changer de rôle que lorsque vous vous connectez en tant qu'utilisateur IAM, en tant que rôle fédéré SAML ou en tant que rôle fédéré d'identité Web. Vous ne pouvez pas changer de rôle lorsque vous vous connectez en tant qu' Utilisateur racine d'un compte AWS.
**Important**
Vous ne pouvez pas changer AWS Management Console de rôle dans un rôle nécessitant une [ExternalId](id_roles_common-scenarios_third-party.md#id_roles_third-party_external-id)valeur. Vous ne pouvez basculer vers un tel rôle qu'en appelant l'API [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) qui prend en charge le paramètre `ExternalId`.
**Remarques**
Cette rubrique décrit les politiques applicables aux *utilisateurs* car, en fin de compte, il s'agit ici d'accorder à un utilisateur les autorisations nécessaires pour effectuer une tâche. Cependant, nous vous déconseillons d'octroyer des autorisations directement à un utilisateur individuel. Lorsqu'un utilisateur assume un rôle, il reçoit également les autorisations associées.
Lorsque vous changez de rôle dans le AWS Management Console, la console utilise toujours vos informations d'identification d'origine pour autoriser le changement. Cela s'applique que vous soyez connecté en tant qu'utilisateur IAM, en tant que rôle fédéré SAML ou en tant que rôle fédéré d'identité web. Par exemple, si vous basculez sur RoleA, IAM utilise les informations d'identification du compte utilisateur ou du rôle fédéré d'origine pour déterminer si vous êtes autorisé à assumer le rôle RoleA. Si vous essayez ensuite de basculer sur RoleB *pendant que vous utilisez RoleA*, vos informations d'identification d'utilisateur ou du rôle fédéré **d'origine** sont utilisées pour autoriser votre tentative. Les informations d'identification de RoleA (Rôle A) ne sont pas utilisées pour cette action.
**Topics**
+ [
## Création ou modification de la politique
](#roles-usingrole-createpolicy)
+ [
## Fourniture d'informations à l'utilisateur
](#roles-usingrole-giveuser)
## Création ou modification de la politique
Une politique qui accorde à un utilisateur l'autorisation d'endosser un rôle doit inclure une instruction avec l'effet `Allow` sur les éléments suivants :
+ L'action `sts:AssumeRole`
+ L'Amazon Resource Name (ARN) du rôle dans un élément `Resource`
Les utilisateurs bénéficiant de la politique sont autorisés à endosser les rôles figurant sur la ressource (via l'appartenance à un groupe ou directement).
**Note**
Si `Resource` est définie sur `*`, l'utilisateur peut endosser n'importe quel rôle dans n'importe quel compte faisant confiance au compte de l'utilisateur. (En d'autres termes, la politique de confiance du rôle spécifie le compte de l'utilisateur en tant que `Principal`). La bonne pratique consiste à appliquer le [principe du moindre privilège](http://en.wikipedia.org/wiki/Principle_of_least_privilege) et à spécifier l'ARN complet uniquement pour les rôles dont l'utilisateur a besoin.
L'exemple suivant illustre une politique qui permet à l'utilisateur d'endosser des rôles dans un seul compte. En outre, la politique utilise un caractère générique (\$1) pour spécifier que l'utilisateur ne peut passer à un rôle que si le nom du rôle commence par les lettres `Test`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/Test*"
}
}
```
------
**Note**
Les autorisations que le rôle octroie à l'utilisateur ne viennent pas s'ajouter aux autorisations dont il dispose déjà. Lorsqu'un utilisateur endosse un rôle, il abandonne temporairement ses autorisations d'origine, de manière à adopter celles accordées par le rôle. Lorsqu'il quitte le rôle, ses autorisations d'origine sont automatiquement restaurées. Par exemple, supposons que les autorisations de l'utilisateur lui permettent d'utiliser des instances Amazon EC2, mais que la politique des autorisations du rôle n'accorde pas ces autorisations. Dans ce cas, lorsque vous utilisez le rôle, l'utilisateur peut ne pas utiliser les instances Amazon EC2 dans la console. En outre, les informations d'identification temporaires obtenues via `AssumeRole` ne fonctionnent pas par programmation avec les instances Amazon EC2.
## Fourniture d'informations à l'utilisateur
Une fois que vous avez créé un rôle et accordé à l'utilisateur les autorisations requises pour l'endosser, vous devez également fournir à l'utilisateur les éléments suivants :
+ Nom du rôle
+ ID ou alias du compte qui contient le rôle
Pour faciliter l'accès aux utilisateurs, vous pouvez leur envoyer un lien préconfiguré contenant l'ID du compte et le nom du rôle. Vous pouvez voir le lien du rôle après avoir terminé l'assistant **Créer un rôle** en sélectionnant la bannière **Afficher le rôle** ou sur la page **Résumé du rôle** pour n'importe quel rôle inter-comptes.
Vous pouvez également utiliser le format suivant pour créer le lien manuellement. Remplacez les deux paramètres de l'exemple suivant par l'ID ou l'alias de votre compte et le nom du rôle.
`https://signin.aws.amazon.com/switchrole?account=your_account_ID_or_alias&roleName=optional_path/role_name`
Nous vous recommandons de diriger vos utilisateurs vers la rubrique [Basculer d’un utilisateur à un rôle IAM (console)](id_roles_use_switch-role-console.md) pour les guider à travers le processus. Pour résoudre les problèmes courants que vous pouvez rencontrer lorsque vous endossez un rôle, consultez [Je ne parviens pas à endosser un rôle](troubleshoot_roles.md#troubleshoot_roles_cant-assume-role).
**Considérations**
+ Si vous créez le rôle par programmation, vous pouvez définir un chemin et un nom. Dans ce cas, vous devez fournir le chemin complet et le nom du rôle à vos utilisateurs afin qu'ils les saisissent sur la page **Switch Role** (Changer de rôle) de la AWS Management Console. Par exemple : `division_abc/subdivision_efg/role_XYZ`.
+ Si vous créez le rôle par programmation, vous pouvez ajouter un `Path` de 512 caractères au maximum , ainsi qu'un `RoleName`. Le nom du rôle peut comporter jusqu'à 64 caractères. Toutefois, pour utiliser un rôle avec la fonctionnalité **Switch Role** dans le AWS Management Console, la combinaison `Path` `RoleName` ne peut pas dépasser 64 caractères.
+ Pour des raisons de sécurité, vous pouvez [consulter AWS CloudTrail les journaux](cloudtrail-integration.md#cloudtrail-integration_signin-tempcreds) pour savoir qui a effectué une action dans AWS. Vous pouvez utiliser la clé de condition `sts:SourceIdentity` dans la politique d'approbation de rôle pour exiger des utilisateurs qu'ils spécifient une identité lorsqu'ils endossent un rôle. Par exemple, vous pouvez exiger que les utilisateurs IAM spécifient leur propre nom d'utilisateur comme identité de source. Cela peut vous aider à déterminer quel utilisateur a effectué une action spécifique dans AWS. Pour de plus amples informations, veuillez consulter [`sts:SourceIdentity`](reference_policies_iam-condition-keys.md#ck_sourceidentity). Vous pouvez utiliser [`sts:RoleSessionName`](reference_policies_iam-condition-keys.md#ck_rolesessionname) pour exiger des utilisateurs qu'ils spécifient un nom de session lorsqu'ils endossent un rôle. Cela peut vous aider à différencier les sessions de rôle lorsqu'un rôle est utilisé par différents principaux.