联合身份模式

验证委托给外部身份提供者。这种模式可以简化开发，最大限度地减少对用户管理的要求，并提高了应用程序的用户体验。

背景和问题

用户通常需要使用由提供，并通过与它们有商业关系的不同组织主持的多个应用程序一起工作。但是，这些用户可能被迫使用特定的（和不同的）的凭证，每一个。这可以：

原因脱节的用户体验。用户经常忘记登录凭据时，他们有很多不同的的。
暴露安全漏洞。当用户离开公司的帐户，必须立即取消设置。这是很容易忽略这在大型组织中。
复杂的用户管理。管理员必须管理凭据的所有用户，以及执行等方面提供密码提示的其他任务。

用户会相反，通常期望使用相同的凭证用于这些应用。

解决方案

实现了可以使用联合身份的认证机制。从应用程序代码中分离的用户身份验证和身份验证委派到受信任的身份提供者，可以大大简化开发，让用户使用更广泛的身份提供者（国内流离失所者），同时最大限度地减少管理开销进行身份验证。它也可以让你清楚地分离的授权认证。

可信身份提供者可能包括公司目录，内部部署联合身份验证服务，其他安全令牌服务（STS的）业务合作伙伴提供的，或社会身份提供者可以验证谁拥有用户，例如，微软，谷歌，雅虎或Facebook帐户。

图1示出了当客户端应用程序需要访问要求身份验证的服务的联合身份模式的原理。该认证是通过身份提供者（IDP），在演唱其工作与安全令牌服务（STS）的执行。境内流离失所者问题的主张有关身份验证的用户的信息安全令牌。该信息被称为权利要求中，包括用户的身份，并且还可以包括其他信息，例如角色成员和更细粒度的访问权限。

图1 - 联合身份验证概述

该模型通常被称为基于声明的访问控制。应用程序和服务授权访问基于包含在令牌中的权利要求的特征和功能。要求身份验证必须相信国内流离失所者的服务。客户端应用程序的联系人执行身份验证境内流离失所者。如果认证成功，则的 IdP 返回包含用于识别用户于 STS 的权利要求书的令牌（注意的 IdP 和 STS 可以是相同的服务）。在 STS 可以改变和增大中根据预定义的规则，令牌中的权利要求书，将其返回到客户端之前。然后，客户端应用程序可以将此令牌传递给服务作为其身份证明。

注意在某些情况下可能会有额外的 STS 的信任链。例如，在微软 Azure 的场景描述后，内部部署 STS 信任 STS 另一个是负责访问的身份提供者对用户进行认证。这种方法是在企业的情况普遍，其中有一个本地 STS 和目录。

联合身份验证提供了一个基于标准的解决方案，在不同信任域身份的问题，并且可以支持单点登录。它正在成为在所有类型的应用，特别是云托管的应用越来越普遍，因为它支持上，而不需要直接网络连接到身份提供单点登录。用户不必输入凭据为每一种应用。这增加了安全性，因为它阻止了访问许多不同的应用程序所需的凭据的扩散，同时也隐藏了用户的凭据所有，但原来的身份提供者。应用程序只看到包含的令牌中的身份验证信息。

联合身份也具有重大的优点，即人的身份和凭证管理是身份提供者的责任。应用程序或服务并不需要提供身份管理功能。另外，在企业环境中，企业目录不需要知道关于用户（提供它信任的身份提供者），它去除了管理该目录中的用户身份的所有的管理开销。

问题和注意事项

设计实现联合身份验证的应用程序时考虑以下因素：

