Autorisations pour GetFederationToken

L'GetFederationTokenopération est appelée par un IAM utilisateur et renvoie des 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'GetFederationTokenAPIappel. (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é.

Dans la plupart des cas, si vous ne transmettez pas de politique lors de l'GetFederationTokenAPIappel, les informations d'identification de sécurité temporaires qui en résultent ne sont pas autorisées. 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 : attribution d'autorisations à l'aide de GetFederationToken

Vous pouvez utiliser l'GetFederationTokenAPIaction avec différents types de politiques. Voici quelques exemples.

Politique attachée à l'IAMutilisateur

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. Votre serveur appelle ensuite le GetFederationToken API pour obtenir des informations d'identification de sécurité temporaires et renvoie 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 le GetFederationToken API avec les informations de sécurité à long terme d'un IAM utilisateur nommétoken-app. Mais les informations IAM d'identification utilisateur à long terme restent sur votre serveur et ne sont jamais distribuées au client. L'exemple de politique suivant est attaché à l'token-appIAMutilisateur et définit l'ensemble le plus large 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 à cette fin, que vous pouvez télécharger ici : Token Vending Machine for Identity Registration - Sample Java Web Application.

Exemple de politique attachée à un IAM utilisateur token-app 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'IAMutilisateur. Cependant, cette politique seule n'accorde pas d'autorisations à l'utilisateur fédéré. Si cet IAM utilisateur appelle GetFederationToken et ne transmet pas de politique en tant que paramètre de l'APIappel, l'utilisateur fédéré qui en résulte ne dispose d'aucune autorisation effective.

Politique de session transmise en tant que paramètre

Le moyen le plus courant de s'assurer que l'utilisateur fédéré dispose des autorisations appropriées consiste à transmettre les politiques de session lors de l'GetFederationTokenAPIappel. En reprenant l'exemple précédent, imaginez qu'il GetFederationToken soit appelé avec les informations d'identification de l'IAMutilisateurtoken-app. Imaginez ensuite que la politique de session suivante soit transmise en tant que paramètre de l'APIappel. 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.

Ces autorisations sont attribuées à l'utilisateur fédéré, car elles se situent à l'intersection des politiques IAM utilisateur et des politiques de session que vous transmettez.

L'utilisateur fédéré n'a pas pu effectuer d'actions dans AmazonSNS, AmazonSQS, Amazon DynamoDB ou dans aucun compartiment S3 sauf. productionapp Ces actions sont refusées même si ces autorisations sont accordées à l'IAMutilisateur associé à l'GetFederationTokenappel.

Exemple de politique de session transmise en tant que paramètre d'GetFederationTokenAPIappel

{
  "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 fédéré. Seuls certains AWS services prennent en charge les politiques basées sur les ressources. Par exemple, Amazon S3 possède des compartiments, Amazon SNS propose des rubriques et Amazon SQS propose des files d'attente auxquelles vous pouvez associer des politiques. Pour obtenir la liste de tous les services prenant en charge les politiques basées sur les ressources, consultez AWS des 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, spécifiez le nom de ressource Amazon (ARN) de l'utilisateur 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 fédéré nommé Carol d'accéder au compartiment. Lorsque l'exemple de politique décrit précédemment est associé à l'token-appIAMutilisateur, l'utilisateur fédéré nommé Carol est autorisé à effectuer les s3:DeleteObject actions s3:GetObjects3: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'GetFederationTokenAPIappel. 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.

N'oubliez pas qu'un utilisateur fédéré ne reçoit des autorisations que lorsque ces autorisations sont explicitement accordées à la fois à l'IAMutilisateur 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.