# 临时安全凭证的权限
您可以使用 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"
}
]
}
```
------