# IAM 临时安全凭证
您可以使用 AWS Security Token Service (AWS STS) 创建可控制对您的 AWS 资源的访问的临时安全凭证，并将这些凭证提供给受信任用户。临时安全凭证的工作方式与长期访问密钥凭证的工作方式几乎相同，仅存在以下差异：
+ 顾名思义，临时安全凭证是*短期* 凭证。可将这些凭证的有效时间配置几分钟到几小时。一旦这些凭证到期，AWS 将不再识别这些凭证或不再允许来自使用这些凭证发出的 API 请求的任何类型的访问。
+ 临时安全凭证不随用户一起存储，而是动态生成并在用户提出请求时提供给用户。临时安全凭证到期时 (甚至之前)，用户可以请求新的凭证，只要请求凭证的用户仍有权这样做。
因此，与长期凭证相比，临时凭证具有以下优势：
+ 您不必随应用程序分配或嵌入长期 AWS 安全凭证。
+ 可允许用户访问您的 AWS 资源，而不必为这些用户定义 AWS 身份。临时凭证是[角色](id_roles.md)和[身份联合验证](id_roles_providers.md)的基础。
+ 临时安全凭证的生命周期较短，因此无需更新或在不再需要这些凭证时显式撤销这些凭证。临时安全凭证到期后无法重复使用。您可指定凭证的有效期，但有最长限期。
## AWS STS 和 AWS 区域
临时安全凭证由 AWS STS 生成。默认情况下，AWS STS 是一种全球服务，在 `https://sts.amazonaws.com` 上具有单个终端节点。不过，您也可以选择对任何其他支持的区域中的终端节点进行 AWS STS API 调用。这可能会将请求发送到地理位置离您较近的区域中的服务器以减少延迟（服务器延迟）。无论您的凭证来自于哪个区域，它们都会在全球范围内起作用。有关更多信息，请参阅 [管理 AWS 区域中的 AWS STS](id_credentials_temp_enable-regions.md)。
## 临时凭证的常见情形
临时凭证在涉及联合身份验证、委派、跨账户访问和 IAM 角色的情形中很有用。
### 联合身份
您可以在 AWS 之外的外部系统中管理用户身份，并为从这些系统登录的用户授予访问权限以执行 AWS 任务和访问您的 AWS 资源。IAM 支持两种联合身份验证。在两种情况下，身份都存储在 AWS 外部。区别在于外部系统所处的位置 在您的数据中心内或 Web 上的外部第三方。要比较用于身份联合验证的临时安全凭证的功能，请参阅 [比较 AWS STS 凭证](id_credentials_sts-comparison.md)。
有关外部身份提供程序的更多信息，请参阅[身份提供程序和 AWS 中的联合身份验证](id_roles_providers.md)。
+ **OpenID Connect（OIDC）联合身份验证** - 您可让移动或 Web 应用程序的用户使用已知的第三方身份提供者（例如，Login with Amazon、Facebook、Google 或任何 OIDC 2.0 兼容的提供者）登录，您不需要创建自定义的登录代码或管理自己的用户身份。使用 OIDC 联合身份验证可帮助您确保 AWS 账户 的安全，因为您不必随应用程序分配长期安全凭证（如 IAM 用户访问密钥）。有关更多信息，请参阅 [OIDC 联合身份验证](id_roles_providers_oidc.md)。
AWS STS OIDC 联合身份验证支持 Login with Amazon、Facebook、Google 和任何 OpenID Connect（OIDC）兼容的身份提供者。
**注意**
有关移动应用程序，我们建议使用 Amazon Cognito。您可以将此服务与面向移动开发的 AWS 开发工具包搭配使用，为用户创建唯一的身份，并对其进行身份验证，以使其安全地访问您的 AWS 资源。Amazon Cognito 支持与 AWS STS 相同的身份提供程序，还支持未经身份验证的（来宾）访问，并允许您在用户登录时迁移用户数据。Amazon Cognito 还提供用于同步用户数据的 API 操作，因此，无论用户在设备间怎样转移，其数据总能得以保留。有关更多信息，请参阅《Amplify 文档》**中的[使用 Amplify 进行身份验证](https://docs.amplify.aws/lib/auth/getting-started/q/platform/js/#authentication-with-amplify)。
+ **SAML 联合身份验证** – 您可以对您的企业网络中的用户进行身份验证，然后为这些用户提供对 AWS 的访问权限，而无需为其创建新的 AWS 身份，他们也无需使用不同的登录凭证进行登录。这称为用于临时访问的*单点登录*方法。AWS STS 支持开放标准 [如安全断言标记语言（SAML）2.0]，这使您可以使用 Microsoft AD FS 来利用您的 Microsoft Active Directory。您还可以使用 SAML 2.0 管理自己的联合身份用户身份解决方案。有关更多信息，请参阅 [SAML 2.0 联合身份验证](id_roles_providers_saml.md)。
+ **自定义联合身份代理** - 您可以使用您企业的身份验证系统来授予对 AWS 资源的访问权限。有关示例方案，请参阅[使自定义身份凭证代理程序能够访问 AWS 控制台](id_roles_providers_enable-console-custom-url.md)。
+ **使用 SAML 2.0 的联合** - 您可以使用您企业的身份验证系统和 SAML 来授予对 AWS 资源的访问权限。有关更多信息以及示例方案，请参阅[SAML 2.0 联合身份验证](id_roles_providers_saml.md)。
### 用于跨账户访问的角色
很多组织均维护多个 AWS 账户。利用角色和跨账户访问，您可以在一个账户中定义用户身份，并使用这些身份访问属于您组织的其他账户中的 AWS 资源。这称为用于临时访问的*委派*方法。有关创建跨账户角色的更多信息，请参阅 [创建角色，向 IAM 用户授予权限](id_roles_create_for-user.md)。要了解您信任区域之外的账户（受信任的企业或账户）中的主体是否有权承担您的角色，请参阅[什么是 IAM Access Analyzer？](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)。
### 适用于 Amazon EC2 的 角色
如果您在 Amazon EC2 实例上运行一些应用程序，并且这些应用程序需要访问 AWS 资源，则您可在启动您的实例时为其提供临时安全凭证。这些临时安全凭证对该实例上运行的所有应用程序都可用，因此您无需在该实例上存储任何长期凭证。有关更多信息，请参阅 [使用 IAM 角色向在 Amazon EC2 实例上运行的应用程序授予权限](id_roles_use_switch-role-ec2.md)。
要了解有关 IAM Amazon EC2 角色凭证的更多信息，请参阅《Amazon Elastic Compute Cloud 用户指南》**中的 [Amazon EC2 的 IAM 角色](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html)。
### 其他 AWS 服务
可使用临时安全凭证访问大多数 AWS 服务。有关接受临时安全凭证的服务的列表，请参阅[使用 IAM 的 AWS 服务](reference_aws-services-that-work-with-iam.md)。
## 使用临时凭证的示例应用程序
您可以使用 AWS Security Token Service (AWS STS) 创建可控制对您的 AWS 资源的访问的临时安全凭证，并将这些凭证提供给可信用户。有关 AWS STS 的更多信息，请参阅 [IAM 临时安全凭证](#id_credentials_temp)。要了解如何使用 AWS STS 管理临时安全凭证，可下载以下示例应用程序，其中实现完整的示例方案：
+ [使用 Windows Active Directory、ADFS 和 SAML 2.0 启用 AWS 的联合身份验证](https://aws.amazon.com/blogs/security/enabling-federation-to-aws-using-windows-active-directory-adfs-and-saml-2-0/)。演示如何使用 Windows Active Directory（AD）、Active Directory 联合身份验证服务（ADFS）2.0 和 SAML（安全断言标记语言）2.0，通过企业联合身份验证将访问权限授予 AWS。
+ [使自定义身份凭证代理程序能够访问 AWS 控制台](id_roles_providers_enable-console-custom-url.md). 说明如何创建启用单点登录（SSO）的自定义联合身份验证代理，以使现有 Active Directory 用户能够登录到 AWS 管理控制台。
+ [如何使用 Shibboleth 单点登录到 AWS 管理控制台。](https://aws.amazon.com/blogs/security/how-to-use-shibboleth-for-single-sign-on-to-the-aws-management-console/)介绍如何使用 [Shibboleth](http://shibboleth.net/) 和 [SAML](id_roles_providers_saml.md) 为用户提供对 AWS 管理控制台的单点登录 (SSO) 访问权限。
### OIDC 联合身份验证示例
下面的示例应用程序说明了如何使用 Login with Amazon、Amazon Cognito、Facebook 或 Google 等提供者的 OIDC 联合身份验证。您可以将从这些提供商处获得的身份验证信息作为临时 AWS 安全凭证以访问 AWS 服务。
+ [Amazon Cognito 教程](https://docs.aws.amazon.com/cognito/latest/developerguide/tutorials.html) — 建议您将 Amazon Cognito 与适用于移动开发的 AWS SDK 搭配使用。Amazon Cognito 是管理适用于移动应用程序的身份的最简单方式，它提供了同步和跨设备身份等额外功能。有关 Amazon Cognito 的更多信息，请参阅《Amplify 文档》**中的[使用 Amplify 进行身份验证](https://docs.amplify.aws/lib/auth/getting-started/q/platform/js/#authentication-with-amplify)。
## 有关临时安全凭证的其他资源
以下场景和应用可指导您使用临时安全凭证：
+ [如何将 AWS STS SourceIdentity 与您的身份提供者](https://aws.amazon.com/blogs/security/how-to-integrate-aws-sts-sourceidentity-with-your-identity-provider/)集成。本文向您介绍当使用 Okta、Ping 或 OneLogin 作为 IdP 时如何设置 AWS STS `SourceIdentity` 属性。
+ [OIDC 联合身份验证](id_roles_providers_oidc.md)。本节讨论如何在使用 OIDC 联合身份验证和 `AssumeRoleWithWebIdentity` API 时配置 IAM 角色。
+ [使用 MFA 保护 API 访问](id_credentials_mfa_configure-api-require.md). 本主题介绍如何使用角色要求多重身份验证 (MFA)，以保护您账户中的敏感 API 操作。
有关 AWS 中的策略和权限的更多信息，请参阅以下主题：
+ [适用于 AWS 资源的 Access Management](access.md)
+ [策略评估逻辑](reference_policies_evaluation-logic.md).
+ *Amazon Simple Storage Service 用户指南*中的[管理对 Amazon S3 资源的访问权限](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html)。
+ 要了解您信任区域之外的账户（受信任的企业或账户）中的主体是否有权承担您的角色，请参阅[什么是 IAM Access Analyzer？](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)。
# 比较 AWS STS 凭证
下表比较了 AWS STS 中返回临时安全凭证的 API 操作的功能。要了解在担任角色以请求临时安全凭证时使用的各种方法，请参阅[担任角色的方法](id_roles_manage-assume.md)。要了解允许您传递会话标签的不同 AWS STS API 操作，请参阅[在 AWS STS 中传递会话标签](id_session-tags.md)。
**注意**
您可以将 AWS STS API 调用发送到全球终端节点或某个区域终端节点。如果您选择更靠近您的终端节点，则可减少延迟并改善 API 调用的性能。如果您不再能与原始终端节点进行通信，也可选择将调用定向到替代的区域终端节点。如果您使用某种 AWS SDK，请先使用该开发工具包的方法指定一个区域，然后再进行 API 调用。如果您正在手动构建 HTTP API 请求，则必须自行将请求定向到正确的终端节点。有关更多信息，请参阅[*区域和终端节点*和 [管理 AWS 区域中的 AWS STS](id_credentials_temp_enable-regions.md) 的 AWS STS 部分](https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region)。
| **AWS STS API** | **谁能调用** | **凭证生命周期 (最小值 \$1 最大值 \$1 默认值)** | **MFA 支持**¹ | **会话策略支持**² | **对生成的临时凭证的限制** |
| --- | --- | --- | --- | --- | --- |
| [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) | 具有现有临时安全凭证的 IAM 用户或 IAM 角色 | 15 分钟 \$1 最大会话持续时间设置³ \$1 1 小时 | 支持 | 是 | 无法调用 `GetFederationToken` 或 `GetSessionToken`。 |
| [AssumeRoleWithSAML](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) | 任何用户；发起人必须传递 SAML 身份验证响应，指示身份验证来自已知的身份提供程序 | 15 分钟 \$1 最大会话持续时间设置³ \$1 1 小时 | 否 | 是 | 无法调用 `GetFederationToken` 或 `GetSessionToken`。 |
| [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) | 任何用户；发起人必须传递 OIDC 兼容的 JWT 令牌，指示身份验证来自已知的身份提供者 | 15 分钟 \$1 最大会话持续时间设置³ \$1 1 小时 | 否 | 是 | 无法调用 `GetFederationToken` 或 `GetSessionToken`。 |
| [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) | IAM 用户或 AWS 账户根用户 | IAM 用户：15 分钟 \$1 36 小时 \$1 12 小时 根用户：15 分钟 \$1 1 小时 \$1 1 小时 | 否 | 是 | 无法使用 AWS CLI 或 AWS API 调用 IAM 操作。此限制不适用于控制台会话。 无法调用除 `GetCallerIdentity` 之外的 AWS STS 操作。⁴ 允许通过 SSO 登录到控制台。⁵ |
| [GetSessionToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) | IAM 用户或 AWS 账户根用户 | IAM 用户：15 分钟 \$1 36 小时 \$1 12 小时 根用户：15 分钟 \$1 1 小时 \$1 1 小时 | 是 | 否 | 除非请求附带了 MFA 信息，否则无法调用 IAM API 操作。 无法调用除 `AssumeRole` 或 `GetCallerIdentity` 之外的 AWS STS API 操作。 不允许通过 SSO 登录到控制台。⁶ |
¹ **MFA 支持**。在调用 AssumeRole 和 GetSessionToken API 操作时，可以包含有关 Multi-Factor Authentication (MFA) 设备的信息。这可确保通过 API 调用生成的临时安全凭证只能由已使用 MFA 设备进行身份验证的用户使用。有关更多信息，请参阅 [使用 MFA 保护 API 访问](id_credentials_mfa_configure-api-require.md)。
² **会话策略支持**。会话策略是当您以编程方式为角色或 AWS STS 联合用户会话创建临时会话时作为参数传递的策略。此策略限制来自角色或用户的基于身份的策略且分配给该会话的权限。生成的会话的权限是实体的基于身份的策略与会话策略的交集。使用会话策略授予的权限不能超过担任的角色的基于身份的策略允许的权限。有关角色会话权限的更多信息，请参阅[会话策略](access_policies.md#policies_session)。
³ **最大会话持续时间设置**。可以使用 `DurationSeconds` 参数指定 900 秒 (15 分钟) 到角色的最大会话持续时间设置之间的角色会话持续时间。要了解如何查看您的角色的最大值，请参阅[更新角色的最长会话持续时间](id_roles_update-role-settings.md#id_roles_update-session-duration)。
⁴ **GetCallerIdentity**。无需权限即可执行该操作。如果管理员为您的 IAM 用户或角色添加明确拒绝访问 `sts:GetCallerIdentity` 操作的策略，您仍然可以执行该操作。不需要权限，因为在拒绝 IAM 用户或角色访问时返回相同的信息。要查看示例响应，请参阅[我没有权限执行：iam:DeleteVirtualMFADevice](troubleshoot.md#troubleshoot_general_access-denied-delete-mfa)。
⁵ **通过单一登录 (SSO) 登录到控制台**。为了支持 SSO，AWS 可让您调用联合终端节点 (`https://signin.aws.amazon.com/federation`) 并传递临时安全凭证。终端节点将返回一个令牌，可使用该令牌构建一个让用户直接登录到控制台而无需使用密码的 URL。有关更多信息，请参阅[使 SAML 2.0 联合主体能够访问 AWS 管理控制台](id_roles_providers_enable-console-saml.md) 安全性博客中的[和AWS如何启用对 ](https://aws.amazon.com/blogs/security/how-to-enable-cross-account-access-to-the-aws-management-console) 管理控制台的跨账户访问AWS。
⁶ 在检索您的临时凭证后，无法将该凭证传递到联合单一登录终端节点以访问 AWS 管理控制台。有关更多信息，请参阅 [使自定义身份凭证代理程序能够访问 AWS 控制台](id_roles_providers_enable-console-custom-url.md)。
# 服务持有者令牌
某些 AWS 服务需要您有权获取 AWS STS 服务持有者令牌，然后您才能以编程方式访问它们的资源。这些服务支持一种协议，该协议要求您使用持有者令牌，而不是使用传统的 [适用于 API 请求的 AWS 签名版本 4](reference_sigv.md)。当您执行需要持有者令牌的 AWS CLI 或 AWS API 操作时，AWS 服务将代表您请求持有者令牌。该服务将为您提供令牌，然后您可以使用该令牌在该服务中执行后续操作。
AWS STS 服务持有者令牌包括来自您的原始主体身份验证的信息，这些信息可能会影响您的权限。这些信息可以包括主体标签、会话标签和会话策略。令牌的访问密钥 ID 以 `ABIA` 前缀开头。这可帮助您在 CloudTrail 日志中识别使用服务持有者令牌执行的操作。
**重要**
持有者令牌只能用于对生成它的服务的调用以及生成它的区域。您不能使用持有者令牌在其他服务或区域中执行操作。
支持持有者令牌的服务示例是 AWS CodeArtifact。在使用 NPM、Maven 或 PIP 等程序包管理器与 AWS CodeArtifact 进行交互之前，您必须调用 `aws codeartifact get-authorization-token` 操作。此操作返回可用于执行 AWS CodeArtifact 操作的持有者令牌。或者，您可以使用 `aws codeartifact login` 命令完成相同的操作，然后自动配置您的客户端。
如果您在为您生成持有者令牌的 AWS 服务中执行操作，则您的 IAM policy 中必须具有以下权限：
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowServiceBearerToken",
"Effect": "Allow",
"Action": "sts:GetServiceBearerToken",
"Resource": "*"
}
]
}
```
------
有关服务持有者令牌的示例，请参阅《*AWS CodeArtifact* 用户指南》中的[为 AWS CodeArtifact 使用基于身份的策略](https://docs.aws.amazon.com/codeartifact/latest/ug/auth-and-access-control-iam-identity-based-access-control.html)。
# 请求临时安全凭证
要请求临时安全凭证，您可以在 AWS API 中使用 AWS Security Token Service (AWS STS) 操作。这些操作包括创建受信任用户，并为其提供可以控制 AWS 资源访问的临时安全凭证。有关 AWS STS 的更多信息，请参阅 [IAM 临时安全凭证](id_credentials_temp.md)。要了解在担任角色以请求临时安全凭证时使用的各种方法，请参阅[担任角色的方法](id_roles_manage-assume.md)。
要调用 API 操作，您可以使用其中的一个 [AWS SDK](https://aws.amazon.com/tools/)。这些开发工具包适用于各种不同的编程语言和环境，包括 Java、.NET、Python、Ruby、Android 和 iOS。这些开发工具包负责处理各种任务，如以加密方式对您的请求进行签名、在必要时重试请求以及处理错误响应。还可使用 AWS STS 查询 API（在 [AWS Security Token Service API 参考](https://docs.aws.amazon.com/STS/latest/APIReference/)中介绍）。最后，两个命令行工具支持 AWS STS 命令：[AWS Command Line Interface](https://aws.amazon.com/documentation/cli)和[AWS Tools for Windows PowerShell](https://aws.amazon.com/documentation/powershell)。
AWS STS API 操作使用临时安全凭证（包括访问密钥对和会话令牌）创建新会话。访问密钥对由访问密钥 ID 和私有密钥组成。用户 (或用户所运行的应用程序) 可使用这些凭证访问您的资源。您可以使用 AWS STS API 操作以编程方式创建角色会话和传递会话策略及会话标签。生成的会话的权限是角色的基于身份的策略与会话策略的交集。有关会话策略的更多信息，请参阅[会话策略](access_policies.md#policies_session)。有关会话标签的更多信息，请参阅 [在 AWS STS 中传递会话标签](id_session-tags.md)。
**注意**
AWS STS API 操作返回的会话令牌大小不固定。我们强烈建议不要假设最大大小。典型的令牌大小小于 4096 字节，但可能会发生变化。
## 通过 AWS 区域使用 AWS STS
您可以将 AWS STS API 调用发送到全球终端节点或某个区域终端节点。如果您选择更靠近您的终端节点，则可减少延迟并改善 API 调用的性能。如果您不再能与原始终端节点进行通信，也可选择将调用定向到替代的区域终端节点。如果您使用某种 AWS SDK，请先使用该开发工具包的方法指定一个区域，然后再进行 API 调用。如果您正在手动构建 HTTP API 请求，则必须自行将请求定向到正确的终端节点。有关更多信息，请参阅[*区域和终端节点*和 [管理 AWS 区域中的 AWS STS](id_credentials_temp_enable-regions.md) 的 AWS STS 部分](https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region)。
下面是让您可以用来获取临时凭证以用于您的 AWS 环境和应用程序的 API 操作。
## 请求通过自定义身份凭证代理程序进行跨账户委派和联合身份验证的凭证
[https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html) API 操作对于允许现有 IAM 用户访问其没有访问权限的 AWS 资源很有用。例如，用户可能需要对其他 AWS 账户 中资源的访问权限。此外，可使用它来暂时获得特权访问权限 - 例如，提供多重身份验证 (MFA)。您必须使用活动凭证调用该 API。要了解谁可以调用此操作，请参阅 [比较 AWS STS 凭证](id_credentials_sts-comparison.md)。有关更多信息，请参阅[创建角色，向 IAM 用户授予权限](id_roles_create_for-user.md)和[使用 MFA 保护 API 访问](id_credentials_mfa_configure-api-require.md)。
**要请求通过自定义身份凭证代理程序进行跨账户委派和联合身份验证的临时安全凭证**
1. 使用您的 AWS 安全凭证进行身份验证。必须使用有效的 AWS 安全凭证来进行此调用。
1. 调用 [https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html) 操作。
以下示例显示了使用 `AssumeRole` 的示例请求和响应。此示例请求将在指定的持续时间内担任 `demo` 角色，其中包含[会话策略](access_policies.md#policies_session)、[会话标签](id_session-tags.md)、[外部 ID](id_roles_common-scenarios_third-party.md) 和[源身份](id_credentials_temp_control-access_monitor.md)。生成的会话命名为 `John-session`。
**Example 示例请求**
```
https://sts.amazonaws.com/
?Version=2011-06-15
&Action=AssumeRole
&RoleSessionName=John-session
&RoleArn=arn:aws::iam::123456789012:role/demo
&Policy=%7B%22Version%22%3A%222012-10-17 %22%2C%22Statement%22%3A%5B%7B%22Sid%22%3A%20%22Stmt1%22%2C%22Effect%22%3A%20%22Allow%22%2C%22Action%22%3A%20%22s3%3A*%22%2C%22Resource%22%3A%20%22*%22%7D%5D%7D
&DurationSeconds=1800
&Tags.member.1.Key=Project
&Tags.member.1.Value=Pegasus
&Tags.member.2.Key=Cost-Center
&Tags.member.2.Value=12345
&ExternalId=123ABC
&SourceIdentity=DevUser123
&AUTHPARAMS
```
在前面的示例中显示的策略值是以下策略的 URL 编码版本：
------
#### [ JSON ]
****
```
{"Version":"2012-10-17", "Statement":[{"Sid":"Stmt1","Effect":"Allow","Action":"s3:*","Resource":"*"}]}
```
------
示例中的 `AUTHPARAMS` 参数是您的*签名* 的占位符。签名是您必须在 AWS HTTP API 请求中包含的身份验证信息。建议使用 [AWS 开发工具包](https://aws.amazon.com/tools/)创建 API 请求，这样做的一个好处是开发工具包将为您处理请求签名。如果您必须手动创建并签署 API 请求，请参阅《Amazon Web Services 一般参考》中的 [使用签名版本 4 签署 AWS 请求](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html)**，以了解如何签署请求。
除了临时安全凭证之外，该响应还包括联合身份用户的 Amazon Resource Name (ARN) 和凭证的到期时间。
**Example 响应示例**
```
DevUser123
AQoDYXdzEPT//////////wEXAMPLEtc764bNrC9SAPBSM22wDOk4x4HIZ8j4FZTwdQW
LWsKWHGBuFqwAeMicRXmxfpSPfIeoIYRqTflfKD8YUuwthAx7mSEI/qkPpKPi/kMcGd
QrmGdeehM4IC1NtBmUpp2wUE8phUZampKsburEDy0KPkyQDYwT7WZ0wq5VSXDvp75YU
9HFvlRd8Tx6q6fE8YQcHNVXAkiY9q6d+xo0rKwT38xVqr7ZD0u0iPPkUL64lIZbqBAz
+scqKmlzm8FDrypNC9Yjc8fPOLn9FX9KSYvKTr4rvx3iSIlTJabIQwj2ICCR/oLxBA==
wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY
2019-07-15T23:28:33.359Z
AKIAIOSFODNN7EXAMPLE
arn:aws:sts::123456789012:assumed-role/demo/John
ARO123EXAMPLE123:John
8
c6104cbe-af31-11e0-8154-cbc7ccf896c7
```
**注意**
AWS 转换会将传递的会话策略和会话标签压缩为具有单独限制的打包二进制格式。即使您的纯文本符合其他要求，您的请求也可能会由于此限制而失败。`PackedPolicySize` 响应元素指示您请求的策略和标签接近大小上限的程度，以百分比来表示。
## 通过 OIDC 提供商请求凭证
[https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) API 操作返回一组临时的 AWS 安全凭证，以换取 JSON Web 令牌（JWT）。这包括公共身份提供者，例如，使用 Login with Amazon、Facebook、Google，以及发布与 OpenID Connect（OIDC）发现兼容的 JWT 的提供者，例如 GitHub 操作或 Azure Devops。有关更多信息，请参阅 [OIDC 联合身份验证](id_roles_providers_oidc.md)。
**注意**
`AssumeRoleWithWebIdentity` 请求未使用签名，也不需要 AWS 凭证。
**通过 OIDC 提供商请求凭证**
1. 调用 [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) 操作。
当您调用 `AssumeRoleWithWebIdentity` 时，AWS 会使用通过 IdP 的 JSON Web 密钥集（JWKS）提供的公钥验证数字签名，从而验证所提供的令牌。如果令牌有效，并且满足 IAM 角色信任策略中规定的所有条件，则 AWS 会向您返回以下信息：
+ 一组临时安全凭证。这些证书由访问密钥 ID、秘密访问密钥和会话令牌组成。
+ 所担任角色的角色 ID 和 ARN。
+ 一个 `SubjectFromWebIdentityToken` 值，其中包含独一无二的用户 ID。
1. 然后，您的应用程序可以使用响应中返回的临时安全凭证进行 AWS API 调用。该过程与使用长期安全凭证进行 AWS API 调用相同。不同之处在于，您必须包含会话令牌，以便 AWS 验证临时安全凭证是否有效。
您的应用程序应缓存 AWS STS 返回的凭证，并根据需要刷新凭证。如果您的应用程序是使用 AWS SDK 构建的，则 SDK 的凭证提供者可以在凭证过期之前处理调用 `AssumeRoleWithWebIdentity` 和刷新 AWS 凭证。有关更多信息，请参阅《AWS SDK 和工具参考指南》**中的《AWS SDK 和工具标准化凭证提供者》[https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html)。
## 通过 SAML 2.0 身份提供商请求凭证
[https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) API 操作为通过您的组织的现有身份系统验证的 SAML 联合主体返回一组临时安全凭证。用户还必须使用 [SAML](https://www.oasis-open.org/standards#samlv2.0) 2.0（安全断言标记语言）将身份验证和授权信息传递给 AWS。对于将身份系统 (如 Windows Active Directory 或 OpenLDAP) 与可生成 SAML 断言的软件集成在一起的组织，该 API 操作是非常有用的。此类集成提供有关用户身份和权限 (如 Active Directory 联合身份验证服务或 Shibboleth) 的信息。有关更多信息，请参阅 [SAML 2.0 联合身份验证](id_roles_providers_saml.md)。
1. 调用 [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) 操作。
这是一个未签名的调用，意味着您无需在发出请求之前对 AWS 安全凭证进行身份验证。
**注意**
对 `AssumeRoleWithSAML` 的调用未签名 (加密)。因此，只有在通过受信任的中介传输请求时，才应包含可选的会话策略。在这种情况下，有人可能会修改策略以删除限制。
1. 调用 `AssumeRoleWithSAML` 时，AWS 将验证 SAML 断言的真实性。假定身份提供程序证实断言有效，则 AWS 向您返回以下信息：
+ 一组临时安全凭证。这些证书由访问密钥 ID、秘密访问密钥和会话令牌组成。
+ 所担任角色的角色 ID 和 ARN。
+ `Audience` 值，包含 SAML 断言的 `Recipient` 元素的 `SubjectConfirmationData` 属性值。
+ `Issuer` 值，包含 SAML 断言的 `Issuer` 元素值。
+ `NameQualifier` 元素，包含通过 `Issuer` 值、AWS 账户 ID 以及 SAML 提供商的易记名称生成的哈希值。与 `Subject` 元素相结合时，它们可以唯一地标识 SAML 联合主体。
+ `Subject` 元素，包含 SAML 断言的 `NameID` 元素的 `Subject` 元素值。
+ `SubjectType` 元素，指示 `Subject` 元素的格式。值可以是 `persistent`、`transient` 或在您的 SAML 断言中使用的 `Format` 和 `Subject` 元素的完整 `NameID` URI。有关 `NameID` 元素的 `Format` 属性的信息，请参阅[为身份验证响应配置 SAML 断言。](id_roles_providers_create_saml_assertions.md)。
1. 使用响应中返回的临时安全凭证进行 AWS API 调用。该过程与使用长期安全凭证进行 AWS API 调用相同。不同之处在于，您必须包含会话令牌，以便 AWS 验证临时安全凭证是否有效。
您的应用程序应缓存凭证。默认情况下，凭证在 1 小时后到期。如果未使用 [ 软件开发工具包中的 ](https://aws.amazon.com/blogs/mobile/using-the-amazoncredentialsprovider-protocol-in-the-aws-sdk-for-ios)AmazonSTSCredentialsProviderAWS 操作，则由您和您的应用程序负责再次调用 `AssumeRoleWithSAML`。在旧安全凭证到期之前，可以调用该操作以获取一组新的临时安全凭证。
## 通过自定义身份凭证代理程序请求凭证
[https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) API 操作为 AWS STS 联合用户主体返回一组临时安全凭证。该 API 不同于 `AssumeRole`，其默认有效期大大增加 (12 小时而不是 1 小时)。此外，您还可以使用 `DurationSeconds` 参数指定临时安全凭证保持有效的持续时间。生成的凭证在指定的时间段内有效，介于 900 秒（15 分钟）到 129600 秒（36 小时）之间。较长的有效期有助于减少调用 AWS 的次数，因为您不需要经常获取新凭证。
1. 使用您的特定 IAM 用户的 AWS 安全凭证进行身份验证。必须使用有效的 AWS 安全凭证来进行此调用。
1. 调用 [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) 操作。
`GetFederationToken` 调用将返回临时安全凭证，其中包括会话令牌、访问密钥、私有密钥和到期时间。如果要在组织内管理权限 (例如，使用代理应用程序分配权限)，则可使用 `GetFederationToken`。
以下示例显示了使用 `GetFederationToken` 的示例请求和响应。此示例请求使用[会话策略](access_policies.md#policies_session) ARN 和[会话标签](id_session-tags.md)，在指定的持续时间内联合调用用户的身份。生成的会话命名为 `Jane-session`。
**Example 示例请求**
```
https://sts.amazonaws.com/
?Version=2011-06-15
&Action=GetFederationToken
&Name=Jane-session
&PolicyArns.member.1.arn==arn%3Aaws%3Aiam%3A%3A123456789012%3Apolicy%2FRole1policy
&DurationSeconds=1800
&Tags.member.1.Key=Project
&Tags.member.1.Value=Pegasus
&Tags.member.2.Key=Cost-Center
&Tags.member.2.Value=12345
&AUTHPARAMS
```
上述示例中显示的策略 ARN 包含以下 URL 编码的 ARN：
`arn:aws:iam::123456789012:policy/Role1policy`
还要注意，该示例中的 `&AUTHPARAMS` 参数用作身份验证信息的占位符。这是*签名*，您必须将其包括在 AWS HTTP API 请求中。建议使用 [AWS 开发工具包](https://aws.amazon.com/tools/)创建 API 请求，这样做的一个好处是开发工具包将为您处理请求签名。如果您必须手动创建并签署 API 请求，请访问《Amazon Web Services 一般参考》中的 [使用签名版本 4 签署 AWS 请求](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html)**，以了解如何签署请求。
除了临时安全凭证之外，该响应还包括联合身份用户的 Amazon Resource Name (ARN) 和凭证的到期时间。
**Example 响应示例**
```
AQoDYXdzEPT//////////wEXAMPLEtc764bNrC9SAPBSM22wDOk4x4HIZ8j4FZTwdQW
LWsKWHGBuFqwAeMicRXmxfpSPfIeoIYRqTflfKD8YUuwthAx7mSEI/qkPpKPi/kMcGd
QrmGdeehM4IC1NtBmUpp2wUE8phUZampKsburEDy0KPkyQDYwT7WZ0wq5VSXDvp75YU
9HFvlRd8Tx6q6fE8YQcHNVXAkiY9q6d+xo0rKwT38xVqr7ZD0u0iPPkUL64lIZbqBAz
+scqKmlzm8FDrypNC9Yjc8fPOLn9FX9KSYvKTr4rvx3iSIlTJabIQwj2ICCEXAMPLE==
wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY
2019-04-15T23:28:33.359Z
AKIAIOSFODNN7EXAMPLE;
arn:aws:sts::123456789012:federated-user/Jean
123456789012:Jean
4
c6104cbe-af31-11e0-8154-cbc7ccf896c7
```
**注意**
AWS 转换会将传递的会话策略和会话标签压缩为具有单独限制的打包二进制格式。即使您的纯文本符合其他要求，您的请求也可能会由于此限制而失败。`PackedPolicySize` 响应元素指示您请求的策略和标签接近大小上限的程度，以百分比来表示。
AWS 建议您在资源级别授予权限（例如，将基于资源的策略附加到 Amazon S3 存储桶），则可省略 `Policy` 参数。但是，如果不加入针对 AWS STS 联合用户主体的策略，则临时安全凭证将不授予任何权限。在这种情况下，您*必须* 使用资源策略为联合身份用户授予您的 AWS 资源的访问权限。
例如，假设您的 AWS 账户 号码为 111122223333，且您拥有希望允许 Susan 访问的 Amazon S3 存储桶。Susan 的临时安全凭证不包括该存储桶的策略。在这种情况下，您需要确保该存储桶的策略具有与 Susan 的 ARN (如 `arn:aws:sts::111122223333:federated-user/Susan`) 匹配的 ARN。
## 为不受信任的环境中的用户请求凭证
[https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) API 操作向现有 IAM 用户返回一组临时安全凭证。此 API 对提高安全性非常有用，例如在已针对 IAM 用户启用 MFA 的情况下提出 AWS 请求。由于凭证是临时的，因此，在 IAM 用户通过不太安全的环境访问您的资源时，它们提供了增强的安全性。不太安全的环境示例包括移动设备或 Web 浏览器。
1. 使用您的特定 IAM 用户的 AWS 安全凭证进行身份验证。必须使用有效的 AWS 安全凭证来进行此调用。
1. 调用 [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) 操作。
1. `GetSessionToken` 将返回临时安全凭证，其中包括会话令牌、访问密钥 ID 和秘密访问密钥。
默认情况下，IAM 用户的临时安全凭证的有效期最长为 12 小时。但是，您可以使用 `DurationSeconds` 参数请求短至 15 分钟或长达 36 小时的持续时间。出于安全考虑，AWS 账户根用户的令牌有效期仅为一小时。
以下示例显示了使用 `GetSessionToken` 的示例请求和响应。响应也包括了临时安全凭证的过期时间。
**Example 示例请求**
```
https://sts.amazonaws.com/
?Version=2011-06-15
&Action=GetSessionToken
&DurationSeconds=1800
&AUTHPARAMS
```
示例中的 `AUTHPARAMS` 参数是您的*签名* 的占位符。签名是您必须在 AWS HTTP API 请求中包含的身份验证信息。建议使用 [AWS 开发工具包](https://aws.amazon.com/tools/)创建 API 请求，这样做的一个好处是开发工具包将为您处理请求签名。如果您必须手动创建并签署 API 请求，请访问《Amazon Web Services 一般参考》中的 [使用签名版本 4 签署 AWS 请求](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html)**，以了解如何签署请求。
**Example 响应示例**
```
AQoEXAMPLEH4aoAH0gNCAPyJxz4BlCFFxWNE1OPTgk5TthT+FvwqnKwRcOIfrRh3c/L
To6UDdyJwOOvEVPvLXCrrrUtdnniCEXAMPLE/IvU1dYUg2RVAJBanLiHb4IgRmpRV3z
rkuWJOgQs8IZZaIv2BXIa2R4OlgkBN9bkUDNCJiBeb/AXlzBBko7b15fjrBs2+cTQtp
Z3CYWFXG8C5zqx37wnOE49mRl/+OtkIKGO7fAE
wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY
2011-07-11T19:55:29.611Z
AKIAIOSFODNN7EXAMPLE
58c5dbae-abef-11e0-8cfe-09039844ac7d
```
（可选）`GetSessionToken` 请求可能包括 `SerialNumber` 和 `TokenCode` 值以进行 AWS Multi-Factor Authentication (MFA) 验证。如果提供的值有效，AWS STS 将提供包含 MFA 身份验证状态的临时安全凭证。然后，可以使用临时安全凭证访问受 MFA 保护的 API 操作或 AWS 网站，但前提是 MFA 身份验证有效。
下例展示一个 `GetSessionToken` 请求，其中包括 MFA 验证代码和设备序列号。
```
https://sts.amazonaws.com/
?Version=2011-06-15
&Action=GetSessionToken
&DurationSeconds=7200
&SerialNumber=YourMFADeviceSerialNumber
&TokenCode=123456
&AUTHPARAMS
```
**注意**
对 AWS STS 的调用可能针对的是全局端点，也可能针对的是激活您的 AWS 账户 的任何区域终端节点。有关更多信息，请参阅[*区域和终端节点*的 AWS STS 部分](https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region)。
示例中的 `AUTHPARAMS` 参数是您的*签名* 的占位符。签名是您必须在 AWS HTTP API 请求中包含的身份验证信息。建议使用 [AWS 开发工具包](https://aws.amazon.com/tools/)创建 API 请求，这样做的一个好处是开发工具包将为您处理请求签名。如果您必须手动创建并签署 API 请求，请参阅《Amazon Web Services 一般参考》中的 [使用签名版本 4 签署 AWS 请求](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html)**，以了解如何签署请求。
# 将临时凭证用于 AWS 资源
借助 AWS CLI 或 AWS API（使用 [AWS SDK](https://aws.amazon.com/tools/)），您可以使用临时安全凭证提出对 AWS 资源的编程请求。临时凭证提供的权限与长期安全凭证（例如 IAM 用户凭证）相同。但还是有几个区别：
+ 使用临时安全凭证进行调用时，必须在调用中包含随这些临时凭证一同返回的会话令牌。AWS 使用该会话令牌来验证临时安全凭证的有效性。
+ 临时凭证在指定间隔后到期。临时凭证到期后，任何使用这些凭证进行的调用都将失败，因此您必须生成一组新的临时凭证。临时凭证的延期或刷新时间不得超过最初指定的时间间隔。
+ 当您使用临时凭证发出请求时，您的主体可能会包含一组标签。这些标签来自附加到您代入的角色的会话标签和标签。有关会话标签的更多信息，请参阅 [在 AWS STS 中传递会话标签](id_session-tags.md)。
如果您使用的是 [AWS SDK](https://aws.amazon.com/tools)、[AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/) (AWS CLI) 或 [Tools for Windows PowerShell](https://aws.amazon.com/powershell)，则获取和使用临时安全凭证的方式随上下文而不同。如果您在 AWS CLI 内部运行代码、 或 Tools for Windows PowerShell 命令，则可使用 Amazon EC2 的角色。否则，您可调用 [AWS STS API](https://docs.aws.amazon.com/STS/latest/APIReference/) 来获取临时凭证，然后使用这些凭证显式地调用 AWS 服务。
**注意**
您可以使用 AWS Security Token Service (AWS STS) 创建可控制对您的 AWS 资源的访问的临时安全凭证，并将这些凭证提供给可信用户。有关 AWS STS 的更多信息，请参阅[IAM 临时安全凭证](id_credentials_temp.md)。AWS STS 是一种全球服务，在 `https://sts.amazonaws.com` 上具有默认终端节点。此端点处于美国东部（弗吉尼亚州北部）区域，不过，您从此端点和其他端点获取的凭证在全球范围都有效。这些凭证可用于任何区域中的服务和资源。您也可以选择对任何支持的区域中的终端节点进行 AWS STS API 调用。这可能会从地理位置离您较近的区域的服务器中发出请求以减少延迟。无论您的凭证来自于哪个区域，它们都会在全球范围内起作用。有关更多信息，请参阅 [管理 AWS 区域中的 AWS STS](id_credentials_temp_enable-regions.md)。
**Contents**
+ [在 Amazon EC2 实例中使用临时凭证](#using-temp-creds-sdk-ec2-instances)
+ [将临时安全凭证用于 AWS SDK。](#using-temp-creds-sdk)
+ [将临时安全凭证用于 AWS CLI。](#using-temp-creds-sdk-cli)
+ [将临时安全凭证用于 API 操作](#RequestWithSTS)
+ [更多信息](#using-temp-creds-more-info)
## 在 Amazon EC2 实例中使用临时凭证
如果要在 EC2 实例内部运行 AWS CLI 命令或代码，建议的获取凭证的方法是使用 [Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) 的角色。您可创建一个 IAM 角色，通过该角色指定要授予在 EC2 实例中运行的应用程序的权限。启动实例时，将该角色关联至实例。
之后，在该实例上运行的应用程序、AWS CLI 和 Tools for Windows PowerShell 命令将能够从该实例的元数据获取自动临时安全凭证。您无需明确获取临时安全凭证。AWS SDK、AWS CLI 和 Tools for Windows PowerShell 自动从 EC2 实例元数据服务 (IMDS) 获取凭证并使用它们。临时凭证具有您为与该实例关联的角色定义的权限。
有关更多信息及示例，请参阅：
+ [使用 IAM 角色授予对 Amazon Elastic Compute Cloud 上 AWS 资源的访问权](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java-dg-roles.html) — 适用于 Java 的 AWS SDK
+ [使用 IAM 角色授予访问权限 IAM ](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/net-dg-hosm.html) - 适用于 .NET 的 AWS SDK
+ [创建角色](https://docs.aws.amazon.com/sdk-for-ruby/latest/developer-guide/iam-example-create-role.html) - 适用于 Ruby 的 AWS SDK
## 将临时安全凭证用于 AWS SDK。
要在代码中使用临时安全凭证，可以编程方式调用类似于 AWS STS 的 `AssumeRole` API，提取生成的凭证和会话令牌。然后，您可以使用这些值作为对 AWS 的后续调用的凭证。以下示例说明了有关使用 AWS 开发工具包时如何使用临时安全凭证的伪代码：
```
assumeRoleResult = AssumeRole(role-arn);
tempCredentials = new SessionAWSCredentials(
assumeRoleResult.AccessKeyId,
assumeRoleResult.SecretAccessKey,
assumeRoleResult.SessionToken);
s3Request = CreateAmazonS3Client(tempCredentials);
```
有关用 Python 编写的示例（使用 [AWS SDK for Python (Boto)](https://aws.amazon.com/sdk-for-python/)），请参阅[切换到 IAM 角色（AWS API）](id_roles_use_switch-role-api.md)。此示例说明如何调用 `AssumeRole` 以获取临时安全凭证，然后使用这些凭证调用 Amazon S3。
有关如何调用 `AssumeRole`、`GetFederationToken` 和其他 API 操作的详细信息，请参阅 [AWS Security Token Service API 参考](https://docs.aws.amazon.com/STS/latest/APIReference/)。有关从结果中获取临时安全凭证和会话令牌的信息，请参阅所用开发工具包的文档。可以在主 [AWS 文档页](https://aws.amazon.com/documentation)上的 **SDKs and Toolkits**（开发工具包和工具箱）部分中找到所有 AWS SDK 的文档。
您必须确保在旧凭证到期之前，获得一组新的凭证。在某些开发工具包中，可让提供商为您管理刷新凭证的过程；并可检查所用开发工具包的文档。
## 将临时安全凭证用于 AWS CLI。
可将临时安全凭证用于 AWS CLI。这对于测试策略来说很有用。
借助 [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/)，您可以调用 `AssumeRole` 或 `GetFederationToken` 之类的 [AWS STS API](https://docs.aws.amazon.com/STS/latest/APIReference/)，然后捕获输出结果。下面的示例说明了一个将输出发送至文件的 `AssumeRole` 调用。在示例中，假定 `profile` 参数是配置文件中的 AWS CLI 配置文件。它还假定为有权代入角色的 IAM 用户引用凭证。
```
aws sts assume-role --role-arn arn:aws:iam::123456789012:role/role-name --role-session-name "RoleSession1" --profile IAM-user-name > assume-role-output.txt
```
当命令完成后，您可以从路由到的任意位置中提取访问密钥 ID、秘密访问密钥和会话令牌。您可以手动或使用脚本执行此操作。之后，您可以将这些值分配给环境变量。
在运行 AWS CLI 命令时，AWS CLI 依特定顺序查找凭证 - 首先查找环境变量，然后是配置文件。因此，在将临时凭证放入环境变量后，AWS CLI 会默认使用这些凭证。（如果在该命令中指定了 `profile` 参数，则 AWS CLI 将跳过环境变量，而 AWS CLI 在配置文件中查找，这使您能够根据需要覆盖环境变量中的凭证。）
下面的示例说明了如何为临时安全凭证设置环境变量然后调用 AWS CLI 命令。由于未在 AWS CLI 命令中包含 `profile` 参数，AWS CLI 首先在环境变量中查找凭证，因而将使用该临时凭证。
**Linux**
```
$ export AWS_ACCESS_KEY_ID=ASIAIOSFODNN7EXAMPLE
$ export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
$ export AWS_SESSION_TOKEN=AQoDYXdzEJr...
$ aws ec2 describe-instances --region us-west-1
```
**Windows**
```
C:\> SET AWS_ACCESS_KEY_ID=ASIAIOSFODNN7EXAMPLE
C:\> SET AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
C:\> SET AWS_SESSION_TOKEN=AQoDYXdzEJr...
C:\> aws ec2 describe-instances --region us-west-1
```
## 将临时安全凭证用于 API 操作
如果是直接向 AWS 发出 HTTPS API 请求，则可以使用从 AWS Security Token Service (AWS STS) 获取的临时安全凭证对这些请求进行签名。为此，您可以使用接收自 AWS STS 的访问密钥 ID 和秘密访问密钥。您使用访问密钥 ID 和秘密访问密钥的方式，与使用长期凭证对请求签名是一样的。此外，还要将您从 AWS STS 获得的会话令牌添加到 API 请求中。将会话令牌添加到 HTTP 标头或名为 `X-Amz-Security-Token` 的查询字符串参数中。将会话令牌添加到 HTTP 标头*或* 查询字符串参数，但不是同时添加到这两者。有关签署 HTTPS API 请求的更多信息，请参阅《AWS 一般参考》中的 [签署 AWS API 请求](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html)**。
## 更多信息
有关将 AWS STS 与其他 AWS 服务结合使用的更多信息，请参阅以下链接：
+ **Amazon S3**。请参阅《Amazon Simple Storage Service 用户指南》中的 [使用 IAM 用户临时凭证创建请求](https://docs.aws.amazon.com/AmazonS3/latest/userguide/AuthUsingTempSessionToken.html) 或者 [使用联合用户临时凭证创建请求](https://docs.aws.amazon.com/AmazonS3/latest/userguide/AuthUsingTempFederationToken.html)**。
+ **Amazon SNS**。请参阅《Amazon Simple Notification Service 开发人员指南》**中的[将基于身份的策略用于 Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/UsingIAMwithSNS.html#UsingTemporarySecurityCredentials_SNS)。
+ **Amazon SQS**。请参阅《Amazon Simple Queue Service 开发人员指南》**中的 [Amazon SQS 中的 Identity and Access Management](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/UsingIAM.html#UsingTemporarySecurityCredentials_SQS)。
+ **Amazon SimpleDB**。请参阅 *Amazon SimpleDB 开发人员指南*中的[使用临时安全凭证](https://docs.aws.amazon.com/AmazonSimpleDB/latest/DeveloperGuide/index.html?UsingTemporarySecurityCredentials_SDB.html)。
# 临时安全凭证的权限
您可以使用 AWS Security Token Service (AWS STS) 创建可控制对您的 AWS 资源的访问的临时安全凭证，并将这些凭证提供给可信用户。有关 AWS STS 的更多信息，请参阅 [IAM 临时安全凭证](id_credentials_temp.md)。AWS STS 颁发临时安全凭证后，这些凭证在到期时间之前有效，并且无法撤消。但是，由于每次使用证书发出请求时都会评估分配给临时安全凭证的权限，因此，即使证书已经签发，您仍可通过更改证书的访问权限来实现撤消证书的效果。
以下主题假定您具备一些 AWS 权限和策略方面的知识。有关这些主题的更多信息，请参阅[适用于 AWS 资源的 Access Management](access.md)。
**Topics**
+ [AssumeRole、AssumeRoleWithSAML 和 AssumeRoleWithWebIdentity 的权限](id_credentials_temp_control-access_assumerole.md)
+ [监控和控制使用所担任角色执行的操作](id_credentials_temp_control-access_monitor.md)
+ [GetFederationToken 的权限](id_credentials_temp_control-access_getfederationtoken.md)
+ [GetSessionToken 的权限](id_credentials_temp_control-access_getsessiontoken.md)
+ [禁用临时安全凭证的权限](id_credentials_temp_control-access_disable-perms.md)
+ [授予创建临时安全凭证的权限](id_credentials_temp_control-access_enable-create.md)
+ [授予使用身份增强控制台会话的权限](id_credentials_temp_control-access_sts-setcontext.md)
# AssumeRole、AssumeRoleWithSAML 和 AssumeRoleWithWebIdentity 的权限
所担任的角色的权限策略决定由 `AssumeRole`、`AssumeRoleWithSAML` 和 `AssumeRoleWithWebIdentity` 返回的临时安全凭证的权限。您可在创建或更新该角色时定义这些权限。
（可选）您可以将内联或托管[会话策略](access_policies.md#policies_session)作为 `AssumeRole`、`AssumeRoleWithSAML` 或 `AssumeRoleWithWebIdentity` API 操作的参数传递。会话策略限制角色的临时凭证会话的权限。生成的会话的权限是角色的基于身份的策略与会话策略的交集。您可以在后续的 AWS API 调用中使用角色的临时凭证来访问拥有该角色的账户中的资源。您使用会话策略授予的权限不能超过担任的角色的基于身份的策略允许的权限。要了解有关 AWS 如何确定角色的有效权限的更多信息，请参阅[策略评估逻辑](reference_policies_evaluation-logic.md)。
![\[PermissionsWhenPassingRoles_Diagram\]](http://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/images/role_passed_policy_permissions.png)
在做出“允许”或“拒绝”授权决定时，AWS 不会对附加至发出 `AssumeRole` 原始调用的凭证的策略进行评估。用户将临时放弃其原始权限，以支持担任的角色所分配的权限。对于 `AssumeRoleWithSAML` 和 `AssumeRoleWithWebIdentity` API 操作，不会有任何策略受到评估，因为这些 API 的发起人不是 AWS 身份。
## 示例：使用 AssumeRole 分配权限
您可以将 `AssumeRole` API 操作与不同类型的策略结合使用。以下是一些示例。
### 角色权限策略
在本示例中，您调用 `AssumeRole` API 操作，而无需在可选 `Policy` 参数中指定会话策略。分配给临时凭证的权限取决于所担任角色的权限策略。以下示例权限策略向角色授予权限，允许该角色列出名为 `productionapp` 的 S3 存储桶中包含的所有对象。它还允许该角色获取、放置和删除该存储桶中的对象。
**Example 角色权限策略示例**
****
```
{
"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/*"
}
]
}
```
### 作为参数传递的会话策略
假设您希望允许某用户担任上例中的相同角色。但在这种情况下，您希望角色会话只具有在 `productionapp` S3 存储桶中获取和放入对象的权限。您不希望允许他们删除对象。完成该操作的一种方法是创建一个新角色，并在该角色的权限策略中指定所需的权限。完成该操作的另一种方法是，调用 `AssumeRole` API 并在可选的 `Policy` 参数中包含会话策略以作为 API 操作的一部分。生成的会话的权限是角色的基于身份的策略与会话策略的交集。使用会话策略授予的权限不能超过担任的角色的基于身份的策略允许的权限。有关角色会话权限的更多信息，请参阅[会话策略](access_policies.md#policies_session)。
在检索新会话的临时凭证后，您可以将其传递给希望具有这些权限的用户。
例如，假设将以下策略作为该 API 调用的参数传递。使用会话的用户只具备执行以下操作的权限：
+ 列出 `productionapp` 存储桶中的所有对象。
+ 获取 `productionapp` 存储桶中的对象或向其中上传对象。
在以下会话策略中，`s3:DeleteObject` 权限已被筛选掉，因此，未向担任的会话授予 `s3:DeleteObject` 权限。该策略为角色会话设置最大权限，以便它覆盖角色上的任何现有权限策略。
**Example 通过 `AssumeRole` API 调用传递的示例会话策略**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::productionapp"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::productionapp/*"
}
]
}
```
### 基于资源的策略
某些 AWS 资源支持基于资源的策略，这些策略提供另一种机制用于定义影响临时安全凭证的权限。仅几种资源（如 Amazon S3 存储桶、Amazon SNS 主题和 Amazon SQS 队列）支持基于资源的策略。下面的示例使用名为 `productionapp` 的 S3 存储桶进一步阐述上述示例。以下策略被附加到该存储桶。
在将以下基于资源的策略附加到 `productionapp` 存储桶时，将会拒绝*所有* 用户从该存储桶中删除对象的权限。（请参阅策略中的 `Principal` 元素。） 这包括所有担任角色的用户（即使角色权限策略授予了 `DeleteObject` 权限）。显式 `Deny` 语句总是优先于 `Allow` 语句。
**Example 存储桶策略的示例**
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": {"AWS": "*"},
"Effect": "Deny",
"Action": "s3:DeleteObject",
"Resource": "arn:aws:s3:::productionapp/*"
}
}
```
有关 AWS 如何对多个策略类型进行合并和评估的更多信息，请参阅[策略评估逻辑](reference_policies_evaluation-logic.md)。
# 监控和控制使用所担任角色执行的操作
[IAM 角色](id_roles.md)是 IAM 中分配[权限](access_policies.md)的对象。当您使用 IAM 身份或来自 AWS 以外的身份[担任该角色](id_roles_manage-assume.md)时，将会收到具有分配给该角色的权限的会话。
当您在 AWS 中执行操作时，则有关您会话的信息可以记录到 AWS CloudTrail 以便您的账户管理员进行监控。管理员可以配置角色以要求身份来传递自定义字符串，该字符串标识在 AWS 中执行操作的个人或应用程序，称为源身份。此身份信息在 AWS CloudTrail 中存储为*源身份*。当管理员查看 CloudTrail 中的活动时，他们可以查看源身份信息，以确定谁通过担任角色会话执行了操作或执行了哪些操作。
设置源身份后，它会出现在任何在角色会话期间执行的 AWS 操作的请求中。当角色用于通过 AWS CLI 或者 AWS API 担任其他角色时，设置的值仍然存在，这称为[角色链](id_roles.md#iam-term-role-chaining)。在角色会话期间无法更改已设置的值。管理员可以根据源身份的存在或值配置精细权限，以进一步控制使用共享角色执行的 AWS 操作。您可以决定是否可以使用源身份属性、是否需要该属性以及可以使用哪些值。
使用源身份的方式与使用角色会话名称和会话标签的方式大有不同。设置后，源身份值无法更改，并且对角色会话执行的任何其他操作将持续存在。以下是如何使用会话标签和角色会话名称的说明：
+ **Session tags**（会话标签）- 您也可以在代入角色或联合身份用户时传递会话标签。担任角色时会出现会话标签。您可以定义策略，这些策略使用标签条件键来根据主体的标签向其授予权限。然后您可以使用 CloudTrail 查看为代入角色或联合身份用户而发出的请求。要了解会话标签的更多信息，请参阅 [在 AWS STS 中传递会话标签](id_session-tags.md)。
+ **Role session name**（角色会话名称）- 您可以在角色信任策略中使用 `sts:RoleSessionName` 条件键，以要求您的用户在代入角色时提供特定的会话名称。角色会话名称可用于区分角色由不同主体使用时的角色会话。要了解角色会话名称的更多信息，请参阅 [sts:RoleSessionName](reference_policies_iam-condition-keys.md#ck_rolesessionname)。
我们建议您在要控制担任角色的身份时使用源身份。源身份在挖掘 CloudTrail 日志以确定是何人在使用该角色执行操作时也很有用。
**Topics**
+ [设置以使用源身份](#id_credentials_temp_control-access_monitor-setup)
+ [有关源身份的需知信息](#id_credentials_temp_control-access_monitor-know)
+ [设置源身份时所需的权限](#id_credentials_temp_control-access_monitor-perms)
+ [在担任角色时指定源身份](#id_credentials_temp_control-access_monitor-specify-sourceid)
+ [使用具有 AssumeRole 的源身份](#id_credentials_temp_control-access_monitor-assume-role)
+ [使用具有 AssumeRoleWithSAML 的源身份](#id_credentials_temp_control-access_monitor-assume-role-saml)
+ [使用具有 AssumeRoleWithWebIdentity 源身份](#id_credentials_temp_control-access_monitor-assume-role-web-id)
+ [使用源身份信息控制访问](#id_credentials_temp_control-access_monitor-control-access)
+ [在 CloudTrail 中查看源身份](#id_credentials_temp_control-access_monitor-ct)
## 设置以使用源身份
设置以使用源身份的方式取决于担任角色时使用的方法。例如，您的 IAM 用户可以直接使用 `AssumeRole` 操作。如果您具有企业身份（也称为人力身份），则他们可能会使用 `AssumeRoleWithSAML` 访问您的 AWS 资源。如果终端用户访问您的移动应用程序或 Web 应用程序，他们可能会使用 `AssumeRoleWithWebIdentity`。以下是一个高级别的工作流概览，可帮助您了解如何进行设置以在现有环境中利用源身份信息。
1. **配置测试用户和角色** — 使用预生产环境，配置测试用户和角色，并配置其策略以允许设置源身份。
如果您对联合身份使用身份提供程序 (IdP)，请将 IdP 配置为在断言或令牌中传递您选择的源身份的用户属性。
1. **担任角色** — 测试所担任角色并将源身份传递给您为测试而设置的用户和角色。
1. **查看 CloudTrail** — 查看 CloudTrail 日志中测试角色的源身份信息。
1. **培训您的用户** — 在预生产环境中进行测试后，请确保用户知道如何传递源身份信息（如有必要）。设置要求用户在生产环境中提供源身份的最后期限。
1. **配置生产策略** — 为生产环境配置策略，然后将其添加到生产用户和角色中。
1. **监控活动** — 使用 CloudTrail 日志监控您的生产角色活动。
## 有关源身份的需知信息
使用源身份时请记住以下事项。
+ 连接到身份提供程序 (IdP) 的所有角色的角色信任策略都必须具有 `sts:SetSourceIdentity` 权限。对于信任策略中没有此权限的角色，`AssumeRole*` 操作将失败。如果您不想更新每个角色的角色信任策略，则可以使用单独的 IdP 实例传递源身份。然后仅将 `sts:SetSourceIdentity` 权限添加到连接至单独 IdP 的角色。
+ 当身份设置源身份时，`sts:SourceIdentity` 密钥将出现在请求中。对于角色会话期间执行的后续操作，`aws:SourceIdentity` 密钥将出现在请求中。AWS 不控制 `sts:SourceIdentity` 或 `aws:SourceIdentity` 密钥中源身份的值。如果选择要求源身份，则必须选择希望用户或 IdP 提供的属性。出于安全考虑，您必须确保可以控制如何来提供这些值。
+ 源身份值的长度必须介于 2 到 64 个字符之间，只能包含字母数字字符、下划线和以下字符：**. , \$1 = @ -**（连字符）。您不能创建以文本 **aws:** 开头的值。此前缀是专为 AWS 内部使用预留的。
+ 当 AWS 服务或服务关联角色代表联合身份或工作人员身份执行操作时，源身份信息不会被 CloudTrail 捕获。
**重要**
您无法切换为 AWS 管理控制台 中在担任角色时需要设置源身份的角色。要担任这样的角色，您可以使用 AWS CLI 或者 AWS API 来调用 `AssumeRole` 操作并指定源身份参数。
## 设置源身份时所需的权限
除了与 API 操作匹配的操作之外，您的策略中还必须具有以下仅限授权执行的操作：
```
sts:SetSourceIdentity
```
+ 要指定源身份，主体（IAM 用户和角色）必须具有对 `sts:SetSourceIdentity` 的权限。作为管理员，您可以在角色信任策略和主体的权限策略中对此进行配置。
+ 当您使用另一个角色担任角色时，该操作称为[角色链](id_roles.md#iam-term-role-chaining)，在担任角色的主体的权限策略和目标角色的角色信任策略中都需要对 `sts:SetSourceIdentity` 的权限。否则，担任角色的操作将失败。
+ 使用源身份时，连接到 IdP 的所有角色的角色信任策略都必须具有 `sts:SetSourceIdentity` 权限。对于连接到 IdP 的任何角色，如果在没有此权限的情况下，`AssumeRole*` 操作将失败。如果您不想更新每个角色的角色信任策略，则可以使用单独的 IdP 实例传递源身份，然后将 `sts:SetSourceIdentity` 权限仅添加到与单独的 IdP 连接的角色。
+ 要跨账户边界设置源身份，您必须在两个位置包含 `sts:SetSourceIdentity` 权限。该权限必须位于原始账户中主体的权限策略和目标账户中角色的角色信任策略中。例如，当某个角色用于在另一个账户中使用[角色链](id_roles.md#iam-term-role-chaining)担任某个角色时，您可能需要执行此操作。
作为账户管理员，假设您希望允许 IAM 用户 `DevUser` 在您的账户中担任在同一账户中的 `Developer_Role`。但是，您希望只有当用户已将源身份设置为其 IAM 用户名时才允许此操作。那么，您可以将以下策略附加到 IAM 用户。
**Example 附加到 DevUser 的基于身份的策略示例**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AssumeRole",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::123456789012:role/Developer_Role"
},
{
"Sid": "SetAwsUserNameAsSourceIdentity",
"Effect": "Allow",
"Action": "sts:SetSourceIdentity",
"Resource": "arn:aws:iam::123456789012:role/Developer_Role",
"Condition": {
"StringLike": {
"sts:SourceIdentity": "${aws:username}"
}
}
}
]
}
```
要强制实施可接受的源身份值，可以配置以下角色信任策略。该策略为 IAM 用户提供 `DevUser` 权限以担任该角色并设置源身份。`sts:SourceIdentity` 条件键定义可接受的源身份值。
**Example 源身份的角色信任策略示例**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowDevUserAssumeRole",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/DevUser"
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity"
],
"Condition": {
"StringEquals": {
"sts:SourceIdentity": "DevUser"
}
}
}
]
}
```
------
借助 IAM 用户 `DevUser` 的凭证，用户将尝试担任使用以下 AWS CLI 请求的 `DeveloperRole`。
**Example 示例 AssumeRole CLI 请求**
```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/Developer_Role \
--role-session-name Dev-project \
--source-identity DevUser \
```
当 AWS 评估请求时，请求上下文将包含 `DevUser` 的 `sts:SourceIdentity`。
## 在担任角色时指定源身份
当您使用 AWS STS `AssumeRole*`API 操作来获取角色的临时安全凭证时，可以指定源身份。您使用的 API 操作因您的使用案例而异。例如，如果您使用 IAM 角色授予 IAM 用户访问 AWS 资源的权限（而其通常并不具有此权限），则可以使用 `AssumeRole` 操作。如果您使用企业联合身份验证来管理工作人员用户，则可以使用 `AssumeRoleWithSAML` 操作。如果您使用 OIDC 联合身份验证来允许终端用户访问您的移动或 Web 应用程序，则可以使用 `AssumeRoleWithWebIdentity` 操作。以下部分介绍如何在每个操作中使用源身份。要了解有关临时凭证常见场景的更多信息，请参阅 [临时凭证的常见情形](id_credentials_temp.md#sts-introduction)。
## 使用具有 AssumeRole 的源身份
`AssumeRole` 操作返回一组可用于访问 AWS 资源的临时凭证。您可以使用 IAM 用户或角色凭证来调用 `AssumeRole`。要在代入角色时传递源身份，请使用 `-–source-identity` AWS CLI 选项或 `SourceIdentity` AWS API 参数。以下示例说明如何使用 AWS CLI 指定源身份。
**Example 示例 AssumeRole CLI 请求**
```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/developer \
--role-session-name Audit \
--source-identity Admin \
```
## 使用具有 AssumeRoleWithSAML 的源身份
主体调用 `AssumeRoleWithSAML` 操作使用基于 SAML 的联合身份进行身份验证。此操作返回一组可用于访问 AWS 资源的临时凭证。有关将基于 SAML 的联合身份用于 AWS 管理控制台访问的更多信息，请参阅[使 SAML 2.0 联合主体能够访问 AWS 管理控制台](id_roles_providers_enable-console-saml.md)。有关 AWS CLI 或 AWS API 访问的详细信息，请参阅[SAML 2.0 联合身份验证](id_roles_providers_saml.md)。有关为 Active Directory 用户设置 SAML 联合身份的教程，请参阅 AWS 安全博客中的[使用 Active Directory AWS 联合身份验证服务 (ADFS)](https://aws.amazon.com/blogs/security/aws-federated-authentication-with-active-directory-federation-services-ad-fs/) 的亚马逊云科技联合身份验证。
作为管理员，您可以使用 AWS STS `AssumeRoleWithSAML` 操作，允许公司目录的成员联合身份到 AWS 中。要执行此操作，您必须完成以下任务：
1. [在企业中配置 SAML 提供程序](id_roles_providers_saml_3rd-party.md)。
1. [在 IAM 中创建 SAML 提供商](id_roles_providers_create_saml.md)
1. [在 AWS 中为 SAML 联合主体配置角色及其权限](id_roles_create_for-idp_saml.md)。
1. [完成配置 SAML IdP 并为 SAML 身份验证响应创建断言](id_roles_providers_create_saml_assertions.md)。
要为源身份设置 SAML 属性，请包含 `Attribute` 元素，并将 `Name` 属性设置为 `https://aws.amazon.com/SAML/Attributes/SourceIdentity`。使用 `AttributeValue` 元素指定源身份的值。例如，假设您要将以下身份属性作为源身份传递。
`SourceIdentity:DiegoRamirez`
要传递这些属性，请在 SAML 断言中包含以下元素。
**Example SAML 断言的示例片段**
```
DiegoRamirez
```
## 使用具有 AssumeRoleWithWebIdentity 源身份
调用 `AssumeRoleWithWebIdentity` 操作的主体使用兼容 OpenID Connect（OIDC）的联合身份验证进行身份验证。此操作返回一组可用于访问 AWS 资源的临时凭证。有关将 OIDC 联合身份验证用于 AWS 管理控制台访问的更多信息，请参阅 [OIDC 联合身份验证](id_roles_providers_oidc.md)。
要从 OpenID Connect (OIDC) 传递源身份，您必须在 JSON Web Token (JWT) 中包含源身份。当您提交 `AssumeRoleWithWebIdentity` 请求时，请在令牌的 `[https://aws.amazon.com/](https://aws.amazon.com/)source_identity` 命名空间中包含源身份。要了解有关 OIDC 令牌和声明的更多信息，请参阅《Amazon Cognito 开发人员指南》**中的[将令牌与用户群体结合使用](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html)。
例如，以下解码的 JWT 是一个令牌，用于通过 `Admin` 源身份调用 `AssumeRoleWithWebIdentity`。
**Example 解码的 JSON Web 令牌示例**
```
{
"sub": "john",
"aud": "ac_oic_client",
"jti": "ZYUCeRMQVtqHypVPWAN3VB",
"iss": "https://xyz.com",
"iat": 1566583294,
"exp": 1566583354,
"auth_time": 1566583292,
"https://aws.amazon.com/source_identity":"Admin"
}
```
## 使用源身份信息控制访问
当初始设置源身份时，[sts:SourceIdentity](reference_policies_iam-condition-keys.md#ck_sourceidentity) 密钥将出现在请求中。设置源身份后，[aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity) 密钥存在于角色会话期间提出的所有后续请求中。作为管理员，您可以编写策略，授予条件授权以根据源身份属性的现状或值执行 AWS 操作。
假设您希望要求开发人员设置源身份，以承担一个关键角色，该角色有权写入生产关键 AWS 资源。再假设您使用 `AssumeRoleWithSAML` 向您的工作人员身份授予了 AWS 访问权限。您只希望高级开发人员 Saanvi 和 Diego 具有该角色的访问权限，因此您可以为角色创建以下信任策略。
**Example 源身份的角色信任策略示例 (SAML)**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SAMLProviderAssumeRoleWithSAML",
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:saml-provider/name-of-identity-provider"
},
"Action": [
"sts:AssumeRoleWithSAML"
],
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
},
{
"Sid": "SetSourceIdentitySrEngs",
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:saml-provider/name-of-identity-provider"
},
"Action": [
"sts:SetSourceIdentity"
],
"Condition": {
"StringLike": {
"sts:SourceIdentity": [
"Saanvi",
"Diego"
]
}
}
}
]
}
```
------
信任策略包含 `sts:SourceIdentity` 的条件，需要将源身份设置为能够使 Saanvi 或 Diego 担任关键角色。
或者，如果您使用 OIDC 提供者进行联合身份验证，并用 `AssumeRoleWithWebIdentity` 对用户进行身份验证，您的角色信任策略可能如下所示。
**Example 源身份的角色信任策略示例（OIDC 提供商）**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/server.example.com"
},
"Action": [
"sts:AssumeRoleWithWebIdentity",
"sts:SetSourceIdentity"
],
"Condition": {
"StringEquals": {
"server.example.com:aud": "oidc-audience-id"
},
"StringLike": {
"sts:SourceIdentity": [
"Saanvi",
"Diego"
]
}
}
}
]
}
```
------
### 角色链和跨账户要求
假设您想允许已经担任 `CriticalRole` 的用户在另一个账户中担任 `CriticalRole_2`。获得以用户担任 `CriticalRole` 的角色会话凭证用于[角色链](id_roles.md#iam-term-role-chaining)到不同账户中的第二个角色，`CriticalRole_2`。该角色正在以跨账户边界的形式担任。因此，`sts:SetSourceIdentity` 权限必须在权限策略中授予 `CriticalRole`，在角色信任策略中授予 `CriticalRole_2`。
**Example CriticalRole 上的权限策略示例**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AssumeRoleAndSetSourceIdentity",
"Effect": "Allow",
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity"
],
"Resource": "arn:aws:iam::222222222222:role/CriticalRole_2"
}
]
}
```
------
为确保跨账户边界设置源身份，以下角色信任策略仅信任 `CriticalRole` 的角色主体来设置源身份。
**Example CriticalRole\$12 上的角色信任策略示例**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111111111:role/CriticalRole"
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity"
],
"Condition": {
"StringLike": {
"aws:SourceIdentity": ["Saanvi","Diego"]
}
}
}
]
}
```
------
用户使用从担任 CriticalRole 获得的角色会话凭证进行以下调用。源身份是在担任 CriticalRole 期间设置的，因此无需再次显式设置。如果用户尝试设置与担任 `CriticalRole` 所设置值不同的源身份，则担任角色请求将被拒绝。
**Example 示例 AssumeRole CLI 请求**
```
aws sts assume-role \
--role-arn arn:aws:iam::222222222222:role/CriticalRole_2 \
--role-session-name Audit \
```
当调用主体担任角色时，请求中的源身份将从第一个担任的角色会话保留。因此，`aws:SourceIdentity` 和 `sts:SourceIdentity` 密钥将会出现在请求上下文中。
## 在 CloudTrail 中查看源身份
您可以使用 CloudTrail 查看为代入角色或联合身份用户而发出的请求。您还可以查看角色或用户请求，以便在 AWS 中执行操作。CloudTrail 日志文件包括有关所代入角色或联合身份用户会话的源身份集的信息。有关更多信息，请参阅 [使用 AWS CloudTrail 记录 IAM 和 AWS STS API 调用](cloudtrail-integration.md)。
例如，假设用户提出 AWS STS `AssumeRole` 请求，并设置了源身份。您可以在 CloudTrail 日志的 `requestParameters` 键中找到 `sourceIdentity` 信息。
**Example AWS CloudTrail 日志中的示例 requestParameters 部分**
```
"eventVersion": "1.05",
"userIdentity": {
"type": "AWSAccount",
"principalId": "AIDAJ45Q7YFFAREXAMPLE",
"accountId": "111122223333"
},
"eventTime": "2020-04-02T18:20:53Z",
"eventSource": "sts.amazonaws.com",
"eventName": "AssumeRole",
"awsRegion": "us-east-1",
"sourceIPAddress": "203.0.113.64",
"userAgent": "aws-cli/1.16.96 Python/3.6.0 Windows/10 botocore/1.12.86",
"requestParameters": {
"roleArn": "arn:aws:iam::123456789012:role/DevRole",
"roleSessionName": "Dev1",
"sourceIdentity": "source-identity-value-set"
}
```
如果用户使用所担任的角色会话执行操作，则源身份信息将出现在 CloudTrail 日志的 `userIdentity` 密钥中。
**Example AWS CloudTrail 日志中的 userIdentity 密钥示例**
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROAJ45Q7YFFAREXAMPLE:Dev1",
"arn": "arn:aws:sts::123456789012:assumed-role/DevRole/Dev1",
"accountId": "123456789012",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROAJ45Q7YFFAREXAMPLE",
"arn": "arn:aws:iam::123456789012:role/DevRole",
"accountId": "123456789012",
"userName": "DevRole"
},
"webIdFederationData": {},
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2021-02-21T23:46:28Z"
},
"sourceIdentity": "source-identity-value-present"
}
}
}
```
要查看 CloudTrail 日志中的示例 AWS STS API 事件，请参阅 [CloudTrail 日志中的 IAM API 事件示例](cloudtrail-integration.md#cloudtrail-integration_examples-iam-api)。有关 CloudTrail 日志文件中所包含信息的更多详细信息，请参阅 *AWS CloudTrail 用户指南*中的 [CloudTrail 事件参考](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/eventreference.html)。
# GetFederationToken 的权限
`GetFederationToken` 操作是由 IAM 用户调用的，并返回该用户的临时凭证。该操作*联合* 用户。分配给 AWS STS 联合用户会话的权限是在以下两个位置之一中定义的：
+ 作为 `GetFederationToken` API 调用参数传递的会话策略。(最常见。)
+ 一项基于资源的策略，在该策略的 `Principal` 元素中对 AWS STS 联合用户会话进行显式命名。（不太常见。）
会话策略是高级策略，在以编程方式创建临时会话时，这些策略将作为参数进行传递。在创建 AWS STS 联合用户会话并传递会话策略时，生成的会话的权限是用户的基于身份的策略与会话策略的交集。您使用会话策略授予的权限不能超过联合的用户的基于身份的策略允许的权限。
在大多数情况下，如果您未通过 `GetFederationToken` API 调用传递策略，则生成的临时安全凭证没有任何权限。不过，基于资源的策略可以为会话提供额外的权限。您可以使用将会话指定为允许的主体的基于资源的策略访问资源。
下图形象地展示了各策略之间如何相互影响，以确定调用 `GetFederationToken` 所返回的临时安全凭证的权限。
![\[IAM 用户下图显示了复选标记，表明会话权限是用户基于身份的策略和会话策略的交集。会话权限也可以是用户基于身份的策略和基于资源的策略的交集。\]](http://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/images/getfederationtoken-permissions.diagram.png)
## 示例：使用 GetFederationToken 分配权限
您可以将 `GetFederationToken` API 操作与不同类型的策略结合使用。以下是一些示例。
### 策略已附加到 IAM 用户
在此示例中，您拥有一个基于浏览器的客户端应用程序，该程序依赖于两个后端 Web 服务。一个后端服务是您自己的身份验证服务器，该服务器使用您自己的身份系统对客户端应用程序进行验证。另一个后端服务是一项 AWS 服务，该服务用于提供此客户端应用程序的部分功能。您的服务器对该客户端应用程序进行身份验证，并创建或检索相应的权限策略。之后，您的服务器调用 `GetFederationToken` API 来获取临时安全凭证，并将这些凭证返回给客户端应用程序。接下来，客户端应用程序就可以借助该临时安全凭证向 AWS 服务直接发出请求。这一架构允许客户端应用程序在不嵌入长期 AWS 凭证的情况下发出 AWS 请求。
您的身份验证服务器使用名为 `token-app` 的 IAM 用户的长期安全凭证调用 `GetFederationToken` API。但是，长期 IAM 用户凭证保留在您的服务器上，从不分发到客户端。下面的示例策略将被附加至 `token-app` IAM 用户，其中定义了您的 AWS STS 联合用户（客户端）需要的一组最广泛的权限。请注意，您的身份验证服务器需要 `sts:GetFederationToken` 权限才能获取 AWS STS 联合用户的临时安全凭证。
**Example 附加到 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 用户授予多个权限。不过，该策略本身不会为 AWS STS 联合用户授予任何权限。如果该 IAM 用户调用 `GetFederationToken`，并且未将策略作为该 API 调用的参数传递，则生成的 AWS STS 联合用户没有任何有效的权限。
### 作为参数传递的会话策略
要确保为 AWS STS 联合用户分配相应的权限，最常用的方法是在 `GetFederationToken` API 调用中传递会话策略。让我们进一步阐述上述示例，并假设使用 IAM 用户 `token-app` 的凭证调用了 `GetFederationToken`。然后，假设将以下会话策略作为该 API 调用的参数进行传递。生成的 AWS STS 联合用户有权列出名为 `productionapp` 的 Amazon S3 存储桶的内容。用户无法对 `productionapp` 存储桶中的项目执行 Amazon S3 `GetObject`、`PutObject`、和 `DeleteObject` 操作。
将为联合身份用户分配这些权限，因为这些权限是 IAM 用户策略与您传递的会话策略的交集。
AWS STS 联合用户无法在 Amazon SNS、Amazon SQS、Amazon DynamoDB，或任何 S3 存储桶（`productionapp` 除外）中执行操作。这些操作会被拒绝，即使这些权限被授给了与 `GetFederationToken` 调用关联的 IAM 用户。
**Example 作为 `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/*"]
}
]
}
```
### 基于资源的策略
某些 AWS 资源支持基于资源的策略，这些策略提供了另一种直接向 AWS STS 联合用户授权的机制。只有一部分 AWS 服务支持基于资源的策略。例如，Amazon S3 具有存储桶，Amazon SNS 有主题，Amazon SQS 具有队列，您可以向这些内容附加策略。有关支持基于资源的策略的所有服务的列表，请参阅[使用 IAM 的 AWS 服务](reference_aws-services-that-work-with-iam.md)并回顾表的“基于资源的策略”列。您可以使用基于资源的策略将权限直接分配给 AWS STS 联合用户。为此，请在基于资源的策略的 `Principal` 元素中指定 AWS STS 联合用户的 Amazon 资源名称（ARN）。以下示例说明了这一点，并使用名为 `productionapp` 的 S3 存储桶进一步阐述上述示例。
以下基于资源的策略附加到存储桶。此存储桶策略允许名为 Carol 的 AWS STS 联合用户访问该存储桶。当之前介绍的示例策略被附加至 `token-app` IAM 用户时，名为 Carol 的 AWS STS 联合用户将具有对名为 `productionapp` 的存储桶执行 `s3:GetObject`、`s3:PutObject` 和 `s3:DeleteObject` 操作的权限。即使未将任何会话策略作为 `GetFederationToken` API 调用的参数传递，Carol 也能够执行此操作。这是因为，在此示例中，以下基于资源的策略已向名为 Carol 的 AWS STS 联合用户明确授予权限。
请记住，只有向 IAM 用户***和*** AWS STS 联合用户都进行显式授权时，AWS STS 联合用户才具有这些权限。另外，也可通过在策略的 `Principal` 元素中对 AWS STS 联合用户进行显式命名的基于资源的策略授予这些权限（在账户内），如下例所示。
**Example 允许访问联合身份用户的示例存储桶策略**
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": {
"AWS": "arn:aws:sts::111122223333:federated-user/Carol"
},
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::productionapp/*"
]
}
}
```
有关如何评估策略的更多信息，请参阅[策略评估逻辑](reference_policies_evaluation-logic.md)。
# GetSessionToken 的权限
调用 `GetSessionToken` API 操作或 `get-session-token` CLI 命令主要发生在用户必须使用 Multi-Factor Authentication (MFA) 进行身份验证时。可以编写一条策略，只允许特定操作，且仅当这些操作是由经过 MFA 身份验证的用户请求时，才予以放行。为成功通过 MFA 身份验证检查，用户必须先调用 `GetSessionToken`，并包含可选的 `SerialNumber` 和 `TokenCode` 参数。如果用户成功通过 MFA 设备的身份验证，则 `GetSessionToken` API 调用返回的凭证将包含 MFA 上下文。此上下文指示用户已使用 MFA 进行了身份验证，并已获得了需要 MFA 身份验证的 API 操作的授权。
## GetSessionToken 所需的权限
用户无需任何权限即可获取会话令牌。`GetSessionToken` 操作旨在使用 MFA 验证用户身份。您不能使用策略来控制身份验证操作。
要授予执行大多数 AWS 操作的权限，您可以将具有相同名称的操作添加到策略。例如，要创建用户，您必须使用 `CreateUser` API 操作、`create-user` CLI 命令或 AWS 管理控制台。要执行这些操作，您必须具有一个策略，该策略允许您访问 `CreateUser` 操作。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:CreateUser",
"Resource": "*"
}
]
}
```
------
虽然您可以在策略中包含 `GetSessionToken` 操作，但不会影响用户执行 `GetSessionToken` 操作的能力。
## 由 GetSessionToken 授予的权限
如果调用 `GetSessionToken` 时使用的是 IAM 用户的凭证，则临时安全凭证将具有与该 IAM 用户相同的权限。同样，如果使用 AWS 账户根用户 凭证调用 `GetSessionToken`，临时安全凭证将拥有根用户权限。
**注意**
我们建议您不要使用根用户凭证来调用 `GetSessionToken`。相反，请遵循我们的[最佳实践](best-practices-use-cases.md)，并创建具有所需权限的 IAM 用户。然后使用这些 IAM 用户执行与 AWS 的日常交互工作。
您在调用 `GetSessionToken` 时获得的临时凭证具有以下功能和限制：
+ 您可以通过将凭证传递到 `https://signin.aws.amazon.com/federation` 上的联合身份验证单一登录终端节点来访问 AWS 管理控制台。有关更多信息，请参阅 [使自定义身份凭证代理程序能够访问 AWS 控制台](id_roles_providers_enable-console-custom-url.md)。
+ 您**无法**使用凭证调用 IAM 或 AWS STS API 操作。您**可以**使用它们来调用其他 AWS 服务的 API 操作。
请参阅 [比较 AWS STS 凭证](id_credentials_sts-comparison.md)，将此 API 操作及其限制和功能与创建临时安全凭证的其他 API 操作比较
有关使用 `GetSessionToken` 进行受 MFA 保护的 API 访问的更多信息，请参阅[使用 MFA 保护 API 访问](id_credentials_mfa_configure-api-require.md)。
# 禁用临时安全凭证的权限
临时安全凭证在过期之前一直有效。这些凭证在指定的时间段内有效，即 900 秒（15 分钟）到最长 129600 秒（36 小时）之间。默认会话持续时间为 43200 秒（12 小时）。您可以撤消这些凭证，但还须更改 IAM 用户或角色的权限，以阻止他人通过泄露的凭证进行恶意账户活动。每次使用临时安全凭证发出 AWS 请求时，系统都会评估分配给该凭证的权限。从凭证中删除所有权限后，使用这些权限的 AWS 请求会失败。
可能需要几分钟时间，策略更新才能生效。对于 IAM 角色会话，可以撤消角色的临时安全凭证，以强制担任该角色的所有用户重新进行身份验证并请求新的凭证。有关更多信息，请参阅[撤销 IAM 角色临时安全凭证](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html)。
您无法更改 AWS 账户根用户的权限。同样，以根用户身份登录时，您无法更改调用 `GetFederationToken` 或 `GetSessionToken` 创建的临时安全凭证的权限。因此，我们建议您不要以根用户身份调用 `GetFederationToken` 或 `GetSessionToken`。
有关如何更改 IAM 用户的权限的过程，请参阅[更改 IAM 用户的权限](id_users_change-permissions.md)。
有关如何更改 IAM 角色的权限的过程，请参阅[更新角色的权限](id_roles_update-role-permissions.md)。
**重要**
您不能编辑 IAM 中根据 IAM Identity Center 权限集创建的角色。您必须在 IAM Identity Center 中撤消用户的活动权限集会话。有关更多信息，请参阅《*IAM Identity Center 用户指南*》中的[撤消由权限集创建的活动 IAM 角色会话](https://docs.aws.amazon.com/singlesignon/latest/userguide/useraccess.html#revoke-user-permissions)。
**Topics**
+ [拒绝访问与角色关联的所有 IAM 角色会话](#deny-access-to-all-sessions)
+ [拒绝访问特定 IAM 角色会话](#deny-access-to-specific-session)
+ [使用条件上下文键拒绝访问临时安全凭证会话](#deny-access-to-specific-session-condition-key)
+ [拒绝访问使用基于资源的策略的指定主体](#deny-access-with-resource-based)
## 拒绝访问与角色关联的所有 IAM 角色会话
此过程拒绝针对与角色关联的**所有** IAM 角色会话的权限。如果担心他人通过以下方式进行可疑访问，可使用此方法：
+ 使用跨账户存取权限的其他账户主体
+ 有权访问账户中 AWS 资源的外部用户身份
+ 已在移动或 Web 应用程序中使用 OIDC 提供者进行身份验证的用户
要更改或删除通过调用 `AssumeRole`、`AssumeRoleWithSAML`、`AssumeRoleWithWebIdentity`、`GetFederationToken` 或 `GetSessionToken` 而获取的临时安全凭证分配的权限，可编辑或删除为角色定义权限的基于身份的策略。
**重要**
如果存在允许主体访问的基于资源的策略，您还必须为该资源添加显式拒绝。有关详细信息，请参阅 [拒绝访问使用基于资源的策略的指定主体](#deny-access-with-resource-based)。
**拒绝访问与角色关联的**所有** IAM 角色会话**
1. 登录到 AWS 管理控制台 并打开 IAM 控制台。
1. 在导航窗格中，选择**角色**。
1. 选择要编辑的角色的名称。您可以使用搜索框来筛选列表。
1. 选择**权限**选项卡。
1. 选择要编辑的相关策略。在编辑客户管理型策略之前，请查看**附加的实体**选项卡，以免中断用户对可能附加了相同策略的其他身份的访问权限。
1. 选择 **JSON** 选项卡并更新策略以拒绝所有资源和操作。
**注意**
这些权限与 AWS 托管式策略 [AWSDenyAll](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html) 中的权限相同。您可以将此 AWS 托管式策略附加到您想要拒绝其所有访问权限的任何 IAM 用户或角色。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAll",
"Effect": "Deny",
"Action": [
"*"
],
"Resource": "*"
}
]
}
```
------
1. 在**审核**页面上，检查策略**摘要**，然后选择**保存更改**进行保存。
更新策略时，所做的更改会影响与该角色关联的所有临时安全凭证的权限，包括在更改该角色的权限策略之前颁发的凭证。
更新策略后，您可以[撤消角色的临时安全凭证](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html)，以立即撤消对该角色的已颁发凭证的所有权限。
## 拒绝访问特定 IAM 角色会话
当您使用“拒绝所有”策略更新 IAM 角色或完全删除该角色时，所有有权访问该角色的用户的访问权限都会中断。您可以在不影响与角色关联的所有其他会话的权限的情况下拒绝访问。
可以使用[条件上下文键](#deny-access-to-specific-session-condition-key)或[基于资源的策略](#deny-access-with-resource-based)拒绝执行 `Principal` 的权限。
**提示**
您可以使用 AWS CloudTrail 日志查找联合用户的 ARN。有关更多信息，请参阅 [How to Easily Identify Your Federated Users by Using AWS CloudTrail](https://aws.amazon.com/blogs/security/how-to-easily-identify-your-federated-users-by-using-aws-cloudtrail/)。
## 使用条件上下文键拒绝访问临时安全凭证会话
如果您想要拒绝访问特定临时安全凭证会话，而不影响创建该凭证的 IAM 用户或角色的权限，可以在基于身份的策略中使用条件上下文键。对于 IAM 角色，更新策略后，您可以[撤消角色的临时安全凭证](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html)会话，以立即撤消所有已颁发的凭证。
有关条件上下文键的更多信息，请参阅 [AWS 全局条件上下文密钥](reference_policies_condition-keys.md)。
### aws:PrincipalArn
您可以在基于身份的策略中使用条件上下文键 [aws:PrincipalArn](reference_policies_condition-keys.md#condition-keys-principalarn)，根据 Amazon 资源名称（ARN）来拒绝访问特定主体。为此，您可以在策略的 Condition 元素中指定与临时安全凭证关联的 IAM 用户、角色或 AWS STS 联合用户会话。
**根据 ARN 拒绝访问特定主体**
1. 在 IAM 控制台的导航窗格中，选择**用户**或**角色**。
1. 选择要编辑的 IAM 用户或角色的名称。您可以使用搜索框来筛选列表。
1. 选择**权限**选项卡。
1. 选择要编辑的相关策略。在编辑客户管理型策略之前，请查看**附加的实体**选项卡，以免中断用户对可能附加了相同策略的其他身份的访问权限。
1. 选择 **JSON** 选项卡并为主体 ARN 添加拒绝语句，如以下示例所示：
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"ArnEquals": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:role/ROLENAME",
"arn:aws:iam::222222222222:user/USERNAME",
"arn:aws:iam::222222222222:federated-user/USERNAME"
]
}
}
}
]
}
```
------
1. 在**审核**页面上，检查策略**摘要**，然后选择**保存更改**进行保存。
### aws:SourceIdentity
您可以在基于身份的策略中使用条件上下文键 [aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity) 来拒绝访问与 IAM 角色会话关联的特定源身份。只要在主体使用任何 AWS STS `assume-role`\$1 CLI 命令或 AWS STS `AssumeRole`\$1 API 操作担任角色时通过设置 `SourceIdentity` 请求参数发出角色会话，此方法就适用。您可以通过在策略的 `Condition` 元素中指定与临时安全凭证关联的源身份来执行此操作。
与上下文键 [sts:RoleSessionName](reference_policies_iam-condition-keys.md#ck_rolesessionname) 不同，在设置源身份后，无法更改该值。`aws:SourceIdentity` 键存在于角色执行的所有操作的请求上下文中。当您使用会话凭证担任另一个角色时，源身份将保留到后续角色会话中。从一个角色代入另一个角色的过程称为[角色链](id_roles.md#iam-term-role-chaining)。
以下策略显示了如何使用条件上下文键 `aws:SourceIdentity` 拒绝访问临时安全凭证会话的示例。如果您指定与角色会话关联的源身份，则将拒绝具有已命名源身份的角色会话，而不会影响已创建凭证的角色的权限。对于此示例，发出角色会话时主体设置的源身份为 `nikki_wolf@example.com`。源身份为 `nikki_wolf@example.com` 的角色会话发出的任何请求都将被拒绝，因为源身份包含在策略条件中，并且策略效果设置为 `Deny`。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringLike": {
"aws:SourceIdentity": [
"nikki_wolf@example.com",
""
]
}
}
}
]
}
```
------
### aws:userid
您可以在基于身份的策略中使用条件上下文键 [aws:userid](reference_policies_condition-keys.md#condition-keys-userid) 来拒绝访问与 IAM 用户或角色关联的所有或特定临时安全凭证会话。为此，您可以在策略的 `Condition` 元素中指定与临时安全凭证关联的 IAM 用户、角色或 AWS STS 联合用户会话的唯一标识符（ID）。
以下策略显示了如何使用条件上下文键 `aws:userid` 拒绝访问临时安全凭证会话的示例。
+ `AIDAXUSER1` 表示 IAM 用户的唯一 ID。如果将 IAM 用户的唯一 ID 指定为上下文键 `aws:userid` 的值，这将拒绝访问该 IAM 用户。这包括通过调用 `GetSessionToken` API 创建的任何临时安全凭证会话。
+ `AROAXROLE1:*` 表示与 IAM 角色关联的所有会话的唯一 ID。如果在 caller-specified-role-session-name 部分中将 IAM 角色的唯一 ID 和通配符 (\$1) 指定为上下文键 `aws:userid` 的值，这将拒绝与该角色关联的所有会话。
+ `AROAXROLE2:` 表示担任角色的会话的唯一 ID。在担任角色的唯一 ID 的 caller-specified-role-session-name 部分中，如果使用 StringLike 条件运算符，则可指定角色会话名称或通配符。如果您指定角色会话名称，则将拒绝已命名的角色会话，而不会影响已创建凭证的角色的权限。如果您为角色会话名称指定通配符，则将拒绝与该角色关联的所有会话。
**注意**
调用者指定的角色会话名称，是担任角色会话唯一标识符的一部分，在角色链接期间可能会发生变化。当一个角色担任另一个角色时，就会发生角色链接。角色会话名称是在主体使用 AWS STS `AssumeRole` API 操作担任角色时使用 `RoleSessionName` 请求参数设置的。
+ `account-id:` 表示 AWS STS 联合用户会话的唯一 ID。IAM 用户通过调用 `GetFederationToken` API 创建了此会话。如果为 AWS STS 联合用户会话指定唯一 ID，这将拒绝已命名的联合会话，而不会影响已创建凭证的 IAM 用户的权限。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringLike": {
"aws:userId": [
"AIDAXUSER1",
"AROAXROLE1:*",
"AROAXROLE2:",
"123456789012:"
]
}
}
}
]
}
```
------
有关主体键值的具体示例，请参阅 [主体键值](reference_policies_variables.md#principaltable)。有关 IAM 唯一标识符以及如何获取此标识符的信息，请参阅[唯一标识符](reference_identifiers.md#identifiers-unique-ids)。
## 拒绝访问使用基于资源的策略的指定主体
要限制访问使用基于资源的策略的特定主体，可以在 `Condition` 元素中使用条件上下文键 [aws:PrincipalArn](reference_policies_condition-keys.md#condition-keys-principalarn) 或 [aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity)。基于资源的策略是附加到资源的权限策略，可用于指定有权访问资源的用户，以及此类用户可以对资源执行的操作。
使用 `aws:PrincipalARN` 条件键时，您可以在策略的 Condition 元素中指定与临时安全凭证关联的 IAM 用户、角色或 AWS STS 联合用户会话的 ARN。以下示例策略演示如何在基于资源的策略中使用 `aws:PrincipalARN` 上下文键：
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": "*",
"Effect": "Deny",
"Action": "s3:*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"ArnEquals": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:role/ROLENAME",
"arn:aws:iam::222222222222:user/USERNAME",
"arn:aws:sts::222222222222:federated-user/USERNAME"
]
}
}
}
}
```
------
使用 `aws:SourceIdentity` 上下文键时，需要在策略的 `Condition` 元素中指定与角色的临时安全凭证关联的源身份值。只要在主体使用任何 AWS STS `assume-role`\$1 CLI 命令或 AWS STS `AssumeRole`\$1 API 操作担任角色时通过设置 `SourceIdentity` 请求参数发出角色会话，此方法就适用。以下示例演示如何在基于资源的策略中使用 `aws:SourceIdentity` 上下文键：
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": "*",
"Effect": "Deny",
"Action": "s3:*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"StringLike": {
"aws:SourceIdentity": [
"nikki_wolf@example.com",
""
]
}
}
}
}
```
------
如果您仅更新主体的基于身份的策略，则用户仍可以执行基于资源的策略中允许的操作，但基于身份的策略中明确拒绝的操作除外。
**拒绝访问基于资源的策略中的指定主体**
1. 请参阅 [使用 IAM 的 AWS 服务](reference_aws-services-that-work-with-iam.md) 以查看该服务是否支持基于资源的策略。
1. 登录到 AWS 管理控制台，然后打开服务控制台。每项服务在控制台中用于附加策略的位置都各不相同。
1. 编辑基于资源的策略。添加拒绝策略语句来指定凭证的识别信息：
1. 在 `Principal` 元素中，输入通配符 (\$1)。主体将在 `Condition` 元素中受到限制。
1. 在 `Effect` 元素中，输入“Deny”。
1. 在 `Action` 中，输入服务命名空间和要拒绝的操作名称。要拒绝所有操作，请使用通配符（\$1）。例如：`"s3:*"`。
1. 在 `Resource` 元素中，输入目标资源的 ARN。例如：`"arn:aws:s3:::amzn-s3-demo-bucket"`。
1. 在 `Condition` 元素中，指定 `aws:PrincipalARN` 或 `aws:SourceIdentity` 上下文键。
如果使用 `aws:PrincipalARN` 上下文键，输入要拒绝其访问的主体的 ARN
如果使用 `aws:SourceIdentity` 上下文键，输入在角色会话中设置的源身份值以拒绝其访问。
1. 保存您的工作。
# 授予创建临时安全凭证的权限
默认情况下，IAM 用户无权为 AWS STS 联合用户会话和角色创建临时安全凭证。您必须使用策略来向用户提供这些权限。虽然您可以直接向用户授予权限，但我们强烈建议您向组授予权限。这样可以使权限管理轻松得多。如果某个用户不再需要执行与权限关联的任务时，您只需从组中将其删除。如果其他用户需要执行这些任务，请将这些用户添加到组以授予权限。
要向 IAM 组授予为 AWS STS 联合用户会话或角色创建临时安全凭证的权限，应附加一个策略，该策略授予以下一项或两项权限：
+ 对于要访问 IAM 角色的 OIDC 和 SAML 联合主体，请授予对 AWS STS `AssumeRole` 的访问权限。
+ 对于无需角色的 AWS STS 联合用户，请授予对 AWS STS `GetFederationToken` 的访问权限。
有关 `AssumeRole` 和 `GetFederationToken` API 操作之间的差异的更多信息，请参阅[请求临时安全凭证](id_credentials_temp_request.md)。
IAM 用户也可以调用 [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) 以创建临时安全凭证。用户无需任何权限即可调用 `GetSessionToken`。此操作旨在使用 MFA 验证用户身份。您不能使用策略来控制身份验证。这意味着，您不能阻止 IAM 用户调用 `GetSessionToken` 来创建临时凭证。
**Example 为授予担任角色的权限的示例策略**
以下示例策略为 AWS 账户 `123123123123` 中的 `UpdateApp` 角色授予调用 `AssumeRole` 的权限。在使用 `AssumeRole` 时，代表联合身份用户创建安全凭证的用户（或应用程序）无法委派尚未在角色权限策略中指定的任何权限。
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::123123123123:role/UpdateAPP"
}]
}
```
**Example 示例策略，该策略授予为联合身份用户创建临时安全凭证的权限**
以下示例策略授予访问 `GetFederationToken` 的权限。
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": "*"
}]
}
```
**重要**
使用 `GetFederationToken` 向 IAM 用户授予为 AWS STS 联合用户创建临时安全凭证的权限时应注意，这将允许这些用户委派自己的权限。有关跨 IAM 用户和 AWS 账户 委派权限的更多信息，请参阅 [委派访问权限的策略示例](id_roles_create_policy-examples.md)。有关控制临时安全凭证权限的详细信息，请参阅[临时安全凭证的权限](id_credentials_temp_control-access.md)。
**Example 向用户授予为联合身份用户创建临时安全凭证的有限权限的示例策略**
在让 IAM 用户调用 `GetFederationToken` 时，最佳实践是限制 IAM 用户可以委派的权限。举例来说，以下策略展示如何让 IAM 用户仅为其名称以 *Manager* 开头的 AWS STS 联合用户创建临时安全凭证。
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": ["arn:aws:sts::123456789012:federated-user/Manager*"]
}]
}
```
# 授予使用身份增强控制台会话的权限
身份增强控制台会话允许在 AWS IAM Identity Center 用户登录时将用户和会话 ID 包含在他们的 AWS 控制台会话中。例如，Amazon Q Developer Pro 使用身份增强控制台会话来个性化服务体验。有关身份增强控制台会话的更多信息，请参阅《*AWS IAM Identity Center 用户指南*》中的 [Enabling identity-enhanced console sessions](https://docs.aws.amazon.com/singlesignon/latest/userguide/identity-enhanced-sessions.html)。有关 Amazon Q 开发者版设置的信息，请参阅《*Amazon Q 开发者版用户指南*》中的[设置 Amazon Q 开发者版](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/setting-up.html)。
要使身份增强控制台会话可供用户使用，您必须使用基于身份的策略向 IAM 主体授予对代表其控制台会话的资源的 `sts:SetContext` 权限。
**重要**
默认情况下，用户无权为其身份增强控制台会话设置上下文。要允许这样做，您必须在基于身份的策略中向 IAM 主体授予 `sts:SetContext` 权限，如以下策略示例所示。
以下示例基于身份的策略向 IAM 主体授予 `sts:SetContext` 权限，允许主体为自己的 AWS 控制台会话设置身份增强控制台会话上下文。策略资源 `arn:aws:sts::account-id:self` 代表调用方的 AWS 会话。如果在多个账户中部署了相同的权限策略，例如使用 IAM Identity Center 权限集部署此策略，则可以将 `account-id` ARN 分段替换为通配符 `*`。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:SetContext",
"Resource": "arn:aws:sts::111122223333:self"
}
]
}
```
------
# 管理 AWS 区域中的 AWS STS
区域端点是 AWS Web 服务在特定区域内入口点的 URL。AWS 建议使用区域 AWS Security Token Service (AWS STS) 端点而不是全局端点，以减少延迟、建立冗余以及提高会话令牌的有效性。尽管全球（旧版）AWS STS 端点 `https://sts.amazonaws.com` 高度可用，但它托管在单个 AWS 区域美国东部（弗吉尼亚州北部），并且与其他端点一样，它不提供到其他区域中端点的自动故障转移。
+ **减少延迟** - 通过向在地理位置离您较近的服务和应用程序的端点发出 AWS STS 调用，可以缩短访问 AWS STS 服务时的响应时间并减少延迟。
+ **建立冗余** – 您可以将工作负载内故障的影响，限制在影响控制范围可预测的少数组件范围内。使用区域 AWS STS 端点可以确保组件的范围与会话令牌的范围保持一致。有关此可靠性支柱的更多信息，请参阅在《AWS Well-Architected Framework》中的 [使用故障隔离来保护工作负载](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html)**。
+ **提高会话令牌有效性** – 来自区域 AWS STS 端点的会话令牌在所有 AWS 区域 中都有效。来自全球 STS 端点的会话令牌仅在默认启用的 AWS 区域 中有效。如果打算为您的账户启用新的区域，您可以使用来自区域 AWS STS 端点的会话令牌。如果选择使用全球端点，您必须更改全球端点的 AWS STS 会话令牌的区域兼容性。这样做可以确保令牌在所有 AWS 区域 中都有效。
有关 AWS STS 区域及其端点的列表，请参阅 [AWS STS 区域和端点](id_credentials_temp_region-endpoints.md)。
**注意**
AWS 已对[默认启用](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)的区域中的 AWS Security Token Service (AWS STS) 全局端点 (`https://sts.amazonaws.com`) 进行了更改，以增强其恢复能力和性能。发往全局端点的 AWS STS 请求将自动在与您的工作负载相同的 AWS 区域中处理。这些更改不会部署到选择加入的区域。我们建议您使用适当的 AWS STS 区域端点。有关更多信息，请参阅 [AWS STS 全局端点更改](id_credentials_temp_region-endpoints.md#reference_sts_global_endpoint_changes)。
**Topics**
+ [在 AWS 区域 中激活和停用 AWS STS](#sts-regions-activate-deactivate)
+ [编写代码以使用 AWS STS 区域](#id_credentials_temp_enable-regions_writing_code)
+ [管理全球端点会话令牌](#sts-regions-manage-tokens)
## 在 AWS 区域 中激活和停用 AWS STS
在为区域激活 AWS STS 端点时，AWS STS 可能会向您的账户中发出 AWS STS 请求的用户和角色颁发临时凭证。然后，可以在默认启用或手动启用的任何区域中使用这些凭证。对于默认启用的区域，您必须在生成临时凭证的账户中激活该区域 AWS STS 端点。在发出请求时，用户是登录到同一账户还是不同账户并不重要。当使用手动启用的区域为另一个 AWS 账户 中的角色请求临时凭证时，目标账户（包含该角色的账户）必须为该区域启用 AWS STS 操作。此举可确保临时安全凭证能够正确生成。
例如，假设账户 A 中的用户要向 [AWS STS 区域端点](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_region-endpoints.html) `https://sts.ap-southeast-3.amazonaws.com` 发送 `sts:AssumeRole` API 请求。该请求旨在为账户 B 中名为 `Developer` 的角色获取临时凭证。由于该请求旨在为账户 B 中的实体创建凭证，因此，账户 B 必须激活 `ap-southeast-3` 区域。账户 A（或任何其他账户）中的用户可以调用 `ap-southeast-3` AWS STS 端点，以便为账户 B 请求凭证，而无论是否在其账户中激活了该区域。欲了解更多信息，请参阅[在您的账户中启用或禁用 AWS 区域](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)。
**注意**
活动区域适用于该账户中使用临时凭证的每个用户。要控制哪些 IAM 用户或角色可以访问区域，请在权限策略中使用 `aws:RequestedRegion` 条件键。
**在默认启用的区域中激活或停用 AWS STS（控制台）**
1. 以根用户或有权执行 IAM 管理任务的用户身份登录。
1. 打开 [IAM 控制台](https://console.aws.amazon.com/iam/home?#home)，然后在导航窗格中选择 [https://console.aws.amazon.com/iam/home?#account_settings](https://console.aws.amazon.com/iam/home?#account_settings)（账户设置）。
1. 在 **Security Token Service (STS)** 部分的 **Endpoints**（端点）中，找到要配置的区域，然后在 **STS status**（STS 状态）列中选择 **Active**（活动）或 **Inactive**（非活动）。
1. 在打开的对话框中，选择 **Activate**（激活）或 **Deactivate**（停用）。
对于必须启用的区域，当您启用相关区域时，我们会自动激活 AWS STS。启用区域后，AWS STS 对于该区域将始终处于活动状态，您无法将其停用。要了解如何启用默认禁用的区域，请参阅《AWS 账户管理 参考指南》**中的[指定您的账户可以使用的 AWS 区域](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)。
## 编写代码以使用 AWS STS 区域
在激活区域后，您可以将 AWS STS API 调用定向到该区域。以下 Java 代码段说明了如何配置 `AWSSecurityTokenService` 对象，以向欧洲地区（米兰）（eu-south-1）区域发出请求。
```
EndpointConfiguration regionEndpointConfig = new EndpointConfiguration("https://sts.eu-south-1.amazonaws.com", "eu-south-1");
AWSSecurityTokenService stsRegionalClient = AWSSecurityTokenServiceClientBuilder.standard()
.withCredentials(credentials)
.withEndpointConfiguration(regionEndpointConfig)
.build();
```
AWS STS 建议您调用区域端点。要了解如何手动启用的区域，请参阅《AWS 账户管理 Reference Guide》**中的 [Specify which AWS 区域 your account can use](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)。
在该示例中，第一行将名为 `regionEndpointConfig` 的 `EndpointConfiguration` 对象实例化，并将端点的 URL 和 AWS 区域 作为参数传递。
要了解如何使用 AWS SDK 的环境变量设置 AWS STS 区域端点，请参阅 *AWS SDK 和工具参考指南*中的 [AWS STS 区域化端点](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html)。
有关所有其他的语言和编程环境组合，请参阅[相关开发工具包的文档](https://aws.amazon.com/tools/)。
## 管理全球端点会话令牌
默认情况下，为所有 AWS 服务 中的操作启用了大多数 AWS 区域。将自动激活这些区域以用于 AWS STS。必须手动启用某些区域，例如，亚太区域（香港）。要了解启用和禁用 AWS 区域 的更多信息，请参阅《AWS 账户管理 Reference Guide》**中的 [Specify which AWS 区域 your account can use](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)。在启用这些 AWS 区域时，将自动激活这些区域以用于 AWS STS。您无法为禁用的区域激活 AWS STS 端点。在所有 AWS 区域 都有效的会话令牌包含的字符数比在默认启用的区域中有效的令牌多。更改该设置可能会影响临时存储令牌的现有系统。
您可以使用 AWS 管理控制台、AWS CLI 或 AWS API 更改该设置。
**更改全球端点的会话令牌的区域兼容性（控制台）**
1. 以根用户或有权执行 IAM 管理任务的用户身份登录。要更改会话令牌的兼容性，您必须具有允许 `iam:SetSecurityTokenServicePreferences` 操作的策略。
1. 打开 [IAM 控制台](https://console.aws.amazon.com/iam/home?#home)。在导航窗格中，选择 **Account settings**（账户设置）。
1. 在 **Security Token Service (STS)** 部分的 **Session Tokens from the STS endpoints**（来自 STS 端点的会话令牌）。**全球端点** 表示 `Valid only in AWS 区域 enabled by default`。选择 **Change (更改)**。
1. 在**更改区域兼容性**对话框中，选择**全部 AWS 区域**。然后选择 **Save changes （保存更改)**。
**注意**
在所有 AWS 区域 都有效的会话令牌包含的字符数比在默认启用的区域中有效的令牌多。更改该设置可能会影响临时存储令牌的现有系统。
**更改全球端点的会话令牌的区域兼容性 (AWS CLI)**
设置会话令牌版本。版本 1 令牌仅在默认启用的 AWS 区域 中有效。这些令牌不适用于手动启用的区域，例如，亚太地区（香港）。版本 2 令牌在所有区域中都有效。不过，版本 2 令牌包含更多字符，可能会影响临时存储令牌的系统。
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/set-security-token-service-preferences.html](https://docs.aws.amazon.com/cli/latest/reference/iam/set-security-token-service-preferences.html)
**更改全球端点的会话令牌的区域兼容性 (AWS API)**
设置会话令牌版本。版本 1 令牌仅在默认启用的 AWS 区域 中有效。这些令牌不适用于手动启用的区域，例如，亚太地区（香港）。版本 2 令牌在所有区域中都有效。不过，版本 2 令牌包含更多字符，可能会影响临时存储令牌的系统。
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_SetSecurityTokenServicePreferences.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_SetSecurityTokenServicePreferences.html)
# AWS STS 区域和端点
**注意**
AWS 已对[默认启用](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)的区域中的 AWS Security Token Service (AWS STS) 全局端点 (`https://sts.amazonaws.com`) 进行了更改，以增强其恢复能力和性能。发往全局端点的 AWS STS 请求将自动在与您的工作负载相同的 AWS 区域中处理。这些更改不会部署到选择加入的区域。我们建议您使用适当的 AWS STS 区域端点。有关更多信息，请参阅 [AWS STS 全局端点更改](#reference_sts_global_endpoint_changes)。
下表列出了区域及其终端节点。其中指示哪些是默认激活的，哪些是可激活或停用的。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/id_credentials_temp_region-endpoints.html)
您必须[启用区域](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html)才能使用它。这会自动激活 AWS STS。您无法在这些区域中手动激活或停用 AWS STS。
²要在中国使用 AWS，您需要中国 AWS 的特定账户和凭证。
## AWS STS 全局端点更改
AWS 已对[默认启用](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)的区域中的 AWS Security Token Service (AWS STS) 全局端点 (`https://sts.amazonaws.com`) 进行了更改，以增强其恢复能力和性能。以前，发往 AWS STS 全局端点的所有请求都由 AWS 区域美国东部（弗吉尼亚州北部）处理。现在，在[默认启用](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)的区域中，发往 AWS STS 全局端点的请求将自动在请求发起的同一区域（而非美国东部（弗吉尼亚州北部）区域）中处理。这些更改不会部署到选择加入的区域。
通过此更改，AWS STS 将根据使用的原始区域和 DNS 解析程序处理您的请求。如果 AWS STS 全局端点的 DNS 请求由默认启用的区域中的 Amazon DNS 服务器处理，则发往 AWS 全局端点的请求将在与您部署的 AWS STS 工作负载相同的区域中处理。如果您的请求源自选择加入区域，或者使用 Amazon DNS 服务器以外的 DNS 解析程序解析您的请求，则发往 AWS STS 全局端点的请求将继续在美国东部（弗吉尼亚州北部）区域处理。有关 Amazon DNS 的更多信息，请参阅《*Amazon Virtual Private Cloud 用户指南*》中的 [Amazon DNS 服务器](https://docs.aws.amazon.com/vpc/latest/userguide/AmazonDNS-concepts.html#AmazonDNS)。
下表显示了如何根据您的 DNS 提供商路由发往 AWS STS 全局端点的请求。
| DNS 解析程序 | 发往 AWS STS 全局端点的请求是否路由到本地 AWS 区域？ |
| --- | --- |
| 默认启用的区域中的 Amazon VPC 中的 Amazon DNS 解析程序 | 是 |
| 选择加入区域中的 Amazon VPC 中的 Amazon DNS 解析程序 | 不，请求将路由到美国东部（弗吉尼亚州北部）区域 |
| 由您的 ISP、公共 DNS 提供商或任何其他 DNS 提供商提供的 DNS 解析程序 | 不，请求将路由到美国东部（弗吉尼亚州北部）区域 |
为了确保最大限度地减少对现有流程的干扰，AWS 已实施以下措施：
+ 对 AWS STS 全局端点发出的请求的 AWS CloudTrail 日志将发送到美国东部（弗吉尼亚州北部）区域。由 AWS STS 区域端点处理的请求的 CloudTrail 日志将继续记录到 CloudTrail 中的相应区域。
+ AWS STS 全局端点和区域端点执行的操作的 CloudTrail 日志将包含附加字段 `endpointType` 和 `awsServingRegion`，以指示哪个端点和区域处理了请求。有关 CloudTrail 日志示例，请参阅[CloudTrail 日志文件中使用全局端点的示例 AWS STS 事件](cloudtrail-integration.md#stscloudtrailexample-assumerole-sts-global-endpoint)。
+ 无论哪个区域处理请求，发往 AWS STS 全局端点的请求的 `aws:RequestedRegion` 条件键的值都将为 `us-east-1`。
+ AWS STS 全局端点处理的请求不会与区域 AWS STS 端点共享每秒请求数配额。
如果您在选择加入区域中拥有工作负载并且仍在使用 AWS STS 全局端点，我们建议您迁移到 AWS STS 区域端点以提高恢复能力和性能。有关配置区域 AWS STS 端点的更多信息，请参阅《*AWS SDK 和工具参考指南*》中的 [AWS STS Regional endpoints](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html)。
## AWS CloudTrail 和区域端点
对区域性和全球性端点的调用将在 AWS CloudTrail 的 `tlsDetails` 字段中记录。对区域性端点（例如 `us-east-2.amazonaws.com`）的调用将在 CloudTrail 中记录到相应的区域。对全球终端节点 (如 `sts.amazonaws.com`) 的调用会记录为对全球服务的调用。全球性 AWS STS 端点的事件将记录到 us-east-1 区域。
**注意**
只能对支持此字段的服务查看 `tlsDetails`。请参阅《*AWS CloudTrail 用户指南*》中的[在 CloudTrail 中支持 TLS 详细信息的服务](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-supported-tls-details.html)
有关更多信息，请参阅 [使用 AWS CloudTrail 记录 IAM 和 AWS STS API 调用](cloudtrail-integration.md)。
# 使自定义身份凭证代理程序能够访问 AWS 控制台
您可以通过编写和运行代码来创建 URL 以使登录到您组织网络的用户能够安全访问 AWS 管理控制台。该 URL 包含您从 AWS 获得的登录令牌，而令牌则用于对访问 AWS 的用户进行身份验证。由于联合身份验证的原因，显示的控制台会话可能包含不同的 `AccessKeyId`。要通过相关 CloudTrail 事件跟踪联合身份验证登录的访问密钥使用情况，请参阅 [使用 AWS CloudTrail 记录 IAM 和 AWS STS API 调用](cloudtrail-integration.md) 和 [AWS 管理控制台 登录事件](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-aws-console-sign-in-events.html)。
**注意**
如果您的组织使用与 SAML 兼容的身份提供程序 (IdP)，则无需编写代码即可设置对控制台的访问权限。这适用于 Microsoft 的 Active Directory 联合身份验证服务或开源 Shibboleth 等提供商。有关更多信息，请参阅 [使 SAML 2.0 联合主体能够访问 AWS 管理控制台](id_roles_providers_enable-console-saml.md)。
要使您组织的用户能够访问 AWS 管理控制台，可以创建执行以下步骤的自定义*身份代理*：
1. 确认您的本地身份系统已对用户进行身份验证。
1. 调用 AWS Security Token Service (AWS STS) [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)（推荐）或 [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) API 操作为该用户获取临时安全凭证。要了解在担任角色时使用的各种方法，请参阅[担任角色的方法](id_roles_manage-assume.md)。要了解在获取安全凭证时如何传递可选的会话标签，请参阅[在 AWS STS 中传递会话标签](id_session-tags.md)。
+ 如果使用某个 `AssumeRole*` API 操作获取角色的临时安全凭证，您可以在调用中包含 `DurationSeconds` 参数。该参数指定 900 秒 (15 分钟) 到角色的最大会话持续时间设置之间的角色会话持续时间。在 `AssumeRole*` 操作中使用 `DurationSeconds` 时，必须以具有长期凭证的 IAM 用户身份调用该操作。否则，在步骤 3 中对联合终端节点的调用将失败。要了解如何查看或更改角色的最大值，请参阅[更新角色的最长会话持续时间](id_roles_update-role-settings.md#id_roles_update-session-duration)。
+ 如果使用 `GetFederationToken` API 操作获取凭证，您可以在调用中包含 `DurationSeconds` 参数。该参数指定您的角色会话的持续时间。该值的范围是 900 秒 (15 分钟) 到 129,600 秒 (36 小时)。您只能使用 IAM 用户的长期 AWS 安全凭证进行该 API 调用。您还可以使用 AWS 账户根用户凭证进行这些调用，但我们不建议使用这种方法。如果您以根用户身份进行该调用，则会话默认持续 1 小时。或者，您可以指定 900 秒 (15 分钟) 到 3,600 秒 (1 小时) 之间的会话。
1. 调用 AWS 联合终端节点并提供临时安全凭证来请求登录令牌。
1. 构造包含该令牌的控制台 URL：
+ 如果在 URL 中使用某个 `AssumeRole*` API 操作，您可以包含 `SessionDuration` HTTP 参数。该参数指定控制台会话持续时间，范围是 900 秒 (15 分钟) 到 43200 秒 (12 小时)。
+ 如果在 URL 中使用 `GetFederationToken` API 操作，您可以包含 `DurationSeconds` 参数。该参数指定联合控制台会话的持续时间。该值的范围是 900 秒 (15 分钟) 到 129,600 秒 (36 小时)。
**注意**
您的 `SessionDuration` 不能大于或等于您所代入的角色的最大会话持续时间设置。例如，您将要代入的角色的最大会话持续时间设置为 5 小时。您的 `SessionDuration` 参数可以是 16524 秒或 4 小时 59 秒。
使用 `GetFederationToken` 获取临时凭证时，请不要使用 `SessionDuration` HTTP 参数。该操作将失败。
使用一个角色的凭证担任其他角色称为 [*role chaining*](id_roles.md#iam-term-role-chaining)（角色链）。在使用角色链时，新凭证的最大持续时间限制为 1 小时。当您使用角色[向 EC2 实例上运行的应用程序授予权限](id_roles_use_switch-role-ec2.md)时，则这些应用程序不受制于此限制。
通过角色串联获取临时凭证时，请不要使用 `SessionDuration` HTTP 参数。该操作将失败。
1. 将 URL 分配给用户或代表用户调用 URL。
联合终端节点提供的 URL 在创建后的 15 分钟内有效。这不同于与 URL 关联的临时安全凭证会话的持续时间 (以秒为单位)。这些凭证在创建时指定的持续时间内有效，从创建时算起。
**重要**
如果您在关联的临时安全凭证中启用了权限，则该 URL 授予通过 AWS 管理控制台访问您的 AWS 资源的权限。因此，您应该视 URL 为机密。我们建议您通过安全的重定向返回 URL，例如，在 SSL 连接上使用 302 HTTP 响应状态代码。有关 302 HTTP 响应状态代码的详细信息，请参阅 [RFC 2616，第 10.3.3 节](https://datatracker.ietf.org/doc/html/rfc2616#section-10.3.3)。
要完成这些任务，您可以使用适用于 AWS Identity and Access Management 的 [HTTPS 查询 API (IAM)](https://docs.aws.amazon.com/IAM/latest/APIReference/) 和 [AWS Security Token Service (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/)。或者，您可以将编程语言（例如 Java、Ruby 或 C\$1）与相应的 [AWS 开发工具包](https://aws.amazon.com/tools/)结合使用。以下主题分别说明了这些方式。
**Topics**
+ [使用 IAM 查询 API 操作的示例代码](#STSConsoleLink_manual)
+ [使用 Python 的示例代码](#STSConsoleLink_programPython)
+ [使用 Java 的示例代码](#STSConsoleLink_programJava)
+ [演示如何构造 URL 的示例 (Ruby)](#STSConsoleLink_programRuby)
## 使用 IAM 查询 API 操作的示例代码
您可以构造一个 URL，此 URL 向角色和联合身主体授予对 AWS 管理控制台的直接访问权限。此任务使用 IAM 和 AWS STS HTTPS 查询 API。有关提出查询请求的详细信息，请参阅[提出查询请求](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAM_UsingQueryAPI.html)。
**注意**
以下过程包括了文本字符串的例子。为增加可读性，一些较长的例子中添加了换行符。如果您要创建并使用这些字符串，必须省略所有换行符。
**向角色和联合主体授予从 AWS 管理控制台访问您的资源的权限**
1. 在您的身份验证系统里验证该用户
1. 为用户获取临时安全凭证。临时凭证由访问密钥 ID、秘密访问密钥和会话令牌组成。有关创建临时凭证的详细信息，请参阅[IAM 临时安全凭证](id_credentials_temp.md)。
要获取临时凭证，您可以调用 AWS STS [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API（推荐）或 [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) API。有关这些 API 操作之间区别的更多信息，请参阅 AWS 安全博客中的[了解安全地委派您的 AWS 账户访问权限的 API 选项](https://aws.amazon.com/blogs/security/understanding-the-api-options-for-securely-delegating-access-to-your-aws-account)。
**重要**
在使用 [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) API 创建临时安全凭证时，您必须指定这些凭证为担任角色的用户授予的权限。对于任何以 `AssumeRole*` 开头的 API 操作，可使用 IAM 角色来分配权限。对于其他 API 操作，机制因 API 而异。有关更多详细信息，请参阅[临时安全凭证的权限](id_credentials_temp_control-access.md)。此外，如果使用 `AssumeRole*` API 操作，您还必须以具有长期凭证的 IAM 用户身份调用这些操作。否则，在步骤 3 中对联合终端节点的调用将失败。
1. 在获取临时安全凭证后，将其构建到 JSON 会话字符串以将其交换为登录令牌。下例展示如何将凭证编码。请将占位符文本替换为上一步骤中接收的凭证中的相应值。
```
{"sessionId":"*** temporary access key ID ***",
"sessionKey":"*** temporary secret access key ***",
"sessionToken":"*** session token ***"}
```
1. [URL 编码](https://en.wikipedia.org/wiki/Percent-encoding)上一步骤中的会话字符串。由于您编码的信息是敏感信息，因此建议您避免对此编码使用 Web 服务。请改用开发工具包中在本地安装的函数或功能来安全地编码这些信息。您可以使用 Python 的 `urllib.quote_plus` 函数、Java 的 `URLEncoder.encode` 函数或 Ruby 的 `CGI.escape` 函数。请参阅本主题后面的示例。
1.
**注意**
AWS 在此处支持 POST 请求。
将您的请求发送到 AWS 联合身份验证端点：
`https://region-code.signin.aws.amazon.com/federation`
有关可能的 *region-code* 值的列表，请参阅 [AWS 登录端点](https://docs.aws.amazon.com/general/latest/gr/signin-service.html)中的 **Region**（区域）列。您可以选择使用默认 AWS 登录联合身份验证端点：
`https://signin.aws.amazon.com/federation`
该请求必须包含 `Action` 和 `Session` 参数；(可选) 如果使用了 [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API 操作，还必须包含 `SessionDuration` HTTP 参数，如以下示例中所示。
```
Action = getSigninToken
SessionDuration = time in seconds
Session = *** the URL encoded JSON string created in steps 3 & 4 ***
```
**注意**
此步骤中的以下说明仅适用于 GET 请求。
`SessionDuration` HTTP 参数指定控制台会话的持续时间。它不同于使用 `DurationSeconds` 参数指定的临时凭证的持续时间。可以将 `SessionDuration` 的最大值指定为 43200（12 小时）。如果缺少 `SessionDuration` 参数，则会话默认为在步骤 2 中从 AWS STS 检索的凭证的持续时间（默认为 1 小时）。有关如何使用 `DurationSeconds` 参数指定持续时间的详细信息，请参阅 [`AssumeRole` API 的文档](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)。创建超过 1 小时的控制台会话的功能是联合终端节点的 `getSigninToken` 操作所固有的。
**注意**
您的 `SessionDuration` 不能大于或等于您所代入的角色的最大会话持续时间设置。例如，您将要代入的角色的最大会话持续时间设置为 5 小时。您的 `SessionDuration` 参数可以是 16524 秒或 4 小时 59 秒。
使用 `GetFederationToken` 获取临时凭证时，请不要使用 `SessionDuration` HTTP 参数。该操作将失败。
使用一个角色的凭证担任其他角色称为 [*role chaining*](id_roles.md#iam-term-role-chaining)（角色链）。在使用角色链时，新凭证的最大持续时间限制为 1 小时。当您使用角色[向 EC2 实例上运行的应用程序授予权限](id_roles_use_switch-role-ec2.md)时，则这些应用程序不受制于此限制。
通过角色串联获取临时凭证时，请不要使用 `SessionDuration` HTTP 参数。该操作将失败。
在启用具有更长持续时间的控制台会话时，您增加了凭证外泄的风险。为了帮助缓解这种风险，您可以通过在 IAM 控制台页面的 **Role Summary**（角色摘要）上选择 **Revoke Sessions**（撤消会话）立即禁用所有角色的有效控制台会话。有关更多信息，请参阅 [撤销 IAM 角色临时安全凭证](id_roles_use_revoke-sessions.md)。
以下为请求具体形式的示例。在此处换行以便阅读，但您应将其作为一行字符串提交。
```
https://signin.aws.amazon.com/federation
?Action=getSigninToken
&SessionDuration=1800
&Session=%7B%22sessionId%22%3A+%22ASIAJUMHIZPTOKTBMK5A%22%2C+%22sessionKey%22
%3A+%22LSD7LWI%2FL%2FN%2BgYpan5QFz0XUpc8s7HYjRsgcsrsm%22%2C+%22sessionToken%2
2%3A+%22FQoDYXdzEBQaDLbj3VWv2u50NN%2F3yyLSASwYtWhPnGPMNmzZFfZsL0Qd3vtYHw5A5dW
AjOsrkdPkghomIe3mJip5%2F0djDBbo7SmO%2FENDEiCdpsQKodTpleKA8xQq0CwFg6a69xdEBQT8
FipATnLbKoyS4b%2FebhnsTUjZZQWp0wXXqFF7gSm%2FMe2tXe0jzsdP0O12obez9lijPSdF1k2b5
PfGhiuyAR9aD5%2BubM0pY86fKex1qsytjvyTbZ9nXe6DvxVDcnCOhOGETJ7XFkSFdH0v%2FYR25C
UAhJ3nXIkIbG7Ucv9cOEpCf%2Fg23ijRgILIBQ%3D%3D%22%7D
```
来自联合终端节点的响应是一个具有 `SigninToken` 值的 JSON 文档。类似下例。
```
{"SigninToken":"*** the SigninToken string ***"}
```
1.
**注意**
AWS 在此处支持 POST 请求。
最后，创建您用户可用于访问 AWS 管理控制台的 URL。此 URL 与您在[Step 5](#STSConsoleLink_manual_step5) 中使用的联合 URL 终端节点相同，外加以下参数：
```
?Action = login
&Issuer = *** the form-urlencoded URL for your internal sign-in page ***
&Destination = *** the form-urlencoded URL to the desired AWS console page ***
&SigninToken = *** the value of SigninToken received in the previous step ***
```
**注意**
此步骤中的以下说明仅适用于 GET API。
下列 URL 为 URL 最终形式的示例。URL 的有效期为 15 分钟，自创建时算起。在 URL 中嵌入的临时安全凭证和控制台会话的有效期为在最初请求它们时在 `SessionDuration` HTTP 参数中指定的持续时间。
```
https://signin.aws.amazon.com/federation
?Action=login
&Issuer=https%3A%2F%2Fexample.com
&Destination=https%3A%2F%2Fconsole.aws.amazon.com%2F
&SigninToken=VCQgs5qZZt3Q6fn8Tr5EXAMPLEmLnwB7JjUc-SHwnUUWabcRdnWsi4DBn-dvC
CZ85wrD0nmldUcZEXAMPLE-vXYH4Q__mleuF_W2BE5HYexbe9y4Of-kje53SsjNNecATfjIzpW1
WibbnH6YcYRiBoffZBGExbEXAMPLE5aiKX4THWjQKC6gg6alHu6JFrnOJoK3dtP6I9a6hi6yPgm
iOkPZMmNGmhsvVxetKzr8mx3pxhHbMEXAMPLETv1pij0rok3IyCR2YVcIjqwfWv32HU2Xlj471u
3fU6uOfUComeKiqTGX974xzJOZbdmX_t_lLrhEXAMPLEDDIisSnyHGw2xaZZqudm4mo2uTDk9Pv
9l5K0ZCqIgEXAMPLEcA6tgLPykEWGUyH6BdSC6166n4M4JkXIQgac7_7821YqixsNxZ6rsrpzwf
nQoS14O7R0eJCCJ684EXAMPLEZRdBNnuLbUYpz2Iw3vIN0tQgOujwnwydPscM9F7foaEK3jwMkg
Apeb1-6L_OB12MZhuFxx55555EXAMPLEhyETEd4ZulKPdXHkgl6T9ZkIlHz2Uy1RUTUhhUxNtSQ
nWc5xkbBoEcXqpoSIeK7yhje9Vzhd61AEXAMPLElbWeouACEMG6-Vd3dAgFYd6i5FYoyFrZLWvm
0LSG7RyYKeYN5VIzUk3YWQpyjP0RiT5KUrsUi-NEXAMPLExMOMdoODBEgKQsk-iu2ozh6r8bxwC
RNhujg
```
## 使用 Python 的示例代码
以下示例说明了如何使用 Python 以编程方式构造授予用户 AWS 管理控制台直接访问权限的 URL。以下是两个示例：
+ 通过 GET 请求联合到 AWS
+ 通过 POST 请求联合到 AWS
这两个示例都使用 [适用于 Python (Boto3) 的 AWS SDK](https://aws.amazon.com/tools/) 和 [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API 获取临时安全凭证。
如果您的 `AssumeRoleSession` 凭证来自角色串联，请不要将 `SessionDuration` 包括在内。如果包括 `SessionDuration`，则操作将失败。
### 使用 GET 请求
```
import urllib, json, sys
import requests # 'pip install requests'
import boto3 # AWS SDK for Python (Boto3) 'pip install boto3'
# Step 1: Authenticate user in your own identity system.
# Step 2: Using the access keys for an IAM user in your AWS 账户,
# call "AssumeRole" to get temporary access keys for the role or federated principal
# Note: Calls to AWS STS AssumeRole must be signed using the access key ID
# and secret access key of an IAM user or using existing temporary credentials.
# The credentials can be in Amazon EC2 instance metadata, in environment variables,
# or in a configuration file, and will be discovered automatically by the
# client('sts') function. For more information, see the Python SDK docs:
# http://boto3.readthedocs.io/en/latest/reference/services/sts.html
# http://boto3.readthedocs.io/en/latest/reference/services/sts.html#STS.Client.assume_role
sts_connection = boto3.client('sts')
assumed_role_object = sts_connection.assume_role(
RoleArn="arn:aws:iam::account-id:role/ROLE-NAME",
RoleSessionName="AssumeRoleSession",
)
# Step 3: Format resulting temporary credentials into JSON
url_credentials = {}
url_credentials['sessionId'] = assumed_role_object.get('Credentials').get('AccessKeyId')
url_credentials['sessionKey'] = assumed_role_object.get('Credentials').get('SecretAccessKey')
url_credentials['sessionToken'] = assumed_role_object.get('Credentials').get('SessionToken')
json_string_with_temp_credentials = json.dumps(url_credentials)
# Step 4. Make request to AWS federation endpoint to get sign-in token. Construct the parameter string with
# the sign-in action request, a 12-hour session duration, and the JSON document with temporary credentials
# as parameters.
request_parameters = "?Action=getSigninToken"
request_parameters += "&SessionDuration=43200"
if sys.version_info[0] < 3:
def quote_plus_function(s):
return urllib.quote_plus(s)
else:
def quote_plus_function(s):
return urllib.parse.quote_plus(s)
request_parameters += "&Session=" + quote_plus_function(json_string_with_temp_credentials)
request_url = "https://signin.aws.amazon.com/federation" + request_parameters
r = requests.get(request_url)
# Returns a JSON document with a single element named SigninToken.
signin_token = json.loads(r.text)
# Step 5: Create URL where users can use the sign-in token to sign in to
# the console. This URL must be used within 15 minutes after the
# sign-in token was issued.
request_parameters = "?Action=login"
request_parameters += "&Issuer=Example.org"
request_parameters += "&Destination=" + quote_plus_function("https://console.aws.amazon.com/")
request_parameters += "&SigninToken=" + signin_token["SigninToken"]
request_url = "https://signin.aws.amazon.com/federation" + request_parameters
# Send final URL to stdout
print (request_url)
```
### 使用 POST 请求
```
import urllib, json, sys
import requests # 'pip install requests'
import boto3 # AWS SDK for Python (Boto3) 'pip install boto3'
import os
from selenium import webdriver # 'pip install selenium', 'brew install chromedriver'
# Step 1: Authenticate user in your own identity system.
# Step 2: Using the access keys for an IAM user in your AAWS 账户,
# call "AssumeRole" to get temporary access keys for the role or federated principal
# Note: Calls to AWS STS AssumeRole must be signed using the access key ID
# and secret access key of an IAM user or using existing temporary credentials.
# The credentials can be in Amazon EC2 instance metadata, in environment variables,
# or in a configuration file, and will be discovered automatically by the
# client('sts') function. For more information, see the Python SDK docs:
# http://boto3.readthedocs.io/en/latest/reference/services/sts.html
# http://boto3.readthedocs.io/en/latest/reference/services/sts.html#STS.Client.assume_role
if sys.version_info[0] < 3:
def quote_plus_function(s):
return urllib.quote_plus(s)
else:
def quote_plus_function(s):
return urllib.parse.quote_plus(s)
sts_connection = boto3.client('sts')
assumed_role_object = sts_connection.assume_role(
RoleArn="arn:aws:iam::account-id:role/ROLE-NAME",
RoleSessionName="AssumeRoleDemoSession",
)
# Step 3: Format resulting temporary credentials into JSON
url_credentials = {}
url_credentials['sessionId'] = assumed_role_object.get('Credentials').get('AccessKeyId')
url_credentials['sessionKey'] = assumed_role_object.get('Credentials').get('SecretAccessKey')
url_credentials['sessionToken'] = assumed_role_object.get('Credentials').get('SessionToken')
json_string_with_temp_credentials = json.dumps(url_credentials)
# Step 4. Make request to AWS federation endpoint to get sign-in token. Construct the parameter string with
# the sign-in action request, a 12-hour session duration, and the JSON document with temporary credentials
# as parameters.
request_parameters = {}
request_parameters['Action'] = 'getSigninToken'
request_parameters['SessionDuration'] = '43200'
request_parameters['Session'] = json_string_with_temp_credentials
request_url = "https://signin.aws.amazon.com/federation"
r = requests.post( request_url, data=request_parameters)
# Returns a JSON document with a single element named SigninToken.
signin_token = json.loads(r.text)
# Step 5: Create a POST request where users can use the sign-in token to sign in to
# the console. The POST request must be made within 15 minutes after the
# sign-in token was issued.
request_parameters = {}
request_parameters['Action'] = 'login'
request_parameters['Issuer']='Example.org'
request_parameters['Destination'] = 'https://console.aws.amazon.com/'
request_parameters['SigninToken'] =signin_token['SigninToken']
jsrequest = '''
var form = document.createElement('form');
form.method = 'POST';
form.action = '{request_url}';
request_parameters = {request_parameters}
for (var param in request_parameters) {{
if (request_parameters.hasOwnProperty(param)) {{
const hiddenField = document.createElement('input');
hiddenField.type = 'hidden';
hiddenField.name = param;
hiddenField.value = request_parameters[param];
form.appendChild(hiddenField);
}}
}}
document.body.appendChild(form);
form.submit();
'''.format(request_url=request_url, request_parameters=request_parameters)
driver = webdriver.Chrome()
driver.execute_script(jsrequest)
input("Press Enter to close the browser window...")
```
## 使用 Java 的示例代码
以下示例说明了如何使用 Java 以编程方式构造授予用户 AWS 管理控制台直接访问权限的 URL。下列代码段使用 [AWS SDK for Java](https://aws.amazon.com/documentation/sdkforjava/)。
```
import java.net.URLEncoder;
import java.net.URL;
import java.net.URLConnection;
import java.io.BufferedReader;
import java.io.InputStreamReader;
// Available at http://www.json.org/java/index.html
import org.json.JSONObject;
import com.amazonaws.auth.AWSCredentials;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.services.securitytoken.AWSSecurityTokenServiceClient;
import com.amazonaws.services.securitytoken.model.Credentials;
import com.amazonaws.services.securitytoken.model.GetFederationTokenRequest;
import com.amazonaws.services.securitytoken.model.GetFederationTokenResult;
/* Calls to AWS STS API operations must be signed using the access key ID
and secret access key of an IAM user or using existing temporary
credentials. The credentials should not be embedded in code. For
this example, the code looks for the credentials in a
standard configuration file.
*/
AWSCredentials credentials =
new PropertiesCredentials(
AwsConsoleApp.class.getResourceAsStream("AwsCredentials.properties"));
AWSSecurityTokenServiceClient stsClient =
new AWSSecurityTokenServiceClient(credentials);
GetFederationTokenRequest getFederationTokenRequest =
new GetFederationTokenRequest();
getFederationTokenRequest.setDurationSeconds(1800);
getFederationTokenRequest.setName("UserName");
// A sample policy for accessing Amazon Simple Notification Service (Amazon SNS) in the console.
String policy = "{\"Version\":\"2012-10-17\", \"Statement\":[{\"Action\":\"sns:*\"," +
"\"Effect\":\"Allow\",\"Resource\":\"*\"}]}";
getFederationTokenRequest.setPolicy(policy);
GetFederationTokenResult federationTokenResult =
stsClient.getFederationToken(getFederationTokenRequest);
Credentials federatedCredentials = federationTokenResult.getCredentials();
// The issuer parameter specifies your internal sign-in
// page, for example https://mysignin.internal.mycompany.com/.
// The console parameter specifies the URL to the destination console of the
// AWS Management Console. This example goes to Amazon SNS.
// The signin parameter is the URL to send the request to.
String issuerURL = "https://mysignin.internal.mycompany.com/";
String consoleURL = "https://console.aws.amazon.com/sns";
String signInURL = "https://signin.aws.amazon.com/federation";
// Create the sign-in token using temporary credentials,
// including the access key ID, secret access key, and session token.
String sessionJson = String.format(
"{\"%1$s\":\"%2$s\",\"%3$s\":\"%4$s\",\"%5$s\":\"%6$s\"}",
"sessionId", federatedCredentials.getAccessKeyId(),
"sessionKey", federatedCredentials.getSecretAccessKey(),
"sessionToken", federatedCredentials.getSessionToken());
// Construct the sign-in request with the request sign-in token action, a
// 12-hour console session duration, and the JSON document with temporary
// credentials as parameters.
String getSigninTokenURL = signInURL +
"?Action=getSigninToken" +
"&DurationSeconds=43200" +
"&SessionType=json&Session=" +
URLEncoder.encode(sessionJson,"UTF-8");
URL url = new URL(getSigninTokenURL);
// Send the request to the AWS federation endpoint to get the sign-in token
URLConnection conn = url.openConnection ();
BufferedReader bufferReader = new BufferedReader(new
InputStreamReader(conn.getInputStream()));
String returnContent = bufferReader.readLine();
String signinToken = new JSONObject(returnContent).getString("SigninToken");
String signinTokenParameter = "&SigninToken=" + URLEncoder.encode(signinToken,"UTF-8");
// The issuer parameter is optional, but recommended. Use it to direct users
// to your sign-in page when their session expires.
String issuerParameter = "&Issuer=" + URLEncoder.encode(issuerURL, "UTF-8");
// Finally, present the completed URL for the AWS console session to the user
String destinationParameter = "&Destination=" + URLEncoder.encode(consoleURL,"UTF-8");
String loginURL = signInURL + "?Action=login" +
signinTokenParameter + issuerParameter + destinationParameter;
```
## 演示如何构造 URL 的示例 (Ruby)
以下示例说明了如何使用 Ruby 以编程方式构造授予用户 AWS 管理控制台直接访问权限的 URL。下列代码段使用 [AWS SDK for Ruby](https://aws.amazon.com/documentation/sdkforruby/)。
```
require 'rubygems'
require 'json'
require 'open-uri'
require 'cgi'
require 'aws-sdk'
# Create a new STS instance
#
# Note: Calls to AWS STS API operations must be signed using an access key ID
# and secret access key. The credentials can be in EC2 instance metadata
# or in environment variables and will be automatically discovered by
# the default credentials provider in the AWS Ruby SDK.
sts = Aws::STS::Client.new()
# The following call creates a temporary session that returns
# temporary security credentials and a session token.
# The policy grants permissions to work
# in the AWS SNS console.
session = sts.get_federation_token({
duration_seconds: 1800,
name: "UserName",
policy: "{\"Version\":\"2012-10-17\", \"Statement\":{\"Effect\":\"Allow\",\"Action\":\"sns:*\",\"Resource\":\"*\"}}",
})
# The issuer value is the URL where users are directed (such as
# to your internal sign-in page) when their session expires.
#
# The console value specifies the URL to the destination console.
# This example goes to the Amazon SNS console.
#
# The sign-in value is the URL of the AWS STS federation endpoint.
issuer_url = "https://mysignin.internal.mycompany.com/"
console_url = "https://console.aws.amazon.com/sns"
signin_url = "https://signin.aws.amazon.com/federation"
# Create a block of JSON that contains the temporary credentials
# (including the access key ID, secret access key, and session token).
session_json = {
:sessionId => session.credentials[:access_key_id],
:sessionKey => session.credentials[:secret_access_key],
:sessionToken => session.credentials[:session_token]
}.to_json
# Call the federation endpoint, passing the parameters
# created earlier and the session information as a JSON block.
# The request returns a sign-in token that's valid for 15 minutes.
# Signing in to the console with the token creates a session
# that is valid for 12 hours.
get_signin_token_url = signin_url +
"?Action=getSigninToken" +
"&SessionType=json&Session=" +
CGI.escape(session_json)
returned_content = URI.parse(get_signin_token_url).read
# Extract the sign-in token from the information returned
# by the federation endpoint.
signin_token = JSON.parse(returned_content)['SigninToken']
signin_token_param = "&SigninToken=" + CGI.escape(signin_token)
# Create the URL to give to the user, which includes the
# sign-in token and the URL of the console to open.
# The "issuer" parameter is optional but recommended.
issuer_param = "&Issuer=" + CGI.escape(issuer_url)
destination_param = "&Destination=" + CGI.escape(console_url)
login_url = signin_url + "?Action=login" + signin_token_param +
issuer_param + destination_param
```