AWS Identity and Access Management
用户指南
AWS 服务或AWS文档中描述的功能,可能因地区/位置而异。请点击 Amazon AWS 入门,可查看中国地区的具体差异

GetFederationToken 的权限

GetFederationToken 返回的临时安全凭证的权限由以下组合决定:

  • 附加至其证书用于调用 GetFederationToken 的 IAM 用户的策略。

  • 在该调用中作为参数传递的策略。

所传递的策略被附加至 GetFederationToken API 调用产生的临时安全凭证 (即联合身份用户)。当联合身份用户发出 AWS 请求时,AWS 将评估附加至该联合身份用户的策略,以及附加至其证书用于调用 GetFederationToken 的 IAM 用户的策略。

重要

仅当附加的策略 IAM 用户策略都明确允许联合身份用户执行所请求的操作时,AWS 才允许联合身份用户的请求。

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

  • 作为 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 用户的策略) 该联合身份用户 (通过所传递的策略) 授予了这些权限。联合身份用户无法在除 productionapp 外的 Amazon SNS、Amazon SQS、Amazon DynamoDB 或任意 S3 存储桶中执行操作,即使已向与 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 的联合身份用户访问该存储桶。当以下基于资源的策略到位后,之前介绍的示例策略将被附加至 IAM 用户 token-app,名为 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/*"] } }