GetFederationToken 的权限 - Amazon Identity and Access Management
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

GetFederationToken 的权限

GetFederationToken 操作是由 IAM 用户调用的,并返回该用户的临时凭证。该操作联合 用户。分配给联合身份用户的权限是在以下两个位置之一中定义的:

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

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

会话策略是高级策略,在以编程方式创建临时会话时,这些策略将作为参数进行传递。在创建联合身份用户会话并传递会话策略时,生成的会话的权限是 用户的基于身份的策略与会话策略的交集。您使用会话策略授予的权限不能超过联合的用户的基于身份的策略允许的权限。

在大多数情况下,如果您未通过 GetFederationToken API 调用传递策略,则生成的临时安全凭证没有任何权限。不过,基于资源的策略可以为会话提供额外的权限。您可以使用将会话指定为允许的主体的基于资源的策略访问资源。

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

示例:使用 GetFederationToken 分配权限

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

策略已附加到 IAM 用户

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

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

注意

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

例 附加到 IAM 用户 token-app 并调用 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": "*" } ] }

上述策略为 IAM 用户授予多个权限。不过,该策略本身不会为联合身份用户授予任何权限。如果该 IAM 用户调用 GetFederationToken,并且未将策略作为该 API 调用的参数传递,则生成的联合身份用户没有任何有效的权限。

作为参数传递的会话策略

要确保为联合身份用户分配相应的权限,最常用的方法是在 GetFederationToken API 调用中传递会话策略。让我们进一步阐述上述示例,并假设使用 IAM 用户 token-app 的凭证调用了 GetFederationToken。然后,假设将以下会话策略作为该 API 调用的参数进行传递。生成的联合身份用户有权列出名为 productionapp 的 Amazon S3 存储桶的内容。用户无法对 productionapp 存储桶中的项目执行 Amazon S3 GetObjectPutObject、和 DeleteObject 操作。

将为联合身份用户分配这些权限,因为这些权限是 IAM 用户策略与您传递的会话策略的交集。

联合身份用户无法在 Amazon SNS、Amazon SQS、Amazon DynamoDB,或任何 S3 存储桶(productionapp 除外)中执行操作。这些操作会被拒绝,即使这些权限被授给了与 GetFederationToken 调用关联的 IAM 用户。

例 作为 GetFederationToken API 调用参数传递的示例会话策略
{ "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/*"] } ] }

基于资源的策略

某些 Amazon 资源支持基于资源的策略,这些策略提供了另一种直接向联合身份用户授权的机制。只有一部分 Amazon 服务支持基于资源的策略。例如,Amazon S3 具有存储桶,Amazon SNS 有主题,Amazon SQS 具有队列,您可以向这些内容附加策略。有关支持基于资源的策略的所有服务的列表,请参阅使用 IAM 的Amazon服务并回顾表的“基于资源的策略”列。您可以使用基于资源的策略将权限直接分配给联合身份用户。为此,请在基于资源的策略的 Principal 元素中指定联合身份用户的 Amazon Resource Name (ARN)。以下示例说明了这一点,并使用名为 productionapp 的 S3 存储桶进一步阐述上述示例。

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

请记住,只有向 IAM 用户联合身份用户都进行显式授权时,该联合身份用户才具有这些权限。另外,也可通过在策略的 Principal 元素中对联合用户进行显式命名的基于资源的策略授予这些权限(在账户内),如下例所示。

例 允许访问联合身份用户的示例存储桶策略
{ "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/*"] } }

有关如何评估策略的更多信息,请参阅策略评估逻辑