联合身份模式

将身份验证委托给外部标识提供者。 这可以简化开发、最小化对用户管理的要求，并改善应用程序的用户体验。

上下文和问题

用户通常需要使用多个应用程序，这些应用程序由与用户有业务关系的不同组织提供和托管。 这些用户可能需要使用每个应用程序的特定（和不同）的凭据。 这可能：

• 导致用户体验不连贯。 当用户拥有许多不同的凭据时，他们常常会忘记登录凭据。
• 暴露安全漏洞。 当用户离开公司时，帐户必须立即取消设置。 在大型组织中尤为容易忽略这一点。
• 使用户管理复杂化。 管理员必须管理所有用户的凭据，并执行其他任务，例如提供密码提醒。

用户通常喜欢对所有这些应用程序使用同一凭据。

解决方案

实现可以使用联合身份的身份验证机制。 将用户身份验证与应用程序代码分离，并将身份验证委托给受信任的标识提供者。 这可以简化开发，并允许用户使用更广泛的标识提供者 (IdP) 进行身份验证，同时最小化管理开销。 它还允许明确地将身份验证与授权分离。

可信任的标识提供者包括公司目录、本地联合服务、由业务伙伴提供的其他安全令牌服务 (STS)，或可以对拥有 Microsoft、Google、Yahoo! 或 Facebook帐户的用户进行身份验证的社交标识提供者。

该图说明了当客户端应用程序需要访问要求身份验证的服务时的联合身份模式。 身份验证由与 STS 协同工作的 IdP 执行。 IdP 颁发安全令牌，该安全令牌提供已进行身份验证用户的信息。 该信息（又称为声明）包括用户的标识，并且还可包含其他信息（如角色成员资格和更具体的访问权限）。

此模型通常称为基于声明的访问控制。 应用程序和服务基于令牌中包含的声明授权访问功能。 需要身份验证的服务必须信任 IdP。 客户端应用程序联系执行身份验证的 IdP。 如果身份验证成功，IdP 将向 STS 返回包含标识用户的声明的令牌（请注意，IdP 和 STS 可以是同一服务）。 STS 可以基于预定义规则，在将其返回到客户端之前，转换和扩大令牌中的声明。 然后，客户端应用程序可以将此令牌传递到服务，作为其标识的证明。

在信任链中可能有额外的 STS。 例如，在下面描述的方案中，本地 STS 信任负责访问标识提供者以对用户进行身份验证的另一 STS。 这是在企业方案中的常见方法，其中包含本地 STS 和目录。

联合身份验证为跨不同域的信任标识的问题提供了一个基于标准的解决方案，并且可以支持单一登录。 它在所有类型的应用程序（尤其是云托管应用程序）中变得越来越普遍，因为它支持单一登录，无需与标识提供者的直接网络连接。 用户不必为每个应用程序输入凭据。 这增加了安全性，因为它可避免访问多个不同应用程序所需的凭据创建，并且它还对除原始标识提供者外的所有标识提供者隐藏用户凭据。 应用程序仅可查看令牌中包含的已经过身份验证的标识信息。

联合身份还具有一大优点，即标识提供者负责管理标识和凭证。 应用程序或服务不需要提供标识管理功能。 此外，在公司方案中，如果公司目录信任标识提供者，则不需要知道用户。 这会免去在目录中管理用户标识的所有管理开销。

问题和注意事项

设计实现联合身份验证的应用程序时，请考虑以下事项：

• 身份验证可以是单点故障。 如果将应用程序部署到多个数据中心，请考虑将标识管理机制部署到同一数据中心，以维护应用程序的可靠性和可用性。
• 通过身份验证工具，可基于身份验证令牌中的角色声明配置访问控制。 这通常称为基于角色的访问控制 (RBAC)，并且它允许对功能和资源的访问进行较具体级别的控制。
• 与公司目录不同，使用社交标识提供者的基于声明的身份验证通常不提供经过身份验证的用户的信息（电子邮件地址和名称除外）。 某些社交标识提供者（如 Microsoft 帐户）仅提供唯一标识符。 应用程序通常需要维护注册用户的一些信息，并能够将此信息与令牌中的声明中包含的标识符相匹配。 这通常通过用户首次访问应用程序时的注册来完成，在每次身份验证之后，信息作为附加声明注入到令牌中。
• 如果为 STS 配置了多个标识提供者，则它必须检测用户应重定向到哪个标识提供者（用于身份验证）。 这个过程称为主页领域发现。 STS 可以基于用户提供的电子邮件地址或用户名、用户正在访问的应用程序的子域、用户的 IP 地址范围或存储在用户浏览器 cookie 中的内容来自动执行此操作。 例如，如果用户在 Microsoft 域中输入电子邮件地址（例如 user@live.com），则 STS 会将用户重定向到 Microsoft 帐户登录页面。 在以后的访问中，STS 可以使用 cookie 来指示最后的登录使用的是 Microsoft 帐户。如果自动发现无法确定主页领域，则 STS 会显示列出受信标识提供者的主页领域发现页，用户必须选择其中之一来使用。

何时使用此模式

此模式适用于以下方案：

• 企业中的单一登录。 在此方案中，需要对公司安全边界外的云托管的公司应用程序进行员工身份验证，而无需要求他们在每次访问应用程序时登录。 用户体验与使用本地应用程序时的用户体验相同，在登录到公司网络时进行身份验证，此后即可访问所有相关应用程序，无需再次登录。
• 与多个合作伙伴的联合身份。 在此方案中，需要对公司员工以及在公司目录中没有帐户的业务合作伙伴进行身份验证。 这在企业到企业应用程序、与第三方服务集成的应用程序，以及已合并或共享资源的具有不同 IT 系统的公司中很常见。
• SaaS 应用程序中的联合身份。 在此方案中，独立软件供应商为多个客户端或租户提供即用型服务。 每个租户使用合适的标识提供者进行身份验证。 例如，公司用户将使用其公司凭据，而租户的使用者和客户将使用其社交标识凭据。

此模式在以下情况中可能不起作用：

• 应用程序的所有用户都可以由一个标识提供者进行身份验证，并且无需使用任何其他标识提供者进行身份验证。 这在使用公司目录（可在应用程序中访问）进行身份验证的业务应用程序中很典型，身份验证的方式是通过使用 V** 或（在云托管方案中）通过本地目录与应用程序之间的虚拟网络连接。
• 最初使用不同的身份验证机制构建应用程序，可能使用了自定义用户存储，或不具备处理基于声明的技术使用的协商标准的能力。 将基于声明的身份验证和访问控制更新到现有应用程序可能很复杂，并且可能不具有成本效益。