你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
将用户身份验证委托给外部标识提供者（IdP），以简化开发、最小化管理任务并改进应用程序 UX。
上下文和问题
用户通常需要与合作伙伴组织提供和托管的多个应用程序协作。 它们可能需要为每个应用程序使用特定的、不同的登录凭据。 此要求可以：
导致割裂的用户体验。 员工经常忘记多个登录凭据。
公开安全漏洞。 当员工离开公司时，组织必须立即停用该帐户。 大型组织通常会错过这一关键步骤。
使用户管理复杂化。 管理员管理用户凭据、发出密码提醒和执行其他管理任务。
用户通常更喜欢对所有应用程序使用相同的登录凭据。
解决方案
实现联合标识身份验证机制。 将用户身份验证与应用程序代码分开，并将身份验证委托给受信任的 IdP。 此过程简化了开发，最大限度地减少了管理开销，并通过一系列 IdP 提供用户身份验证。 联合标识还会将身份验证与授权分开。
受信任的 IdP 包括公司目录、本地联合身份验证服务、安全令牌服务（STSs）和社交 IdP，例如 Microsoft、Google、Yahoo！或 Facebook。
下图显示了访问需要身份验证的服务的客户端应用程序的联合标识模式。 IdP 与 STS 协同工作以提供身份验证。 IdP 颁发安全令牌，该安全令牌提供已进行身份验证用户的信息。 此信息称为 声明，包括用户的标识，也可能包括其他声明，例如角色成员身份和更精细的访问权限。
此模型也称为基于声明的访问控制。 应用程序和服务根据声明授权访问特性和功能。 需要身份验证的服务必须信任 IdP。 客户端应用程序联系 IdP 进行身份验证。 如果身份验证成功，IdP 会向 STS 返回一个包含用于标识用户的声明的令牌。 IdP 和 STS 可能是同一服务的一部分。 STS 可以根据预定义的规则转换和扩充声明，然后再将令牌返回到客户端。 然后，客户端应用程序将此令牌作为标识证明传递给服务。
联合身份验证提供基于标准的方法来跨域建立对标识的信任，并支持单一登录（SSO）。 许多应用程序（尤其是云托管的应用程序）都使用联合身份验证，因为它支持 SSO，而无需与 IdP 建立直接网络连接。 此设计增加了安全性，因为用户不需要为多个应用程序创建和输入不同的登录凭据。 此外，它还将凭据的暴露范围仅限于原始 IdP。 应用程序仅查看令牌中经过身份验证的标识信息。
使用联合身份验证的应用程序和服务不需要提供标识管理功能。 相反，IdP 负责标识和凭据管理。 当公司目录信任 IdP 时，它不需要管理用户标识。 此方法消除了基于目录的用户标识管理的管理开销。
问题和注意事项
在决定如何实现此模式时，请考虑以下几点：
身份验证可以是单点故障。 若要跨多个区域维护应用程序可靠性和可用性，请考虑在应用程序所在的同一区域中部署标识管理机制。
若要配置基于角色的访问控制（RBAC），请使用身份验证工具。 RBAC 支持对功能和资源访问进行精细控制。
与公司目录不同，使用社交 IdP 的基于声明的身份验证通常仅提供经过身份验证的用户的电子邮件地址，有时提供其名称。 某些社交 IDP（如Microsoft）仅提供唯一标识符。 应用程序通常维护有关已注册用户的一些信息，以便它可以将此信息与声明中的标识符匹配。 当用户首次访问应用程序时，通常会在注册期间完成此任务。 然后，在每次身份验证后，信息将作为新声明注入令牌中。
如果为 STS 配置了多个 IdP，STS 必须确定哪些 IdP 应对用户进行身份验证。 此过程称为 主领域发现。 STS 可能会根据用户提供的信息（例如电子邮件地址或用户名、应用程序子域、用户的 IP 地址范围或存储在用户的浏览器中的 Cookie）自动确定 IdP。 例如，如果用户输入Microsoft电子邮件地址，例如
user@live.com，STS 会将用户重定向到Microsoft 帐户登录页。 在后续访问中，STS 可以使用一个 Cookie 来指示用户以前使用Microsoft 帐户登录。 如果 STS 无法自动确定主领域，则会显示一个主领域发现页，其中列出了受信任的 IdP。 然后用户选择一个 IdP。
何时使用此模式
如果需要，请使用此模式：
企业中的 SSO。 在这种情况下，你需要对员工进行身份验证，以便他们能够访问托管在企业安全边界之外的云中的企业应用程序，而无需在每次访问应用程序时都重新登录。 用户体验与本地应用程序匹配。 用户在登录到公司网络时进行身份验证，然后他们无需再登录即可访问相关应用程序。
与多个合作伙伴的联合身份验证 在此方案中，需要对没有企业目录中帐户的企业员工和业务合作伙伴进行身份验证。 这种做法在企业到企业应用程序、与合作伙伴服务集成的应用程序以及使用不同 IT 系统或合并或共享资源的公司中很常见。
软件即服务（SaaS）应用程序中的联合标识。 在此方案中，独立软件供应商为多个客户端或租户提供现成的服务。 租户使用合适的 IdP 进行身份验证。 例如，业务用户使用其公司凭据，而租户使用者和客户端则使用社交标识凭据。
用于工作负荷访问的联合标识。 在此方案中，租户应用程序、自动化工作流或持续集成和持续交付系统需要调用没有用户存在的 API。 租户通过使用工作负载标识，经由各自的 IdP 进行身份验证。 应用程序使用租户范围的声明验证来授权访问。
如果存在以下情况，则此模式可能不适用：
一个 IdP。 在此方案中，应用程序用户使用一个 IdP 进行身份验证，并且无需使用另一个 IdP 进行身份验证。 这种情况通常适用于使用公司目录进行身份验证的应用程序，无论是通过 VPN 还是应用程序与本地目录之间的虚拟网络连接。
不兼容的身份验证机制。 在此方案中，应用程序使用不同的身份验证机制，例如使用自定义用户存储，或者它无法处理基于声明的技术协商标准。 将基于声明的身份验证和访问控制改造为现有应用程序可能很复杂且成本高昂。
工作负载设计
评估如何在工作负载设计中使用联合身份模式，以实现 Azure 良好架构框架支柱 中所述的目标和原则。 下表提供有关此模式如何支持每个支柱目标的指南。
| 支柱 | 此模式如何支持支柱目标 |
|---|---|
| 可靠性 设计决策有助于工作负荷在发生故障后 复原 ，并确保它在发生故障后 恢复到 正常运行状态。 | 此模式将用户管理和身份验证卸载到 IdP，该 IDP 通常具有较高的服务级别目标。 在工作负荷灾难恢复（DR）期间，工作负荷恢复计划不需要解决身份验证组件的问题。 - RE:02 关键流程 - RE：09 DR |
| 安全设计决策有助于确保工作负荷数据和系统的机密性、完整性和可用性。 | 此模式提供基于标识的高级威胁检测和防护功能，而无需在工作负载中实现它们。 外部 IdP 还使用新式可互操作的身份验证协议。 - SE:02 安全开发生命周期 - SE:10 监控和威胁检测 |
| 通过缩放、数据和代码的优化，性能效率可帮助工作负荷高效地满足需求。 | 此模式可帮助你将应用程序资源投入到其他优先级。 - PE:03 选择服务 |
如果此模式在某个支柱中引入权衡取舍，请将它们与其他支柱的目标进行对比。
Example
组织托管包含 Web 前端和后端 API 的多组件基于云的应用程序。 应用程序使用Microsoft Entra ID将身份验证委托给集中式 IdP，而不是在每个组件中实现身份验证逻辑。
下载此体系结构的 Visio 文件。
以下工作流对应于上图。
用户访问 Web 应用。
Web 应用将用户重定向到Microsoft Entra ID进行身份验证。
身份验证成功后，Microsoft Entra ID使用授权代码将用户重定向回 Web 应用。
Web 应用交换令牌的授权代码，并将 POST 请求发送到令牌终结点。
Microsoft Entra ID颁发包含有关用户的声明的令牌。
Web 应用使用此令牌调用后端 API。
Web 应用和后端 API 验证令牌，并根据声明强制执行其授权规则。
API 返回对 Web 应用的响应。
主要特征：
集中式身份验证。 组件依赖于Microsoft Entra ID对用户进行身份验证，这样就不再需要应用程序中的自定义身份验证逻辑。
分散式授权。 应用程序组件基于声明独立强制实施授权决策。
基于声明的访问控制。 使用声明（如角色或范围）确定对功能的访问权限。
基于标准的协议。 组件使用 OAuth 2.0 和 OpenID Connect 进行身份验证。
可选的 MFA 强制实施。 如果风险配置文件需要更强大的登录保证，则可以在Microsoft Entra ID中使用条件访问策略强制实施多重身份验证。
通过联合实现可选扩展。 通过使用跨租户访问设置，可将 Microsoft Entra ID 配置为信任合作伙伴的 Microsoft Entra 租户。 然后，合作伙伴用户可以访问应用程序，而无需更改应用程序组件。