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 accordées à un utilisateur fédéré sont définies dans l'un des éléments 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.)

• Une politique basée sur les ressources qui nomme explicitement l'utilisateur fédéré dans l'élément Principal de la politique. (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 d'utilisateur fédéré et transmettez des stratégies de session, les autorisations de la session obtenues sont une combinaison de la stratégie basée sur l'identité de l'utilisateur et des stratégies 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.

Exemple : Octroi 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 envoyer des demandes directement au service AWS avec les informations d'identification de sécurité temporaires. Cette architecture permet à l'application client d'exécuter des demandes AWS sans avoir à intégrer d'informations d'identification AWS à 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 IAM token-app et définit le plus large ensemble d'autorisations dont vos utilisateurs fédérés (clients) auront besoin. Notez que l'autorisation sts:GetFederationToken est requise pour que votre service d'authentification puisse obtenir les informations d'identification de sécurité temporaires pour les utilisateurs fédérés.

Note

AWS fournit un exemple d'application Java à cet effet ; vous pouvez le télécharger ici : Token Vending Machine for Identity Registration - Sample Java Web Application.

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 seule n'accorde pas d'autorisations à l'utilisateur 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 fédéré qui en résulte n'a aucune autorisation effective.

Politique de session transmise en tant que paramètre

La méthode la plus courante pour s'assurer que l'autorisation appropriée est octroyée à l'utilisateur fédéré consiste à transmettre des politiques de session de l'appel d'API GetFederationToken. 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é 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 fédéré n'a pas pu effectuer d'actions dans Amazon SNS, Amazon SQS, Amazon DynamoDB, ni dans un 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.

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 ressources AWS prennent en charge les politiques basées sur les ressources, et ces dernières fournissent un autre moyen d'accorder des autorisations directement à un utilisateur fédéré. Seuls quelques services AWS 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 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 fédéré. Pour ce faire, vous devez spécifier l'Amazon Resource Name (ARN) de l'utilisateur fédéré dans l'élément Principal 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 fédéré nommé Carol d'accéder au compartiment. Lorsque la politique d'exemple décrite précédemment est attachée à l'utilisateur IAM token-app, l'utilisateur fédéré nommé Carol est autorisé à effectuer les actions s3:GetObject, s3:PutObject et s3:DeleteObject sur le compartiment 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, la politique suivante basée sur les ressources a octroyé explicitement des autorisations à l'utilisateur fédéré nommé Carol.

Gardez à l'esprit que les autorisations ne sont accordées à un utilisateur fédéré que si celles-ci sont explicitement accordées à la fois à l'utilisateur IAM et à l'utilisateur 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 fédéré dans l'élément Principal de la politique, comme dans l'exemple suivant.

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::account-id: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.