# 向用户授予切换角色的权限
当管理员[创建用于跨账户存取的角色](id_roles_create_for-user.md)时，您在拥有角色和资源的账户（信任账户）和包含用户的账户（可信账户）之间建立了信任。为此，信任账户的管理员指定可信账号为角色的信任策略中的 `Principal`。这*可能*会允许可信账户中的任何用户担任该角色。要完成配置，可信账户的管理员必须为该账户中的特定组或用户提供切换到该角色的权限。
**要授予切换到角色的权限**
1. 作为可信账户的管理员，请为用户创建新策略，或编辑现有策略以添加所需元素。有关更多信息，请参阅 [创建或编辑策略](#roles-usingrole-createpolicy)。
1. 然后，选择您希望如何分享角色信息：
+ 角色链接：****向用户发送链接，以使用户进入已填写所有详细信息的 **Switch Role**（切换角色）页面。
+ 账户 ID 或别名：****为每位用户提供角色名称以及账户 ID 号或账户别名。用户随后转到 **Switch Role** 页面，然后手动添加详细信息。
有关更多信息，请参阅 [向用户提供信息](#roles-usingrole-giveuser)。
请注意，仅当您以 IAM 用户、SAML 联合角色或 web 身份联合角色登录时才能切换角色。如果您以 AWS 账户根用户身份登录，则无法切换角色。
**重要**
您无法将 AWS 管理控制台中的角色切换到需要 [ExternalId](id_roles_common-scenarios_third-party.md#id_roles_third-party_external-id) 值的角色。您只能通过调用支持 `ExternalId` 参数的 [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API 来切换到此类角色。
**备注**
本主题讨论了用户**的策略，因为您最终会向用户授予完成任务的权限。但是，我们建议您不要向单个用户直接授予权限。当用户担任某个角色时，系统会为他们分配与该角色相关的权限。
当您在 AWS 管理控制台中切换角色时，控制台总是使用您的原始凭证对切换操作进行授权。无论您作为 IAM 用户、SAML 联合角色还是 Web 联合身份角色登录，上述情形均适用。例如，如果您切换到角色 A，则 IAM 使用您的原始用户或联合角色凭证确定是否允许您担任角色 A。如果您在*使用 RoleA 时*尝试切换到 RoleB，则会使用您的**原始**用户或联合角色凭证对您的尝试进行授权。RoleA 凭证不用于此操作。
**Topics**
+ [创建或编辑策略](#roles-usingrole-createpolicy)
+ [向用户提供信息](#roles-usingrole-giveuser)
## 创建或编辑策略
向用户授予担任角色权限的策略必须包括一个语句，该语句对以下项具有 `Allow` 影响：
+ `sts:AssumeRole` 操作
+ `Resource` 元素中该角色的 Amazon Resource Name (ARN)
获得了该策略（通过组成员资格或直接附加）的用户可以切换所列资源上的角色。
**注意**
如果将 `Resource` 设置为 `*`，则用户可在信任用户账户的任何账户中担任何角色。（换言之，角色的信任策略将用户的账户指定为 `Principal`）。作为最佳实践，我们建议您遵循[最低权限原则](http://en.wikipedia.org/wiki/Principle_of_least_privilege)并仅为用户所需的角色指定完整的 ARN。
以下示例所显示的策略允许用户仅在一个账户中担任角色。此外，该策略使用通配符 (\$1) 来指定用户仅在角色名称以字母 `Test` 开头时才能切换到该角色。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/Test*"
}
}
```
------
**注意**
角色向用户授予的权限不会添加到用户已获得的权限。当用户切换到某个角色时，用户可临时放弃其原始权限以换取由该角色授予的权限。用户退出该角色时，将自动恢复原始用户权限。例如，假如用户的权限允许使用 Amazon EC2 实例，但是角色的权限策略未授予这些权限。在这种情况下，使用角色时，用户无法在控制台中使用 Amazon EC2 实例。此外，通过 `AssumeRole` 获取的临时凭证无法以编程方式使用 Amazon EC2 实例。
## 向用户提供信息
创建角色并向用户授予切换为该角色的权限后，您必须为用户提供以下信息：
+ 角色的名称。
+ 包含该角色的 ID 或账户别名
通过向用户发送使用账户 ID 和角色名称预配置的链接，可为用户简化访问。完成**创建角色**向导后，您可以选择**查看角色**横幅，或在任何已启用跨账户角色的**角色摘要**页面上查看角色链接。
您还可使用以下格式手动构建链接。请用您的账户 ID 或别名及角色名称替换以下示例中的两个参数：
`https://signin.aws.amazon.com/switchrole?account=your_account_ID_or_alias&roleName=optional_path/role_name`
我们建议您将用户定向到 [从用户切换到 IAM 角色（控制台）](id_roles_use_switch-role-console.md) 以指导他们完成该过程。要排除您在担任角色时可能遇到的常见问题，请参阅 [我无法代入角色](troubleshoot_roles.md#troubleshoot_roles_cant-assume-role)。
**注意事项**
+ 如果您以编程方式创建角色，则可使用路径以及名称创建角色。如果执行此操作，则必须向用户提供完整的路径和角色名称，以便他们可以在 AWS 管理控制台 的 **Switch Role**（切换角色）页面输入该角色。例如：`division_abc/subdivision_efg/role_XYZ`。
+ 如果您以编程方式创建角色，则您可以添加最长 512 个字符的 `Path` 以及 `RoleName`。角色名称最多可以有 64 个字符。但是，要通过 AWS 管理控制台 中的**切换角色**功能使用角色，则组合的 `Path` 和 `RoleName` 不能超过 64 个字符。
+ 为了安全起见，您可以[查看 AWS CloudTrail 日志](cloudtrail-integration.md#cloudtrail-integration_signin-tempcreds)以了解已在 AWS 中执行操作的人员。您可以在角色信任策略中使用 `sts:SourceIdentity` 条件键，以要求用户在代入角色时指定身份。例如，您可以要求 IAM 用户指定自己的用户名作为其源身份。这可以帮助您确定哪个用户在 AWS 中执行了具体的操作。有关更多信息，请参阅 [`sts:SourceIdentity`](reference_policies_iam-condition-keys.md#ck_sourceidentity)。您可以使用 [`sts:RoleSessionName`](reference_policies_iam-condition-keys.md#ck_rolesessionname)，以要求用户在代入角色时指定会话名称。这可以帮助您在不同主体使用角色时区分角色会话。