Azure设计模式之联邦身份模式
联合身份模式
将身份验证职责交给外部标识提供程序。这样可以简化开发,并最大限度地减少用户管理的任务,提高了应用程序的用户体验。
问题背景
用户信息通常来自不同组织所提供的应用程序,来满足不同的业务需要。这些用户可能需要使用特定的(和不同的)凭据。这可能导致用户体验下降。当用户使用太多不同的登录凭据,有可能会忘记它们，也会暴露安全漏洞。当用户离开公司时,该帐户必须立即被注销。在大公司很容易忽略这一点。那里的用户管理很复杂。管理员管理所有用户的凭据,并还要执行其他任务,如提供密码过期提醒。用户通常倾向于为所有这些应用程序提供相同的登录凭据。
解决方案
实现一种能够使用联合标识的验证机制。将用户身份验证与应用程序分离,并将身份验证交给受信任的身份提供程序。这样能够简化开发,并使得用户能够使用更广泛的身份验证程序进行验证,同时也减少了管理开销。它还使得身份验证与授权分离。受信任的身份提供程序包括企业目录访问、企业内网身份验证、业务合作伙伴提供的安全令牌服务(STS),也可以集成公共身份验证服务，如微软，谷歌,雅虎,或脸书。
下图演示了当客户端应用程序需要访问身份验证服务时，联合身份模式的执行流程。身份验证由与STS协同工作的身份提供商联合完成。身份提供商生成安全令牌,提供身份验证的用户信息。此信息(称为"声明")包括用户标识,还可能包括其他信息,如角色以及更细粒度的权限信息。
此模型通常称为基于声明的访问控制。应用程序和服务根据标记中包含的声明授权对功能的访问。需要身份验证的服务必须信任身份验证提供商。客户端应用程序需要与执行身份验证的身份验证提供商联系。如果身份验证成功,身份验证提供商会返回一个标记,其中包含向sts标识用户的声明(请注意,身份验证提供商和sts可以是同一服务)。STS可根据预定义的规则在令牌的转换过程扩充声明,然后将其返回给客户端。客户端应用程序可以将此标记传递给服务作为其标识的证明。信任链中可能存在额外的STS。例如在后面描述的方案中,本地sts需要使用另一个STS通过身份提供商来进行身份验证。这种方法在企业应用中很常见,通常会有本地部署的STS和目录。
联合身份验证为跨不同域的信任身份问题提供了标准的解决方案,并且可支持单点登录。它在各种类型的应用程序(尤其是云托管应用程序)中越来越常见,因为它支持单点登录,而不需要直接连接到身份提供程序。用户不必为每个应用程序输入凭据。这会提高安全性,因为它可以防止为不同应用程序伪造登录信息,同时也会隐藏除原始身份提供程序之外的其他用户身份信息。应用程序只能看到已通过身份验证的标识信息。
联合身份验证还有一个优点,即身份和凭据的管理是身份提供商的责任。应用程序或服务不需要管理身份信息。此外,在解决方案中,如果公司目录选择信任身份提供商,则根本不需要了解该用户。这将降低用户标识的管理开销。
问题和注意事项
在设计联合身份验证的应用程序时,需要考虑以下事项:
身份验证可能是单点故障。如果将应用程序部署到多个数据中心,考虑将身份管理机制也部署到相同的数据中心,以维护应用程序的可靠性和可用性。
身份验证工具可根据身份验证令牌中包含的角色声明来对访问进行控制。这通常被称为基于角色的访问控制(RBAC),从而对功能和资源的访问进行更细化的控制。
与企业目录不同的是,使用社交身份提供商的基于声明的身份验证通常不提供经过身份验证的用户信息,往往只提供电子邮件地址,或者姓名。某些社交身份提供商(如Microsoft帐户)只会提供唯一的标识符。应用程序通常需要维护注册用户的一些信息,并且能够将此信息与令牌中声明所包含的标识符相匹配。通常,这是在用户首次访问应用程序时通过注册完成的,然后在每次身份验证后将此信息作为附加声明包含到令牌中。
如果为STS配置了多个用户标识提供商,则必须检测要将用户重定向到哪个身份提供商进行验证。这个过程主提供商查找。STS可根据用户提供的电子邮件或姓名、应用程序的子域、IP地址范围或用户浏览器中的cookie中内容自动执行此重定向操作。例如,如果用户在microsoft域中输入了电子邮件地址(如user@live.comuser@live),则STS会将用户重定向到"microsoft帐户登录"页。在以后的访问中,STS可以使用cookie来存储最后一个登录是使用Microsoft帐户。如果无法确定主域,则STS将显示一个主提供商选择页面,其中列出了受信任的身份提供商, 由用户自行选择。
何时使用此模式
此模式对于以下情况非常有用:
企业系统单点登录。在这种情况下,需要对在公司安全范畴之外的云托管应用程序的员工进行身份验证,而无需每次访问应用程序时都请求登录。这样一来就能保证用户的登录体验与使用企业内网应用程序相同,一旦登录就可以访问所有相关应用程序,而无需再次请求登录。
与多个合作商进行联合身份验证。在这种情况下,需要对在公司目录中没有帐户的员工和企业合作商一起进行身份验证。在b2b应用程序、第三方服务集成的应用程序，具有不同IT系统进行集成或共享资源的情况下，这种应用场景很常见。
软件即服务（SaaS）应用程序中的联合身份验证。每个软件供应商为不同客户或租户提供现成的服务。每个租户都使用各自的身份提供商进行身份验证。例如,企业用户使用公司内部的用户信息,而租户和客户可使用他们的社交账号身份凭证。
在下列情况下, 此模式可能不会有帮助:
应用程序的所有用户由统一的身份验证机制,并不需要使用任何其他用户身份提供商进行验证。这在传统应用程序中是常见的,它使用公司目录(在应用程序内可访问)进行身份验证、使用VPN或(在云托管方案中)通过内部目录之间的虚拟网络来访问应用.
应用程序最初使用了不同的身份验证机制构建的,例如自定义用户存储机制,或是不支持基于声明身份验证技术所使用的协商标准。将基于声明的身份验证和访问控制改造为现有的应用程序可能很复杂,而且也不具有成本效益。
例子
在Azure中,为多租户软件提供托管服务(SaaS)。应用程序包括一个网站,租户可以使用它来管理他们自己的应用程序。该程序允许租户通过由AD联合身份验证服务(ADF：Active Directory Federation)生成的联盟标识来访问网站,而用户是由自己企业内部的AD进行验证的。
该图显示了租户如何使用自己的身份提供程序(步骤1)进行身份验证,在此例中为ADF。在成功验证租户身份后,ADFS（ActiveDirectoryFederationService）会发出一个令牌。客户端浏览器将此令牌转发给某SAAS应用程序的身份信息提供商,它信任租户ADF颁发的令牌,返回SAAS应用身份信息提供商中的身份令牌(步骤2)。如有必要,SaaS身份信息提供商会将标记中的声明转换为应用程序识别的声明(步骤3),然后再将新的标记返回给客户端浏览器。应用程序信任SaaS应用身份信息提供商颁发的令牌,并使用令牌中的声明来执行授权规则(步骤4)。
租户无需记住所有身份凭据就可以访问应用程序,而租户公司的管理员可以在公司内部的ADF中配置可访问该应用程序的用户列表。
相关链接
微软Azure活动目录AD（https://azure.microsoft.com/services/active-directory/）
活动目录域服务ADFS（https://msdn.microsoft.com/library/bb897402.aspx）
活动目录联盟服务（https://msdn.microsoft.com/library/bb897402.aspx）
多租户程序在微软Azure中的身份管理（https://docs.microsoft.com/en-us/azure/architecture/multitenant-identity/）
在Azure中构建多租户程序（https://docs.microsoft.com/en-us/azure/dotnet-develop-multitenant-applications）
将身份验证职责交给外部标识提供程序。这样可以简化开发,并最大限度地减少用户管理的任务,提高了应用程序的用户体验。
问题背景
用户信息通常来自不同组织所提供的应用程序,来满足不同的业务需要。这些用户可能需要使用特定的(和不同的)凭据。这可能导致用户体验下降。当用户使用太多不同的登录凭据,有可能会忘记它们，也会暴露安全漏洞。当用户离开公司时,该帐户必须立即被注销。在大公司很容易忽略这一点。那里的用户管理很复杂。管理员管理所有用户的凭据,并还要执行其他任务,如提供密码过期提醒。用户通常倾向于为所有这些应用程序提供相同的登录凭据。
解决方案
实现一种能够使用联合标识的验证机制。将用户身份验证与应用程序分离,并将身份验证交给受信任的身份提供程序。这样能够简化开发,并使得用户能够使用更广泛的身份验证程序进行验证,同时也减少了管理开销。它还使得身份验证与授权分离。受信任的身份提供程序包括企业目录访问、企业内网身份验证、业务合作伙伴提供的安全令牌服务(STS),也可以集成公共身份验证服务，如微软，谷歌,雅虎,或脸书。
下图演示了当客户端应用程序需要访问身份验证服务时，联合身份模式的执行流程。身份验证由与STS协同工作的身份提供商联合完成。身份提供商生成安全令牌,提供身份验证的用户信息。此信息(称为"声明")包括用户标识,还可能包括其他信息,如角色以及更细粒度的权限信息。
此模型通常称为基于声明的访问控制。应用程序和服务根据标记中包含的声明授权对功能的访问。需要身份验证的服务必须信任身份验证提供商。客户端应用程序需要与执行身份验证的身份验证提供商联系。如果身份验证成功,身份验证提供商会返回一个标记,其中包含向sts标识用户的声明(请注意,身份验证提供商和sts可以是同一服务)。STS可根据预定义的规则在令牌的转换过程扩充声明,然后将其返回给客户端。客户端应用程序可以将此标记传递给服务作为其标识的证明。信任链中可能存在额外的STS。例如在后面描述的方案中,本地sts需要使用另一个STS通过身份提供商来进行身份验证。这种方法在企业应用中很常见,通常会有本地部署的STS和目录。
联合身份验证为跨不同域的信任身份问题提供了标准的解决方案,并且可支持单点登录。它在各种类型的应用程序(尤其是云托管应用程序)中越来越常见,因为它支持单点登录,而不需要直接连接到身份提供程序。用户不必为每个应用程序输入凭据。这会提高安全性,因为它可以防止为不同应用程序伪造登录信息,同时也会隐藏除原始身份提供程序之外的其他用户身份信息。应用程序只能看到已通过身份验证的标识信息。
联合身份验证还有一个优点,即身份和凭据的管理是身份提供商的责任。应用程序或服务不需要管理身份信息。此外,在解决方案中,如果公司目录选择信任身份提供商,则根本不需要了解该用户。这将降低用户标识的管理开销。
问题和注意事项
在设计联合身份验证的应用程序时,需要考虑以下事项:
身份验证可能是单点故障。如果将应用程序部署到多个数据中心,考虑将身份管理机制也部署到相同的数据中心,以维护应用程序的可靠性和可用性。
身份验证工具可根据身份验证令牌中包含的角色声明来对访问进行控制。这通常被称为基于角色的访问控制(RBAC),从而对功能和资源的访问进行更细化的控制。
与企业目录不同的是,使用社交身份提供商的基于声明的身份验证通常不提供经过身份验证的用户信息,往往只提供电子邮件地址,或者姓名。某些社交身份提供商(如Microsoft帐户)只会提供唯一的标识符。应用程序通常需要维护注册用户的一些信息,并且能够将此信息与令牌中声明所包含的标识符相匹配。通常,这是在用户首次访问应用程序时通过注册完成的,然后在每次身份验证后将此信息作为附加声明包含到令牌中。
如果为STS配置了多个用户标识提供商,则必须检测要将用户重定向到哪个身份提供商进行验证。这个过程主提供商查找。STS可根据用户提供的电子邮件或姓名、应用程序的子域、IP地址范围或用户浏览器中的cookie中内容自动执行此重定向操作。例如,如果用户在microsoft域中输入了电子邮件地址(如user@live.comuser@live),则STS会将用户重定向到"microsoft帐户登录"页。在以后的访问中,STS可以使用cookie来存储最后一个登录是使用Microsoft帐户。如果无法确定主域,则STS将显示一个主提供商选择页面,其中列出了受信任的身份提供商, 由用户自行选择。
何时使用此模式
此模式对于以下情况非常有用:
企业系统单点登录。在这种情况下,需要对在公司安全范畴之外的云托管应用程序的员工进行身份验证,而无需每次访问应用程序时都请求登录。这样一来就能保证用户的登录体验与使用企业内网应用程序相同,一旦登录就可以访问所有相关应用程序,而无需再次请求登录。
与多个合作商进行联合身份验证。在这种情况下,需要对在公司目录中没有帐户的员工和企业合作商一起进行身份验证。在b2b应用程序、第三方服务集成的应用程序，具有不同IT系统进行集成或共享资源的情况下，这种应用场景很常见。
软件即服务（SaaS）应用程序中的联合身份验证。每个软件供应商为不同客户或租户提供现成的服务。每个租户都使用各自的身份提供商进行身份验证。例如,企业用户使用公司内部的用户信息,而租户和客户可使用他们的社交账号身份凭证。
在下列情况下, 此模式可能不会有帮助:
应用程序的所有用户由统一的身份验证机制,并不需要使用任何其他用户身份提供商进行验证。这在传统应用程序中是常见的,它使用公司目录(在应用程序内可访问)进行身份验证、使用VPN或(在云托管方案中)通过内部目录之间的虚拟网络来访问应用.
应用程序最初使用了不同的身份验证机制构建的,例如自定义用户存储机制,或是不支持基于声明身份验证技术所使用的协商标准。将基于声明的身份验证和访问控制改造为现有的应用程序可能很复杂,而且也不具有成本效益。
例子
在Azure中,为多租户软件提供托管服务(SaaS)。应用程序包括一个网站,租户可以使用它来管理他们自己的应用程序。该程序允许租户通过由AD联合身份验证服务(ADF：Active Directory Federation)生成的联盟标识来访问网站,而用户是由自己企业内部的AD进行验证的。
该图显示了租户如何使用自己的身份提供程序(步骤1)进行身份验证,在此例中为ADF。在成功验证租户身份后,ADFS（ActiveDirectoryFederationService）会发出一个令牌。客户端浏览器将此令牌转发给某SAAS应用程序的身份信息提供商,它信任租户ADF颁发的令牌,返回SAAS应用身份信息提供商中的身份令牌(步骤2)。如有必要,SaaS身份信息提供商会将标记中的声明转换为应用程序识别的声明(步骤3),然后再将新的标记返回给客户端浏览器。应用程序信任SaaS应用身份信息提供商颁发的令牌,并使用令牌中的声明来执行授权规则(步骤4)。
租户无需记住所有身份凭据就可以访问应用程序,而租户公司的管理员可以在公司内部的ADF中配置可访问该应用程序的用户列表。
相关链接
微软Azure活动目录AD（https://azure.microsoft.com/services/active-directory/）
活动目录域服务ADFS（https://msdn.microsoft.com/library/bb897402.aspx）
活动目录联盟服务（https://msdn.microsoft.com/library/bb897402.aspx）
多租户程序在微软Azure中的身份管理（https://docs.microsoft.com/en-us/azure/architecture/multitenant-identity/）
在Azure中构建多租户程序（https://docs.microsoft.com/en-us/azure/dotnet-develop-multitenant-applications）