Autorisations pour GetFederationToken - AWS Identity and Access Management
Exemple : attribution d'autorisations à l'aide de GetFederationToken

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.

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:GetFederationTokenautorisation 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.

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 token-app d'utilisateur IAM qui appelle GetFederationToken
JSON
{
  "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 AWS STS fédéré qui en résulte est autorisé à 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.

Exemple de politique transmise en tant que paramètre de l'appel d'API GetFederationToken
JSON
{
  "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 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: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'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.

Exemple de politique de compartiment qui autorise l'accès à l'utilisateur fédéré
JSON
{
  "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.