身份验证可以是一个单点故障。如果您将应用程序部署到多个数据中心，考虑部署身份管理机制，以相同的数据中心，以保持应用程序的可靠性和可用性。
身份验证机制，可以提供工具来配置基于包含在认证令牌的作用索赔的访问控制。这通常被称为基于角色的访问控制（RBAC），并且它可以允许控制权访问的功能和资源的更精细的水平。
与企业目录，利用社会身份提供者通常不提供有关身份验证的用户以外的电子邮件地址，也许名称的信息基于声明的身份。一些社会身份提供者，如 Microsoft 帐户，只提供一个唯一的标识符。应用程序通常将需要保持对注册用户的一些信息，并且能够匹配该信息，包含在令牌中的权利要求书的标识符。典型地，这是通过一个注册过程完成的用户第一次访问该应用程序时，信息然后被注入到令牌作为每个认证后附加的权利要求。
如果配置为 STS 多个身份提供者，它必须检测其身份提供者，用户应该被重定向到身份验证。这个过程被称为主领域发现。在 STS 可能能够基于电子邮件地址或用户名，该用户提供，该用户被访问时，用户的 IP 地址范围，该应用程序的一个子域，或上的 cookie 中存储的用户的内容自动地执行此浏览器。例如，如果用户在微软域，如user@live.com 输入一个电子邮件地址，在 STS 将用户重定向到 Microsoft 帐户登录页面。在随后的访问中，STS可以使用 cookie 来表示最后登录用的 Microsoft 帐户。如果自动发现无法确定主领域时，STS 将显示一个家庭领域发现（HRD）页，其中列出了受信任的身份提供者，用户必须选择他们想要使用的人。何时使用这个模式

此模式是非常适合的范围内的情况下，如：

在企业单点登录。在这种情况下，您需要验证员工被托管在云中的企业安全边界以外的企业应用程序，而不需要他们每次访问应用程序时签署。用户体验是一样的使用本地应用程序，他们签约到公司网络时，最初通过身份验证的时候，并从此获得所有相关的应用程序，而无需再次登录。
与多个合作伙伴联合身份。在这种情况下，您需要验证这两个企业的员工和业务合作伙伴谁没有在公司目录帐户。这是企业对企业（B2B）的应用程序，集成与第三方服务，并在那里与不同的IT系统公司合并或共享资源的应用普遍。
在SaaS应用联合身份。在这种情况下独立软件供应商（ISV）提供了一个即用型服务，为多个客户或租户。每个租户将要使用适当的身份提供者进行身份验证。例如，企业用户会希望我们自己的企业资格证书，而租户的消费者和客户可能希望使用自己的社会身份凭证。

这种模式可能不适合于下列情况：

应用程序的所有用户都可以通过一个标识提供者进行身份验证，并没有要求使用任何其他身份提供者进行身份验证。这是典型的只使用企业目录进行身份验证业务应用，并获得该目录可在应用程序中直接使用VPN，或（在云中托管的情况下），通过导通之间的虚拟网络连接本地目录和应用程序。
应用程序最初建使用不同的认证机制，或许与自定义用户存储，或者不具有处理所用的权利要求为基础的技术的协商标准的能力。改造基于声明的身份验证和访问控制到现有的应用程序可能很复杂，可能不符合成本效益。

例子

组织举办了多租户软件即在 Azure 中的服务（SaaS）应用程序。该应用程序 incudes 一个网站，租户可以用它来管理应用程序为自己的用户。该应用程序允许租户使用由活动目录联合服务（ADFS）产生的，当用户通过该组织自己的 Active Directory 身份验证的联合身份访问租户的网站。图2示出了该过程的概述。

图2 - 用户如何在大型企业用户访问应用程序

在图 2 所示的场景中，商户验证自己的身份提供者（步骤1），在这种情况下 ADFS。在成功验证租客，ADFS 发出的令牌。客户端浏览器转发此令牌至 SaaS 应用的联合提供者，其信任的租户的 ADFS 发出令牌，以便取回的令牌是有效的 SaaS 的联合提供者（步骤 2）。如果有必要，在 SaaS 联合会提供商上执行令牌中的权利要求书的权利要求到该应用程序识别的新令牌返回给客户机浏览器之前（步骤3）的变换。应用程序信任的 SaaS 的联合提供者发出的令牌，并使用在令牌中的权利要求书申请授权规则（步骤 4）。

租户将不再需要记住不同的凭据来访问应用程序，以及管理员租户的公司将能够在自己的 ADFS 配置可以访问应用程序的用户的列表。