# IAM 角色的常见场景
<a name="id_roles_common-scenarios"></a>

与大多数 AWS 功能一样，您通常可按照两种方式来使用角色：在 IAM 控制台中以交互方式使用角色，或通过 AWS CLI、Tools for Windows PowerShell 或 API 以编程方式使用角色。
+ 您账户中的使用 IAM 控制台的 IAM 用户可*切换为*某个角色，以临时使用该控制台中的角色的权限。该用户放弃自己的原始权限，采用分配给该角色的权限。用户退出角色时，将恢复其原始权限。
+ 应用程序或 AWS 提供的服务（如 Amazon EC2）可以通过请求供角色用来向 AWS 进行编程请求的临时安全凭证来*代入*角色。您可以按这种方式使用角色，以便不必为需要访问资源的每个实体共享或维护长期安全凭证 (例如，通过创建 IAM 用户)。

**注意**  
本指南以可互换方式使用了*切换到角色*和*代入角色*这两个短语。

最简单的角色使用方式是向 IAM 用户授予权限，以便切换为您在自己或其他 AWS 账户 中创建的角色。他们可以使用 IAM 控制台轻松地切换角色以使用通常您不希望他们拥有的权限，然后退出角色以交出这些权限。这样有助于防止对敏感资源进行*意外* 访问或修改。

若要对角色进行更复杂的使用 (如向应用程序和服务或联合身份外部用户授予访问权限)，可以调用 `AssumeRole` API。该 API 调用返回应用程序可在后续 API 调用中使用的一组临时凭证。使用临时凭证执行的操作只拥有相关联的角色所授予的权限。应用程序不必像控制台中的用户那样“退出”角色；而是应用程序直接停止使用临时凭证并使用原始凭证继续调用。

联合身份用户使用身份提供程序 (IdP) 提供的凭证登录。AWS 随后向可信 IdP 提供临时证书以传递给用户，以便包含在后续 AWS 资源请求中。这些证书提供向分配的角色授予的权限。

本部分提供了以下方案的概述：
+ [为您拥有的一个 AWS 账户 中的 IAM 用户提供对您拥有的其他账户中的资源的访问权限](id_roles_common-scenarios_aws-accounts.md)
+ [提供对非 AWS 工作负载的访问权限](id_roles_common-scenarios_non-aws.md)
+ [为第三方拥有的 AWS 账户 中的 IAM 用户提供访问权限](id_roles_common-scenarios_third-party.md)
+ [为 AWS 提供的服务提供对 AWS 资源的访问权限](id_roles_common-scenarios_services.md)
+ [为经过外部身份验证的用户（联合身份验证）提供访问权限](id_roles_common-scenarios_federated-users.md)

# 在您拥有的其他 AWS 账户 中 IAM 用户的访问权限
<a name="id_roles_common-scenarios_aws-accounts"></a>

您可以向 IAM 用户授予权限，以便切换至您 AWS 账户 中的角色，或切换至您拥有的其他 AWS 账户 中定义的角色。

**注意**  
如果要授予对您未拥有或无法控制的账户的访问权限，请参阅本主题后面的[访问第三方拥有的 AWS 账户](id_roles_common-scenarios_third-party.md)。

假设您拥有一个企业关键型 Amazon EC2 实例。您可以创建具有这些权限的角色，而不是直接向用户授予终止实例的权限。然后，允许管理员在需要终止实例时切换为该角色。这样，可向实例添加以下几层保护：
+ 您必须向用户显式授予担任该角色的权限。
+ 用户必须使用 AWS 管理控制台主动切换为该角色，或使用 AWS CLI 或 AWS API 担任角色。
+ 您可以向该角色添加多重身份验证 (MFA) 保护，以便只有登录 MFA 设备的用户才能担任该角色。要了解如何配置角色以使担任角色的用户必须先使用多重身份验证 (MFA) 进行身份验证，请参阅[使用 MFA 保护 API 访问](id_credentials_mfa_configure-api-require.md)。

