云计算设计模式（九）——联合身份模式
验证托付给外部身份提供者。这样的模式能够简化开发，最大限度地降低对用户管理的要求。并提高了应用程序的用户体验。
背景和问题
用户通常须要使用由提供，并通过与它们有商业关系的不同组织主持的多个应用程序一起工作。可是。这些用户可能被迫使用特定的（和不同的）的凭证，每个。这能够：
•原因脱节的用户体验。用户常常忘记登录凭据时，他们有非常多不同的的。
•暴露安全漏洞。当用户离开公司的帐户，必须马上取消设置。
这是非常easy忽略这在大型组织中。
•复杂的用户管理。
管理员必须管理凭据的全部用户。以及运行等方面提供password提示的其它任务。
用户会相反，通常期望使用同样的凭证用于这些应用。
解决方式
实现了能够使用联合身份的认证机制。
从应用程序代码中分离的用户身份验证和身份验证委派到受信任的身份提供者，能够大大简化开发。让用户使用更广泛的身份提供者（国内流离失所者），同一时候最大限度地降低管理开销进行身份验证。它也能够让你清楚地分离的授权认证。
可信身份提供者可能包含公司文件夹，内部部署联合身份验证服务。其它安全令牌服务（STS的）业务合作伙伴提供的。或社会身份提供者能够验证谁拥有用户。比如。微软，谷歌，雅虎或Facebook帐户。
图1示出了当client应用程序须要訪问要求身份验证的服务的联合身份模式的原理。该认证是通过身份提供者（IDP）。在演唱其工作与安全令牌服务（STS）的运行。境内流离失所者问题的主张有关身份验证的用户的信息安全令牌。
该信息被称为权利要求中，包含用户的身份，而且还能够包含其它信息，比如角色成员和更细粒度的訪问权限。
图1 - 联合身份验证概述
该模型通常被称为基于声明的訪问控制。应用程序和服务授权訪问基于包括在令牌中的权利要求的特征和功能。
要求身份验证必须相信国内流离失所者的服务。
client应用程序的联系人运行身份验证境内流离失所者。
假设认证成功，则的IdP返回包括用于识别用户于STS的权利要求书的令牌（注意的IdP和STS能够是同样的服务）。
在STS能够改变和增大中依据提前定义的规则。令牌中的权利要求书。将其返回到client之前。
然后，client应用程序能够将此令牌传递给服务作为其身份证明。
注意：
在某些情况下可能会有额外的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发出的令牌。
client浏览器转发此令牌至SaaS应用的联合提供者。其信任的租户的ADFS发出令牌，以便取回的令牌是有效的SaaS的联合提供者（步骤2）。假设有必要，在SaaS联合会提供商上运行令牌中的权利要求书的权利要求到该应用程序识别的新令牌返回给客户机浏览器之前（步骤3）的变换。应用程序信任的SaaS的联合提供者发出的令牌。并使用在令牌中的权利要求书申请授权规则（步骤4）。
租户将不再须要记住不同的凭据来訪问应用程序，以及管理员租户的公司将可以在自己的ADFS配置可以訪问应用程序的用户的列表。
本文翻译自MSDN：http://msdn.microsoft.com/en-us/library/dn589790.aspx