联合身份模式
将身份验证委托给外部身份提供者。这可以简化开发，最大限度地减少用户管理的需求，并改善应用程序的用户体验。
问题和背景
用户通常需要使用与其业务关系的不同组织提供和托管的多个应用程序。这些用户可能需要为每个用户使用特定（和不同的）凭据。 这会导致：
- 导致用户体验脱节。当用户有很多不同的凭据时，用户经常忘记登录凭据，。
- 暴露安全漏洞。当用户离开公司时，该帐户必须立即禁止使用。大型组织中很容易忽略这一点。
- 复杂的用户管理。管理员必须管理所有用户的凭据，并执行其它任务，例如提供密码更换提醒。
- 用户通常喜欢为所有应用程序使用相同的凭据。
解决方案
实现可以使用联合身份的身份验证机制。将用户认证与应用程序代码分开，并将认证委托给受信任的身份提供者。这可以简化开发，并允许用户使用更广泛的身份提供者（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域中输入了电子邮件地址，如[email protected]，则STS将将用户重定向到Microsoft帐户登录页面。在稍后的访问中，STS可以使用cookie来表示最后登录的是Microsoft帐户。如果自动发现无法确定家庭领域???，则STS将显示列出受信任身份提供商的家庭领域发现页面，用户必须选择想要使用的域名。
何时使用该模式
本模式适于以下场景：
- 单一登录企业。在这种情况下，需要为在公司安全边界外的云中托管的应用程序进行身份验证，无需每次访问应用程序时登录。用户体验与在登录公司网络时使用内部部署应用程序进行身份验证相同，从那时起可以访问所有相关应用程序，无需再次登录。
- 与多个合作伙伴的联合身份。在这种情况下，需要对在公司目录中没有帐户的公司员工和业务伙伴进行身份验证。这在企业对企业应用程序，与第三方服务集成的应用程序以及合并了不同IT系统的公司或共享资源的公司中是常见的。
- SaaS应用中的联合身份。在这种情况下，独立软件供应商为多个客户或租户提供即用型服务。每个租户使用合适的身份提供商进行身份验证。例如，业务用户将使用他们的公司凭证，而租户的消费者和客户将使用他们的社会身份凭证。
本模式可能不适于以下场景：
- 应用程序的所有用户都可以通过一个身份提供者进行身份验证，并且不需要使用任何其他身份提供者进行身份验证。这是在使用企业目录（在应用程序中可访问的）进行身份验证，通过使用VPN或（在云托管场景中）通过本地目录和应用程序之间的虚拟网络连接的业务应用程序中的典型方式。
- 该应用程序最初使用不同的身份验证机制构建，可能有自定义用户存储，或者没有能力处理基于声明的技术使用的协商标准。 将基于声明的身份验证和访问控制应用到现有应用程序可能很复杂，不划算。
案例
组织在Microsoft Azure中托管多租户软件即服务（SaaS）应用程序。该应用程序包括租户可以使用来管理自己用户的应用程序的网站。当用户通过该组织自己的Active Directory进行身份验证时，应用程序允许租户通过使用由Active Directory联合身份验证服务（ADFS）生成的联合身份来访问该网站。
该图显示租户如何使用自己的身份提供者进行身份验证（步骤1），图中为ADFS。在成功验证租户后，ADFS发出令牌。浏览器将此令牌转发到SaaS应用程序的联合提供者，该提供者信任由租户的ADFS发出的令牌，以便获取对SaaS联合提供者有效的令牌（步骤2）。如果需要，SaaS联合提供者将令牌中的声明转换为应用程序在将新令牌返回到浏览器之前识别的声明（步骤3）。应用程序信任由SaaS联合提供者发出的令牌，并使用令牌中的声明来应用授权规则（步骤4）。
租户不需要记住访问应用程序的单独凭据，租户公司的管理员可以在自己的ADFS中配置访问应用程序的用户列表。