我们建议使用该方法以实施*最小权限原则*。这意味着，仅限特定任务需要时，才能使用提升的权限。借助角色，您可以帮助防止对敏感环境进行意外更改，如果您将它们与[审核](cloudtrail-integration.md)合并以帮助确保仅在需要时才使用角色，这尤其适用。

在您出于此目的创建角色时，可在该角色的信任策略的 `Principal` 元素中按 ID 指定其用户需要访问权限的账户。随后可以向这些其他账户中的特定用户授予切换到角色的权限。要了解您信任区域之外的账户（受信任的企业或账户）中的主体是否有权承担您的角色，请参阅[什么是 IAM Access Analyzer？](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)。

一个账户中的用户可以切换为相同或不同账户中的角色。使用角色过程中，用户只能执行角色允许的操作并且只能访问角色允许的资源；其原始用户权限处于暂停状态。用户退出角色时，恢复原始用户权限。

## 使用不同的开发和生产账户的示例方案
<a name="id_roles_common-scenarios_aws-accounts-example"></a>

假设您的组织拥有多个 AWS 账户 以将开发环境与生产环境隔离。开发账户中的用户有时可能需要访问生产账户中的资源。例如，在促进从开发环境到生产环境的更新时，您可能需要进行跨账户访问。尽管您可以为在两个账户中工作的用户创建单独的身份 (和密码)，多个账户的凭证管理还是会为身份管理带来难题。在以下图表中，所有用户都通过开发账户进行管理，但一些开发人员需要对生产账户进行有限访问。开发账户有两个组：测试人员和开发人员，每个组有其自身的策略。

