联合身份模式——云计算架构常用设计模式

背景

    在一个系统当中，可能集成了多个应用程序，而这些应用程序由一些有商业联系的组织提供和托管。但是对于使用者来说，他们可能会面临着被强迫使用不同凭证的问题，这将导致以下问题：

• 糟糕的用户体验：对用户来说，使用多个不同的凭证意味着更多的操作复杂性；
• 暴露安全漏洞：对用户权限的管理更加复杂；
• 复杂的用户管理：管理员必须管理所有用户的凭证，提高了管理难度。

目的

    联合身份模式是指将身份验证委托给外部的身份验证提供商的模式。此模式能够简化开发，最小化账户管理，并提高用户体验。

解决方案

方案：采用联合身份认证机制，将身份认证从应用程序代码中分离出来，并将身份认证委托给一个可信的身份验证提供商。
好处：做可以大大简化开发，并运行用户使用更加广泛的身份验证提供商，来最小化管理开销。
身份验证商：可以是公司内部联合服务、其他商业伙伴提供的安全令牌服务(STSs)，或者一些能够验证用户的社交身份提供商，如Google、Microsoft、阿里的账户。

其中，身份提供商下发一个安全令牌，该令牌声明了一个已经授权的用户信息，称为声明。它可以包括个人信息及更加详细的信息。这个模型通常称为基于声明的访问控制。
联合身份认证提供了一种基础标准解决方案，其主要有以下优点：

• 可以用来应对跨域身份认证的问题，也可以支持单点登陆。
• 增加安全性：它防止了访问不同应用程序时带来的凭证扩散，还隐藏了来自所有原始的身份提供商的凭证，使得应用程序仅能看到包含在令牌当中的已认证的身份信息；
• 应用程序或服务无需提供身份管理功能，消除了管理用户的所有开销。

考虑因素

• 认证可以是单点失效的：当应用程序部署到多个节点时，身份认证机制也应该部署到多个节点，以便维护应用程序的可靠性和可用性；
• 认证机制可以提供访问控制工具，它基于包含在认证令牌中的角色声明，这通常称为基于角色的访问控制(RBAC)，它允许更精细的控制访问特性；
• 与企业目录不同，使用社交身份提供商基于声明的认证通常不提供除电子邮件和名字以外的授权用户信息，而是仅提供一个唯一标识符。因此，应用程序当中需要额外维护用户信息，然后将这些信息同令牌中的标识符匹配。这一工作通常在用户第一次注册时进行初始化，并将信息作为日外的声明注入令牌当中。
• 如果为安全令牌服务配置了多个身份提供商，则需要先检测用户应该重新定向到那个省份提供商进行身份验证。

适用情况

• 企业中的单点登陆：当用户登陆到企业网络时，首先进行身份验证，而之后访问企业每部的其他应用程序则无需再次进行身份验证；
• 和多个伙伴联合身份认证；
• 在软件即服务中联合身份认证。