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.
# Autorisations pour GetFederationToken
L'opération `GetFederationToken` est appelée par un utilisateur IAM et renvoie les informations d'identification temporaires pour cet utilisateur. Cette opération *fédère* l'utilisateur. Les autorisations attribuées à une session utilisateur AWS STS fédérée sont définies à l'un des deux endroits suivants :
+ Les politiques de session transmises en tant que paramètre de l'appel d'API `GetFederationToken`. (Il s'agit du scénario le plus courant.)
+ Stratégie basée sur les ressources qui nomme explicitement la session utilisateur AWS STS fédérée dans l'`Principal`élément de la stratégie. (Ce scénario est moins courant.)
Les politiques de session sont des politiques avancées que vous transmettez en tant que paramètres lorsque vous créez par programmation une session temporaire. Lorsque vous créez une session utilisateur AWS STS fédérée et que vous adoptez des politiques de session, les autorisations de session qui en résultent sont à l'intersection de la politique basée sur l'identité de l'utilisateur et des politiques de session. Vous ne pouvez pas utiliser la politique de session pour accorder plus d'autorisations que celles autorisées par la politique basée sur l'identité de l'utilisateur fédéré.
Cela signifie que dans la plupart des cas, si vous ne transmettez pas de politique avec l'appel d'API `GetFederationToken`, les informations d'identification de sécurité temporaires générées ne disposent d'aucune autorisation. Toutefois, une politique basée sur les ressources peut fournir des autorisations supplémentaires pour la session. Vous pouvez accéder à une ressource avec une politique basée sur les ressources, qui spécifie votre session en tant que principal autorisé.
Les illustrations suivantes sont une représentation visuelle de la façon dont les politiques interagissent pour déterminer les autorisations accordées aux informations d'identification de sécurité temporaires retournées par un appel à `GetFederationToken`.
![\[Utilisateur IAM Les illustrations suivantes indiquent que les autorisations de session sont à la croisée de la politique basée sur l’identité de l’utilisateur et des politiques de session. Les autorisations de session peuvent également être à la croisée de la politique basée sur l’identité de l’utilisateur et des politiques basées sur les ressources.\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/getfederationtoken-permissions.diagram.png)
## Exemple : attribution d'autorisations à l'aide de GetFederationToken
Vous pouvez utiliser l'action d'API `GetFederationToken` avec différents types de politiques. Voici quelques exemples.
### Politique attachée à l'utilisateur IAM
Dans cet exemple, une application cliente basée sur un navigateur s'appuie sur deux services web backend. L’un des backend est votre propre serveur d'authentification qui utilise votre système d'identité pour authentifier l'application cliente. L'autre backend est un service AWS qui fournit certaines des fonctionnalités de l'application cliente. L'application cliente est authentifiée par votre serveur, puis ce dernier créée ou récupère la politique d'autorisation appropriée. Ensuite, votre serveur appelle l'API `GetFederationToken` afin d'obtenir des informations d'identification de sécurité temporaires, puis il retourne ces informations d'identification à l'application cliente. L'application cliente peut ensuite adresser des demandes directement au AWS service avec les informations d'identification de sécurité temporaires. Cette architecture permet à l'application cliente de faire des AWS demandes sans intégrer d'informations d' AWS identification à long terme.
Votre serveur d'authentification appelle l'API `GetFederationToken` avec les informations d'identification de sécurité à long terme d'un utilisateur IAM nommé `token-app`. Cependant, les informations d'identification de l'utilisateur IAM à long terme restent sur votre serveur et ne sont jamais distribuées au client. L'exemple de politique suivant est attaché à l'utilisateur `token-app` IAM et définit l'ensemble le plus large d'autorisations dont vos utilisateurs AWS STS fédérés (clients) auront besoin. Notez que l'`sts:GetFederationToken`autorisation est requise pour que votre service d'authentification obtienne des informations d'identification de sécurité temporaires pour les utilisateurs AWS STS fédérés.
**Example Exemple de politique attachée à un `token-app` d'utilisateur IAM qui appelle `GetFederationToken`**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "dynamodb:ListTables",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "sqs:ReceiveMessage",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "sns:ListSubscriptions",
"Resource": "*"
}
]
}
```
La politique précédente accorde plusieurs autorisations à l'utilisateur IAM. Cependant, cette politique à elle seule n'accorde aucune autorisation à l'utilisateur AWS STS fédéré. Si cet utilisateur IAM appelle `GetFederationToken` et ne transmet pas de politique en tant que paramètre de l'appel d'API, l'utilisateur AWS STS fédéré qui en résulte ne dispose d'aucune autorisation effective.
### Politique de session transmise en tant que paramètre
La méthode la plus courante pour s'assurer que l'utilisateur AWS STS fédéré dispose des autorisations appropriées consiste à transmettre les politiques de session dans l'appel `GetFederationToken` d'API. En reprenant l'exemple précédent, imaginons que `GetFederationToken` est appelé avec les informations d'identification de l'utilisateur `token-app` IAM. Imaginons ensuite que la politique de session suivante est transmise en tant que paramètre de l'appel d'API. L’utilisateur fédéré AWS STS a obtenu l’autorisation de répertorier le contenu du compartiment Amazon S3 nommé `productionapp`. L'utilisateur ne peut pas effectuer les actions Amazon S3 `GetObject` `PutObject` et `DeleteObject` sur les éléments dans le compartiment `productionapp`.
L'utilisateur fédéré se voit attribuer ces autorisations, car elles sont une combinaison des politiques d'utilisateur IAM et les politiques de session que vous transmettez.
L'utilisateur AWS STS fédéré n'a pas pu effectuer d'actions dans Amazon SNS, Amazon SQS, Amazon DynamoDB ou dans aucun compartiment S3 à l'exception de. `productionapp` Ces actions sont refusées, même si ces autorisations sont accordées à l'utilisateur IAM associé à l'appel `GetFederationToken`.
**Example Exemple de politique transmise en tant que paramètre de l'appel d'API `GetFederationToken`**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::productionapp"]
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": ["arn:aws:s3:::productionapp/*"]
}
]
}
```
### Politiques basées sur les ressources
Certaines AWS ressources prennent en charge les politiques basées sur les ressources, et ces politiques fournissent un autre mécanisme permettant d'accorder des autorisations directement à un utilisateur AWS STS fédéré. Seuls certains AWS services prennent en charge les politiques basées sur les ressources. Par exemple, Amazon S3 comprend des compartiments, Amazon SNS des rubriques, et Amazon SQS des files d'attente auxquelles vous pouvez attacher des politiques. Pour obtenir la liste de tous les services prenant en charge les politiques basées sur les ressources, consultez [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md) et passez en revue la colonne « Politiques basées sur les ressources » des tableaux. Vous pouvez utiliser des politiques basées sur les ressources pour attribuer des autorisations directement à un utilisateur AWS STS fédéré. Pour ce faire, spécifiez l'Amazon Resource Name (ARN) de l'utilisateur AWS STS fédéré dans l'`Principal`élément de la politique basée sur les ressources. L'exemple suivant illustre cette méthode et développe les exemples précédents, à l'aide d'un compartiment S3 nommé `productionapp`.
La politique basée sur les ressources suivante est attachée au compartiment. Cette politique de compartiment permet à un utilisateur AWS STS fédéré nommé Carol d'accéder au compartiment. Lorsque l'exemple de politique décrit précédemment est attaché à l'utilisateur `token-app` IAM, l'utilisateur AWS STS fédéré nommé Carol est autorisé à effectuer les `s3:DeleteObject` actions `s3:GetObject``s3:PutObject`, et sur le bucket nommé. `productionapp` Cela est vrai même lorsqu'aucune politique de session n'est transmise en tant que paramètre de l'appel d'API `GetFederationToken`. En effet, dans ce cas, l'utilisateur AWS STS fédéré nommé Carol a reçu des autorisations explicites en vertu de la politique basée sur les ressources suivante.
N'oubliez pas qu'un utilisateur AWS STS fédéré ne reçoit des autorisations que lorsque ces autorisations sont explicitement accordées à la fois à l'utilisateur IAM ***et*** à l'utilisateur AWS STS fédéré. Ils peuvent également être accordés (au sein du compte) par une politique basée sur les ressources qui nomme explicitement l'utilisateur AWS STS fédéré dans l'`Principal`élément de la politique, comme dans l'exemple suivant.
**Example Exemple de politique de compartiment qui autorise l'accès à l'utilisateur fédéré**
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": {
"AWS": "arn:aws:sts::111122223333:federated-user/Carol"
},
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::productionapp/*"
]
}
}
```
Pour plus d'informations sur la manière dont les politiques sont évaluées, consultez la rubrique [Logique d'évaluation des politiques](reference_policies_evaluation-logic.md).