AWS Identity and Access Management
用户指南
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 AWS 服务入门

GetFederationToken 的权限

会话策略是当您以编程方式为联合身份用户创建临时会话时作为参数传递的高级策略。要创建联合身份用户会话,您使用 IAM 用户的访问密钥以编程方式调用 GetFederationToken API 操作。当您执行此操作并传递会话策略时,生成的会话仅具有由 IAM 用户的基于身份的策略和会话策略这两者授予的权限。

分配给联合身份用户的权限在以下两个位置之一中定义:

  • 作为 GetFederationToken API 调用的参数传递的会话策略。(最常见。)

  • 一项基于资源的策略,在该策略的 Principal 元素中对联合身份用户进行显式命名。(最少见。)

这意味着,在大多数情况下,如果不通过 GetFederationToken API 调用传递策略,生成的临时安全凭证就没有任何权限。只有使用凭证访问以下资源时除外:此类资源拥有基于资源的策略且在策略的 Principal 元素中特别引用该联合身份用户会话。

下图形象地展示了各策略之间如何相互影响,以确定调用 GetFederationToken 所返回的临时安全凭证的权限。

示例:使用 GetFederationToken 分配权限

您可以将 GetFederationToken API 操作与不同类型的策略结合使用。下面是几个示例。

附加至 IAM 用户的策略

在此示例中,您拥有一个基于浏览器的客户端应用程序,该程序依赖于两个后端 Web 服务。一个后端服务是您自己的身份验证服务器,该服务器使用您自己的身份系统对客户端应用程序进行验证。另一个后端服务是一项 AWS 服务,该服务用于提供此客户端应用程序的部分功能。您的服务器对该客户端应用程序进行身份验证,并创建或检索相应的权限策略。之后,您的服务器调用 GetFederationToken API 来获取临时安全凭证,并将这些凭证返回给客户端应用程序。接下来,客户端应用程序就可以借助该临时安全凭证向 AWS 服务直接发出请求。这一架构允许客户端应用程序在不嵌入长期 AWS 证书的情况下发出 AWS 请求。

您的身份验证服务器使用名为 token-app 的 IAM 用户的长期安全凭证调用 GetFederationToken API,但该长期 IAM 用户凭证只保留在您的服务器上,而绝不会分发至客户端。下面的示例策略将被附加至 token-app IAM 用户,其中定义了您的联合身份用户(客户端)需要的一组最广泛的权限。请注意,您的身份验证服务器需要 sts:GetFederationToken 权限才能获取联合身份用户的临时安全凭证。

注意

AWS 提供了一个实现这一目的的 Java 示例应用程序,您可从此处下载:身份注册令牌售卖机 - Java Web 示例应用程序

例 附加至调用 GetFederationToken 的 IAM 用户 token-app 的策略

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:GetFederationToken", "Resource": "*" }, { "Effect": "Allow", "Action": "dynamodb:*", "Resource": "*" }, { "Effect": "Allow", "Action": "sqs:*", "Resource": "*" }, { "Effect": "Allow", "Action": "s3:*", "Resource": "*" }, { "Effect": "Allow", "Action": "sns:*", "Resource": "*" } ] }

尽管上述策略授予了许多权限,但其本身不足以向联合身份用户授予任何权限。如果具有在上述策略中定义的权限的 IAM 用户调用了 GetFederationToken,但未将任何策略作为该 API 调用的参数传递,则生成的联合身份用户不具备任何有效权限。

作为参数传递的会话策略

要确保向联合身份用户分配适当的权限,最常见的做法是将会话策略作为 GetFederationToken API 调用的参数传递。对上一个示例展开讨论,假设使用 IAM 用户 token-app 的凭证调用了 GetFederationToken,并且将下面的会话策略作为该 API 调用的参数进行了传递。联合身份用户将只具备执行以下操作的权限:

  • 列出名为 productionapp 的 Amazon S3 存储桶的内容。

  • productionapp 存储桶中的项目执行 Amazon S3 GetObjectPutObjectDeleteObject 操作。

向联合身份用户分配这些权限,因为已向两个用户授予了权限:

  • 调用 GetFederationToken 的 IAM 用户(通过附加到 IAM 用户的策略)

  • 联合身份用户(通过会话策略)

联合身份用户无法在 Amazon SNS、Amazon SQS、Amazon DynamoDB 或任何 S3 存储桶(productionapp 除外)中执行操作。这些操作会被拒绝,即使这些权限被授给了与 GetFederationToken 调用关联的 IAM 用户。之所以如此,是因为联合身份用户的有效权限只包括 IAM 用户策略会话策略中授予的权限。

例 作为 GetFederationToken API 调用的参数传递的会话

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:ListBucket"], "Resource": ["arn:aws-cn:s3:::productionapp"] }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": ["arn:aws-cn:s3:::productionapp/*"] } ] }

基于资源的策略

某些 AWS 资源支持基于资源的策略,这些策略提供了另一种直接向联合身份用户授权的机制。只有一部分 AWS 服务支持基于资源的策略。例如,您可以向 Amazon S3 的存储桶、Amazon SNS 的主题和 Amazon SQS 的队列附加策略。有关支持基于资源的策略的所有服务的列表,请参阅使用 IAM 的 AWS 服务并回顾表的“基于资源的策略”列。如果您使用的是以下服务之一,且您的情况需要使用基于资源的策略,则可通过在基于资源的策略的 Principal 元素中指定联合身份用户的 Amazon 资源名称来为联合身份用户直接分配权限。以下示例对此进行了说明。以下示例是前例的扩展,其中使用了一个名为 productionapp 的 S3 存储桶。

以下基于资源的策略附加到存储桶。此存储桶策略允许名为 Carol 的联合身份用户访问该存储桶。当之前介绍的示例策略被附加至 token-appIAM 用户时,名为 Carol 的联合身份用户将具有对名为 productionapp 的存储桶执行 s3:GetObjects3:PutObjects3:DeleteObject 操作的权限。即使未将任何会话策略作为 GetFederationToken API 调用的参数传递,Carol 也能够执行此操作。这是因为,在此示例中,以下基于资源的策略已向名为 Carol 的联合身份用户明确授予权限。

请记住,只有向 IAM 用户联合身份用户都进行显式授权时,该联合身份用户才具有这些权限。可通过作为 GetFederationToken API 调用的参数传递的会话策略将权限授予联合身份用户。还可以通过在策略的 Principal 元素中显式指定联合身份用户的基于资源的策略授予这些权限,如下例所示。

例 允许访问联合身份用户的存储桶策略

{ "Version": "2012-10-17", "Statement": { "Principal": {"AWS": "arn:aws-cn:sts::ACCOUNT-ID-WITHOUT-HYPHENS:federated-user/Carol"}, "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": ["arn:aws-cn:s3:::productionapp/*"] } }