首页 > 代码库 > 云计算设计模式(九)——联合身份模式

云计算设计模式(九)——联合身份模式

云计算设计模式(九)——联合身份模式

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

背景和问题


用户通常需要使用提供,并通过与它们商业关系的不同组织主持的多个应用程序一起工作但是,这些用户可能被迫使用特定的(不同的的凭证,每一个可以:
?原因脱节的用户体验用户经常忘记登录凭据时,他们有很多不同的的。
?暴露安全漏洞当用户离开公司帐户,必须立即取消设置这是很容易忽略这在大型组织中
?复杂的用户管理管理员必须管理凭据的所有用户,以及执行等方面提供密码提示的其他任务。

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

解决方案


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

可信身份提供者可能包括公司目录内部部署联合身份验证服务其他安全令牌服务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配置可以访问应用程序的用户的列表

本文翻译自MSDN:http://msdn.microsoft.com/en-us/library/dn589790.aspx

云计算设计模式(九)——联合身份模式