![\[使用角色向不同账户中的用户委托权限\]](http://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/images/roles-usingroletodelegate.png)


1. 在生产账户中，管理员使用 IAM 在该账户中创建 `UpdateApp` 角色。在角色中，管理员定义信任策略，该策略将开发账户指定为 `Principal`，这意味着开发账户中的授权用户可以使用 `UpdateApp` 角色。管理员还为角色定义权限策略，以指定对名为 `productionapp` 的 Amazon S3 存储桶的读取和写入权限。

   然后，管理员相应信息与需要担任角色的所有人共享。该信息是角色的账号和名称（对于 AWS 控制台用户）或 Amazon Resource Name (ARN)（用于 AWS CLI 或 AWS API 访问）。角色 ARN 类似于 `arn:aws:iam::123456789012:role/UpdateApp`，其中角色名为 `UpdateApp`，角色采用账号 123456789012 进行创建。
**注意**  
管理员可以选择配置角色，以便担任角色的用户必须先使用多重身份验证 (MFA) 进行身份验证。有关更多信息，请参阅 [使用 MFA 保护 API 访问](id_credentials_mfa_configure-api-require.md)。

1. 在开发账户中，管理员向开发人员组的成员授予切换为角色的权限。执行此操作的方法是向开发人员组授予针对 `UpdateApp` 角色调用 AWS Security Token Service (AWS STS) `AssumeRole` API 的权限。开发账户中开发人员组的所有 IAM 用户现在都可以切换为生产账户中的 `UpdateApp` 角色。不在开发人员组中的其他用户无权切换为该角色，因此无法访问生产账户中的 S3 存储桶。

1. 用户请求切换为角色：
   + AWS 控制台：用户选择导航栏上的账户名并选择 **Switch Role (切换角色)**。用户指定账户 ID (或别名) 和角色名称。或者，用户可以单击管理员在电子邮件中发送的链接。通过该链接，用户可以转到已填写详细信息的 **Switch Role** 页面。
   + AWS API/AWS CLI：开发账户中开发人员组的用户调用 `AssumeRole` 函数以获取 `UpdateApp` 角色的凭证。用户将 `UpdateApp` 角色的 ARN 指定为调用的一部分。如果测试人员组中的用户发出相同请求，请求将失败，因为测试人员没有针对 `UpdateApp` 角色 ARN 调用 `AssumeRole` 的权限。

1. AWS STS 返回临时凭证：
   + AWS 控制台：AWS STS 使用角色的信任策略来验证请求，以确保请求来自受信任实体（即开发账户）。验证完成后，AWS STS 向 AWS 控制台返回[临时安全凭证](https://docs.aws.amazon.com/STS/latest/UsingSTS/Welcome.html)。
   + API/CLI：AWS STS 根据角色的信任策略来验证请求，以确保请求来自受信任实体 (即开发账户)。验证完成后，AWS STS 向应用程序返回[临时安全凭证](https://docs.aws.amazon.com/STS/latest/UsingSTS/Welcome.html)。

1. 临时凭证允许访问 AWS 资源：
   + AWS 控制台：AWS 控制台在所有后续控制台操作中代表用户使用临时凭证，在本例中是用于读取和写入 `productionapp` 存储桶。该控制台无法访问生产账户中的任何其他资源。用户退出角色时，用户的权限恢复为切换为角色之前所拥有的原始权限。
   + API/CLI：应用程序使用临时安全凭证更新 `productionapp` 存储桶。应用程序只能使用临时安全凭证读取和写入 `productionapp` 存储桶，无法访问生产账户的任何其他资源。应用程序不必退出角色，只需在后续 API 调用中停止使用临时凭证并使用原始凭证。

## 其他资源
<a name="id_roles_common-scenarios_more-info"></a>

有关更多信息，请参阅下列内容：
+ [IAM 教程：使用 IAM 角色委托跨 AWS 账户的访问权限](tutorial_cross-account-with-roles.md)

# 非 AWS 工作负载的访问权限
<a name="id_roles_common-scenarios_non-aws"></a>

[IAM 角色](id_roles.md)是 AWS Identity and Access Management（IAM）中分配[权限](access_policies.md)的对象。当您[担任的角色](id_roles_manage-assume.md)使用 IAM 身份或来自 AWS 外部的身份时，它会为您提供角色会话的临时安全凭证。您的工作负载可能在数据中心或其他 AWS 外部必须访问您 AWS 资源的基础设施中运行。除了创建、分发和管理长期访问密钥之外，您可以使用 AWS Identity and Access Management Roles Anywhere（IAM Roles Anywhere）来验证您的非 AWS 工作负载。IAM Roles Anywhere 使用您的证书颁发机构（CA）颁发的 X.509 证书对身份进行验证，并安全地使用 IAM 角色提供的临时证书提供对 AWS 服务 的访问权限。

**使用 IAM Roles Anywhere**

1. 设置使用 [AWS 私有证书颁发机构](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) 的 CA 或者使用来自您自己的 PKI 基础设施的 CA。

1. 设置 CA 后，您可以在 IAM Roles Anywhere 中创建一个称为*信任锚*的对象。此锚点在 IAM Roles Anywhere 和您的 CA 之间建立信任以进行身份验证。

1. 然后，您可以配置现有的 IAM 角色，或者创建信任 IAM Roles Anywhere 服务的新角色。

1. 使用信任锚点通过 IAM Roles Anywhere 对非 AWS 工作负载进行身份验证。AWS 将非 AWS 工作负载临时凭证授予有权访问您的 AWS 资源的 IAM 角色。

## 其他资源
<a name="id_roles_non-aws_additional_resources"></a>

以下资源可以帮助您了解有关提供非 AWS 工作负载访问权限的更多信息。
+ 有关配置 IAM Roles Anywhere 的更多信息，请参阅《IAM Roles Anywhere 用户指南》中的[什么是 AWS Identity and Access Management Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html)。
+ 要了解如何设置 IAM Roles Anywhere 的公有密钥基础设施（PKI），请参阅*AWS安全博客*中的 [IAM Roles Anywhere with an external certificate authority](https://aws.amazon.com/blogs/)。

# 访问第三方拥有的 AWS 账户
<a name="id_roles_common-scenarios_third-party"></a>

当第三方请求访问您的组织的 AWS 资源时，您可以使用角色向他们委派访问权限。例如，第三方可能某种服务来管理您的 AWS 资源。您可以通过 IAM 角色授予第三方访问您的 AWS 资源的权限，而无需共享您的 AWS 安全凭证。而第三方则可以通过代入您在 AWS 账户 中创建的角色来访问您的 AWS 资源。要了解您信任区域之外的账户（受信任的企业或账户）中的主体是否有权承担您的角色，请参阅[什么是 IAM Access Analyzer？](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)。

为了创建他们可以代入的角色，第三方必须为您提供以下信息：
+ **第三方的 AWS 账户 ID**。为角色定义信任策略时，可将其 AWS 账户 ID 指定为主体。
+ **与角色唯一关联的外部 ID**。外部 ID 可以是仅您和第三方已知的任何标识符。例如，您可以使用您与该第三方之间的发票 ID，但不要使用能被猜到的内容，如第三方的名称或电话号码。为角色定义信任策略时，必须指定该 ID。第三方在代入角色时必须提供该 ID。
+ **第三方使用您的 AWS 资源所需的权限。**在定义角色的权限策略时，您必须指定这些权限。这个策略定义了他们可以执行哪些操作以及可以访问哪些资源。

创建完角色后，您必须向第三方提供该角色的 Amazon Resource Name (ARN)。他们需要使用您的角色的 ARN 来代入该角色。

**重要**  
当您授予第三方访问 AWS 资源的权限时，他们可以访问您在该策略中指定的任何资源。系统会为您发送他们使用资源的记录。请确保适当限制他们对资源的使用。

## 用于第三方访问的外部 ID
<a name="id_roles_third-party_external-id"></a>

外部 ID 允许正担任该角色的用户断言其运行的环境。它还为账户所有者提供一种方法来允许仅在特定情况下担任该角色。外部 ID 的主要功能是解决并防止 [混淆代理人问题](confused-deputy.md)。

**重要**  
AWS 不会将该外部 ID 作为秘密信息。您在 AWS 中创建访问密钥对或密码这类秘密信息后，您无法再次查看它们。有权查看角色的任何人都可以看到该角色的外部 ID。

## 我何时应使用外部 ID？
<a name="external-id-use"></a>

在以下情况下使用外部 ID：
+ 您是 AWS 账户 所有者并且已为将访问其他 AWS 账户 以及您的账户的第三方配置角色。您应要求第三方提供其在担任您的角色时包含的外部 ID。然后，在您角色的信任策略中检查该外部 ID。这样做可确保外部方仅在代表您执行操作时才能担任您的角色。
+ 在前述情况下，您代表不同客户 (如 Example Corp) 担任角色。您应该为每个客户分配一个唯一的外部 ID 并指导他们将该外部 ID 添加到其角色的信任策略。然后，您必须确保在担任角色的请求中始终包含正确的外部 ID。

  您可能已为您的每个客户提供一个唯一标识符，而且此唯一 ID 足以用作外部 ID。该外部 ID 不是您要明确创建或分别跟踪所需的特殊值 (仅用于此目的)。

  您应始终在您的 `AssumeRole` API 调用中指定外部 ID。此外，在客户为您提供角色 ARN 时，请测试是否能在带有/不带正确外部 ID 的情况下担任该角色。如果可在没有正确外部 ID 的情况下担任角色，则不要在您的系统中存储该客户的角色 ARN。等待该客户将角色信任策略更新为要求提供正确的外部 ID。这样一来，您帮助您的客户执行了正确的操作，并帮助您和客户避免了混淆代理人问题。

## 使用外部 ID 的示例场景
<a name="id_roles_third-party_example"></a>

例如，假设您决定聘请一家名为 Example Corp 的第三方公司来监控您的 AWS 账户 并帮助优化成本。为跟踪您的日常开支，Example Corp 需要访问您的 AWS 资源。Example Corp 也可监控其他客户的很多其他 AWS 账户。

请勿向 Example Corp 提供对您的 AWS 账户中的 IAM 用户及其长期凭证的访问权限。请使用 IAM 角色 角色及其临时安全凭证。IAM 角色提供了一种机制，可允许第三方访问您的 AWS 资源而无需共享长期凭证（例如，IAM 用户的访问密钥）。

您可使用 IAM 角色在您的 AWS 账户 和 Example Corp 账户之间建立信任关系。建立这种关系后，Example Corp 账户的成员可以调用 AWS Security Token Service [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API 以获取临时安全凭证。然后，Example Corp 成员可以使用这些凭证访问您的账户中的 AWS 资源。

**注意**  
有关可调用来获取临时安全凭证的 AssumeRole 和其他 AWS API 操作的更多信息，请参阅[比较 AWS STS 凭证](id_credentials_sts-comparison.md)。

以下是此方案的更多详细信息：

1. 您聘请了 Example Corp，此公司将为您创建唯一客户标识符。他们为您提供此唯一客户 ID 及其 AWS 账户 账号。您需要此信息来在下一步中创建 IAM 角色。
**注意**  
Example Corp 可使用其想用于 ExternalId 的任何字符串值，只要该值对于每个客户来说都是唯一的。该值可以是客户账号，甚至可以是一个随机字符串，只要没有两个客户拥有相同的值即可。该值不是“机密的”。Example Corp 必须向每个客户提供 ExternalId 值。关键的一点是，该值必须由 Example Corp 生成，而***不是***其客户生成，从而确保每个外部 ID 是唯一的。

1. 您登录到 AWS 并创建 IAM 角色，该角色可向 Example Corp 提供对您的资源的访问权。与任何 IAM 角色类似，该角色具有两个策略：权限策略和信任策略。该角色的信任策略规定谁可担任该角色。在我们的示例方案中，该策略将 Example Corp 的 AWS 账户 账号指定为 `Principal`。这允许来自此账户的身份担任该角色。此外，将 `[Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Condition)` 元素添加到信任策略。此 `Condition` 测试 `ExternalId` 上下文密钥，以确保它与 Example Corp 的唯一客户 ID 一致。例如：

   ```
       "Principal": {"AWS": "Example Corp's AWS 账户 ID"},
       "Condition": {"StringEquals": {"sts:ExternalId": "Unique ID Assigned by Example Corp"}}
   ```

1. 该角色的权限策略指定该角色允许某个人执行哪些操作。例如，您可以规定该角色允许某人仅管理您的 Amazon EC2 和 Amazon RDS 资源，但不能管理您的 IAM 用户或组。在我们的示例方案中，您使用权限策略为 Example Corp 授予您的账户中的所有资源的只读访问权限。

1. 创建完角色后，您向 Example Corp 提供该角色的 Amazon Resource Name (ARN)。

1. 当 Example Corp 需要访问您的 AWS 资源时，该公司的某人可调用 AWS `sts:AssumeRole` API。该调用包括要担任的角色的 ARN 以及与其客户 ID 对应的 ExternalId 参数。

如果发出请求的人使用的是 Example Corp 的 AWS 账户，并且角色 ARN 和外部 ID 是正确的，则请求成功。然后，该请求提供临时安全凭证，Example Corp 可使用这些凭证访问您的角色允许访问的 AWS 资源。

换句话说，当角色策略包括外部 ID 时，任何需要担任该角色的人都必须是该角色中的主体，还必须包括正确的外部 ID。

## 外部 ID 的要点
<a name="id_roles_third-party_key-points"></a>
+ 在您支持多个客户拥有不同 AWS 账户的多租户环境中，我们建议每个 AWS 账户 使用一个外部 ID。此 ID 应该是第三方生成的随机字符串。
+ 要在代入角色时需要提供外部 ID 的第三方，请使用您选择的外部 ID 来更新角色的信任策略。
+ 要在代入角色时提供外部 ID，请使用 AWS CLI 或 AWS API 来代入该角色。有关更多信息，请参阅 STS [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API 操作或 STS [assume-role](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role.html) CLI 操作。
+ `ExternalId` 值的长度必须最少为 2 个字符，最多为 1224 个字符。该值必须是字母数字，没有空格。它还可以包含以下符号：加号 (\$1)、等号 (=)、逗号 (,)、句点 (.)、@ 符号、冒号 (:)、正斜杠 (/) 和连字符 (-)。

## 其他资源
<a name="id_roles_third-party_additional_resources"></a>

以下资源可帮助您了解有关向第三方拥有的 AWS 账户 提供访问权限的更多信息。
+ 要了解如何允许其他人在您的 AWS 账户 中执行操作，请参阅 [使用自定义信任策略创建角色](id_roles_create_for-custom.md)。
+ 要了解如何授予切换到角色的权限，请参阅 [向用户授予切换角色的权限](id_roles_use_permissions-to-switch.md)
+ 要了解如何创建并向受信任的用户提供临时安全凭证，请参阅 [临时安全凭证的权限](id_credentials_temp_control-access.md)。

# 访问 AWS 服务
<a name="id_roles_common-scenarios_services"></a>

很多 AWS 服务要求您利用角色控制该服务可以访问的内容。由一项服务担任、代表您执行操作的角色称为[服务角色](id_roles.md#iam-term-service-role)。当某角色为某项服务提供专门用途时，可以将其归类为[服务相关角色](id_roles.md#iam-term-service-linked-role)。请参阅每种服务的 [AWS 文档](https://docs.aws.amazon.com/)，以了解它是否使用角色以及如何分配角色以供服务使用。

有关创建角色以向 AWS 提供的服务委派访问权限的详细信息，请参阅[创建向 AWS 服务委派权限的角色](id_roles_create_for-service.md)。

# 访问经过外部身份验证的用户（身份联合验证）
<a name="id_roles_common-scenarios_federated-users"></a>

您的用户可能已具有 AWS 外部的身份，如在公司目录中。如果这些用户需要使用 AWS 资源（或使用访问这些资源的应用程序），则这些用户也需要 AWS 安全凭证。您可以使用 IAM 角色为身份通过您的企业或第三方身份提供程序 (IdP) 进行联合证明的用户指定权限。

**注意**  
作为安全最佳实践，我们建议您使用身份联合验证在 [IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/what-is.html) 中管理用户访问权限，而不是创建 IAM 用户。要了解需要使用 IAM 用户的特定情况，请参阅 [何时创建 IAM 用户（而非角色）](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose)。

## 通过 Amazon Cognito 联合移动或基于 Web 的应用程序的用户
<a name="id_roles_common-scenarios_federated-users-cognito"></a>

如果创建访问 AWS 资源的移动或基于 Web 的应用程序，则应用程序需要安全凭证才能向 AWS 进行编程请求。对于大多数移动应用程序情况，我们建议您使用 [Amazon Cognito](https://aws.amazon.com/cognito/)。您可以将此服务与 [AWS Mobile SDK for iOS](https://aws.amazon.com/sdkforios/) 和 [AWS Mobile SDK for Android and Fire OS](https://aws.amazon.com/sdkforandroid/) 搭配使用，为用户创建唯一的身份，并对其进行身份验证，以使其安全地访问您的 AWS 资源。Amazon Cognito 支持与下一个部分中所列的那些提供商相同的身份提供程序，而且还支持已经过[开发人员验证的身份](https://aws.amazon.com/blogs/mobile/amazon-cognito-announcing-developer-authenticated-identities)和未经身份验证的（来宾）访问。Amazon Cognito 还提供用于同步用户数据的 API 操作，因此，无论用户在设备间怎样转移，其数据总能得以保留。有关更多信息，请参阅 [用于移动应用程序的 Amazon Cognito](id_federation_common_scenarios.md#id_roles_providers_oidc_cognito)。

## 使用公共身份服务提供商或 OpenID Connect 联合身份用户
<a name="id_roles_common-scenarios_federated-users-openId"></a>

在移动和基于 Web 的场景下尽可能使用 Amazon Cognito。Amazon Cognito 为您提供公共身份提供程序服务的大部分幕后工作。它与相同的第三方服务协作，也支持匿名登录。不过，对于更高级的方案，您可以直接使用第三方服务，例如 Login with Amazon、Facebook、Google 或任何与 OpenID Connect (OIDC) 兼容的 IdP。有关通过这些服务之一使用 OIDC 联合身份验证的更多信息，请参阅 [OIDC 联合身份验证](id_roles_providers_oidc.md)。

## 通过 SAML 2.0 联合身份用户
<a name="id_roles_common-scenarios_federated-users-saml20"></a>

如果您的组织已使用支持 SAML 2.0 (安全断言标记语言 2.0) 的身份提供程序软件包，您可以在作为身份提供程序 (IdP) 的您的组织和作为服务提供商的 AWS 之间建立信任。随后可以使用 SAML 为您的用户提供对 AWS 管理控制台的联合单一登录 (SSO)，或是用于调用 AWS API 操作的联合访问。例如，如果您的公司使用 Microsoft Active Directory 和 Active Directory 联合身份验证服务，则您可以使用 SAML 2.0 进行联合。有关使用 SAML 2.0 对用户进行联合身份验证的更多信息，请参阅[SAML 2.0 联合身份验证](id_roles_providers_saml.md)。

## 通过创建自定义身份代理应用程序来联合身份用户
<a name="id_roles_common-scenarios_federated-users-idbroker"></a>

如果您的身份存储与 SAML 2.0 不兼容，则可构建自定义身份代理应用程序来执行类似功能。代理应用程序将对用户进行身份验证，从 AWS 为用户请求临时安全凭证，然后将凭证提供给用户以便访问 AWS 资源。

例如，Example Corp. 有很多员工需要运行访问公司 AWS 资源的内部应用程序。这些员工在公司的身份与验证系统中已有身份，并且 Example Corp. 不希望为每位公司员工都创建一个单独的 IAM 用户。

Bob 是 Example Corp. 的一名开发人员。为使 Example Corp. 的内部应用程序可访问公司的 AWS 资源，Bob 开发了一个自定义身份代理应用程序。该应用程序确认员工登录到现有的 Example Corp. 身份与验证系统，而该系统可能使用 LDAP、Active Directory 或其他系统。然后，身份代理应用程序获取员工的临时安全凭证。此场景与以前的某个场景（一个使用自定义身份验证系统的移动应用程序）类似，但需要访问 AWS 资源的应用程序全都运行在企业网络中，并且公司现有一个身份验证系统。

为了获取临时安全凭证，该身份代理应用程序调用 `AssumeRole` 或 `GetFederationToken` 以获取临时安全凭证，具体取决于 Bob 要如何管理用户的策略以及临时凭证应何时到期。(有关这些 API 操作之间的差异的更多信息，请参阅[IAM 临时安全凭证](id_credentials_temp.md)和[临时安全凭证的权限](id_credentials_temp_control-access.md)。) 该调用返回由 AWS 访问密钥 ID、秘密访问密钥和会话令牌组成的临时安全凭证。该身份代理应用程序向内部公司应用程序提供这些临时安全凭证。然后，该应用程序可使用这些临时凭证直接调用 AWS。该应用程序将证书缓存至其到期，然后请求新的一组临时证书。下图举例说明此场景。

![\[使用自定义身份代理应用程序的示例工作流\]](http://docs.aws.amazon.com/zh_cn/IAM/latest/UserGuide/images/enterprise-authentication-with-identity-broker-application.diagram.png)


此方案有以下属性：
+ 该身份代理应用程序具有访问 IAM 的令牌服务 (STS) API 以创建临时安全凭证的权限。
+ 该身份代理应用程序可确认员工在现有的身份验证系统中经过身份验证。
+ 用户可获得一个临时 URL，通过它可访问 AWS 管理控制台 (称为单点登录)。

有关创建临时安全凭证的信息，请参阅[比较 AWS STS 凭证](id_credentials_sts-comparison.md)。有关获取对 AWS 管理控制台的访问权限的 SAML 联合主体的更多信息，请参阅 [使 SAML 2.0 联合主体能够访问 AWS 管理控制台](id_roles_providers_enable-console-saml.md)。