# 访问经过外部身份验证的用户（身份联合验证）
<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)。