Claim-Based Identity for Windows: Technologies and Scenarios

Active Diretory Federation Services 2.0

基于申明（Claim-Based）的身份验证：场景介绍

在开始使用基于申明（Cliam-Based）身份验证之前，首先得理解这个技术的基本原理。最好的方式就是通过例子来理解它是如何运作的。因此，本节将讨论一些不同的方法，这些方法可以在前面提及的云计算中使用，每个说明都使用了刚刚描述的Microsoft技术。

ON-Premises Scenrios（本地情景）

Claim-Based首先是用来解决内部企业之间的问题。这项技术至今仍被广泛应用，所以我们有必要了解其内部场景。本节将举三个例子:

• 访问一个STS提供者企业应用程序，所有用户都有相同的组织机构.
• 让我们来拓展情景1，在网页上访问这个企业应用程序，并且这些用户没有在规定的组织机构
• 企业应用程序使用联合身份标识验证，其中一个组织的用户去访问应用程序中另一个组织的用户

Accessing an Enterprise Application（访问企业应用程序）

现在大多数企业应用程序都扮演着身份验证提供者的角色，近乎每个企业必定会处理身份验证方面的问题。 那些运行在内部组织机构的应用程序的AD FS 2.0（Active Directory Federation Services）和 WIF（Windows Identity Foundation）为本地（on-premises）Claim-Based身份标识验证程序提供基础，下图说明了这些 在这个例子中，一个用户使用ADFS登录，获得一个Kerberos ticket(step1)，然后用户访问用WIF构建的基于声明应用程序，尝试得到这个应用程序（STS）的信任(step2)。这个应用程序服务器只信任自己的企业，并且用户的浏览器和客户端从STS请求一个token，提供一个Kerberos ticket来对用户进行授权(step3)。ADFS2.0作为一个身份标识验证提供验证的STS，验证这个ticket然后在ADFS中查找这个需要新建一个请求Token的信息(step4)。确切的说，这个token中的声明信息依赖于请求应用程序的用户以及用户访问的应用程序——每一个应用程序都能表明所需要的申明信息。一旦token被创建，ADFS2.0 STS 就会把它回传到用户的客户端或者是浏览器(step5)，接着客户端就会提交这个token到WIF应用程序(step6). 然后这个应用程序会用WIF验证token的签名信息以及使用户的声明信息有效(step7)。

基于声明的方法的一大优点值得在这里重新强调(re-emphasizing)：不需要去查询有关用户的信息，它可以将所有的信息都交给token。如果应用程序需要，比方说，用户的工作标题，它可以在它的要求声明列表中指定它。 当STS给application创建token时，在ADFS中它会发现user的工作标题，并且插入到声明(Claim)中给application使用。没有这些，那么开发者必须编写自己的代码来从ADFS挖掘这些信息。基于声明的身份验证能够使开发者更加轻松。

通过Internet访问企业应用程序

假设某个公司希望通过互联网使本地应用程序访问远端员工。有一种传统的解决方案是通过修改应用程序去接收用户名/密码去登录，同样也能用基于声明的方法来做到，应用程序无需做任何更改。如下图所示：

在这里，用户在公司外的另一台计算机上。与之前一样，访问application得到sts授权(step1)。application同样也只信任自己企业，因此用户的浏览器或客户端请求来自该STS的一个令牌(token)。STS使用了ADFS2.0实现了STS验证用户并返回一个token(step2)。然后拿到token的用户浏览器或客户端提交给application(step3)。application依赖WIF包括使用Claims来验证token是否合法。

不需要让application针对不同的访问来实现不同的处理身份消息，基于声明的方法能解决这种情况，就像在公司内部的情况一样。当然，这也相当对的带来了一些复杂性。当在第二步获取token的时候，比如，STS如何验证自己的身份深吸呢？Kerberos tickets只在企业内部使用，在之前的图7说明，它们不会再网络上工作。而是用户在她的请求中附带username和password。这在微软的ADFS2.0中支持是可选的。由于在这个例子中，用户(User)是雇员，它们在ADFS中已经存在账户，所以毫无疑问的能登录。

但是，如果users他们不是雇员呢？假设application通过网络向客户公开。那么这种方法是否还能工作？答案当然是可以的。尽管它不是一个通用的选择，外部用户的信息也能存储在ADFS中，能被ADFS访问。

但是，尽管如此：如果在网络上，用户还是要需要user/password，那么claims-based方法还能很好的处理么？一个重要的改进是，它将每个应用程序从需要存储敏感密码信息的需要中解放出来 而不是将这些职责转移到更小的sts。所以，用户不在需要在每个application提交username/password，它会使这个”世界”更加简单化与安全。

在其他机构组织中为企业提供单点登录

另一个相同的身份验证就是用户在一个组织中访问过application，那么在其他组织也能正常运行。例如，假设你公司希望做一个内部共享平台网站去给合作伙伴的员工访问。一种方式就是给他们每一个账户和密码并存到自己的公司系统中。这能行，但是方案不吸引人。那些员工不愿意单独去登录，并且你们公司自己的管理员也不愿意管理公司外部的人的用户信息。而且这个方案也存在安全隐患——你公司的管理员是如何知道这写用户何时会离开他的公司，那么他就应该注销账户。

一个好的解决方案就是让这些外部用户用他们自己的身份信息访问你们的系统。这个方案不在要求要新的账户去单独登录，还要要求什么呢，它需要在你们公司和合作伙伴公司建立一个关系。这样做需要两个组织之间达成某种商业协议，这方面超出本节讨论的范围，不展开说明。当然，还需要用正确的技术。

一种方法是配置运行在一个组织机构中的应用程序(application)信任另一个sts提供者。如图9所示

在这个场景下，在X企业的用户访问Y企业的application应用程序，并且得到stss许可(step1)。在这里，这个应用程序被配置都信任自己的STS(一个是企业Y)和企业X的身份标识验证提供者STS。他们这些用户都被要求要在自己的STS申请token(step2)。然后提交给application(step3)。这个应用程序通过WIF验证用户的传过来的token以及包含的声明内容(Claims)，然后用他喜欢的方式去使用那些声明内容。

这个解决方案很好理解，但并不是没有任何问题。例如，假设此应用程序在多个不同的企业中有用户。那么根据上述描述的方法，这个应用程序将要配置信任每个企业(类似于配置白名单)，这明显非常繁琐。这就引出了另一个解决方案——联合身份标识验证(Federated Identity)。这意味着application要信任自己的STS，这为构建和管理此应用程序的人员生活变得简单。图10展示了具体细节。

这个场景在最开始的时候跟之前是一样的：企业X的用户访问企业Y的应用程序Y并获得STS许可。然而，这次应用程序Y被配置只信任自己的STS，也就是企业Y。确定了这点，用户系统上的客户端或者浏览器就会联系企业Y中的STS，并获得它信任的STS(step2)。这里，STS扮演着联合身份提供者的角色，并且被配置信任企业X中的STS。因此，用户客户端或者浏览器请求一个来自企业XSTS中的Idp token(step3)，企业X中的STS是身份验证提供者的角色。

然而由于应用程序Y只信任自己的STS发布的token从而不会接受这个Idp token。相反，用户的浏览器或客户端将idp token提交给联合身份验证提供器STS Y(step4)。因为这个STSY是被配置过企业X入白名单的，企业Y的STS验证收到由企业X发出的token，然后验证通过发布一个FP token回传给用户并通知用户允许访问应用程序Y(step5)。用户向应用程序展示令牌(step6)，应用程序通过WIF验证这个token和Claims的准确信息。应用程序现在可以像往常一样使用这些声明(step7)。

注意在企业Y中联合身份提供器STS是转换声明的作用，接收STS X发布的token，然后生成一个自己的token。这个STS Y生成的token内容很可能跟收到的来自STS X的token不同——token Y可以自由添加，删除，修改声明。实际上，ADFS2.0为那些管理员为那些转换定义规则提供一个相当复杂的方式。甚至可以在必要的时候禁止发布令牌。

还要注意到application是如何方便的从token中直接获取它所需要的信息。当用户和application都在相同的组织时，ADFS还能访问用户，获取如用户工作标题等信息。而在不同组织企业下时，就像这种场景展示的一样，application大多数时候是不允许方法的。从用户的令牌中获取所需的一些信息都是非常好的。

还有最后一个问题值得讨论：上面的step2，联合提供器STS将用户的浏览器或客户端定向到身份提供器STS。但是如果联合提供者STS有多个信任的身份提供者，那么它是如何知道把用户的信息发送给那个身份提供者？伴随这个问题的的出现，这里有一些解决方案。第一，ADFS支持这个选项，向用户提供一份可能性列表，让它选择它认可的组织。另一个选择是让用户提供电子邮箱，然后让联合提供者从她的身份提供者的地址域名获知身份信息。无论如何，身份联合需要以某种方式解决这个问题（这里很绕口，不知道怎么翻译，故原文如下：

One option, which AD FS 2.0 supports, is to present the user with a list of possibilities, letting her choose the one she recognizes as her own organization. Another option is to have the user provide her email address, then let the federation provider STS infer her identity provider from the address’s domain name. However it’s done, using identity federation typically requires solving this problem in some way.

云场景

本地场景很重要，但是大多数应用程序都是运行在云上的。使用Claims-Based身份标识能够让开发者和用户变得非常简单，再次重申：下面说的几种可能：

• 当访问云上的应用程序，用户和身份提供者STS是都在企业中，但是应用程序是在云上运行的。
• 通过云身份联合认证，它通过在云上添加联合提供者STS拓展了第一种情况
• 使用基于云的联合多身份验证，在云上应用程序通过基于云的联合提供者STS去接收多身份提供者STSs发布的身份信息。

云应用程序的单点登录

假设开发者想在云平台上构建一个应用程序，比如像Windows Azure或者是Amazon Web Service，然后让自己企业的用户能够使用它。或者假使让已经存在本地环境的应用程序迁移到云平台上。那么用户如何才能不需要账号密码在单独的登录一次就能访问应用程序被？

一种方法是配置应用程序相信企业身份提供者STS，如图11所示：

这个场景并不新鲜；实际上它跟图7展示的第一个场景相似。在那个例子中，用户访问应用程序并得到STS的许可(step1)，然后从STS获得一个token(step2)。尽管在这个图中没有表示出来，用户很有可能在STS中给自己授权，通过 Kerberos ticket，如图7所示那样。用户拿到从STS身份提供者的token，他的浏览器或客户端就会把token提交给应用程序(step3)。应用程序则通过WIF处理并验证token，通过之后就能想平常使用声明内容了。

从用户的角度讲，这就看起来像访问一个本地应用程序。因为应用程序被配置相信X企业的STS身份提供者，这里不需要身份联合验证。这个例子能够很好的应用在单个企业的云上应用程序

在SaaS应用程序上的单点登录

在图10所示的身份联合验证场景中，联合提供程序STS在被访问的应用程序中运行在相同的组织内。然而，这不是必须的。只要应用程序相信联合提供者STS，那么STS就能运行——甚至在云上。

Windows Azure AppFabric访问控制正是这样：一个运行在云的联合提供者STS，它能在本地环境和云上都能被应用程序使用，有趣的是在我们现在的ACS场景中都是基于云的应用程序。举个例子，假设一个SaaS应用程序希望给为不同公司组织的用户提供单点登录功能，由于每一个公司都有自己的身份提供者程序。那么它就将被配置成信任每一个公司来解决这个问题。一个更好的解决方案就是用ACS。图12显示了一个组织和多个组织是如何互操作的。

虽然着看起来有一点点差异，其实这就是联合身份验证的另一个例子。让我们来一步一步的看发生了什么：

• 最开始，用户访问应用程序并且应用程序只由ACS提供的联合身份验证提供者STS的信任(step1)
• 用户的浏览器和客户端连接到那个从STS列表中获得受信任的那个STS，而这个列表中就包含企业X中的STS(step2)
• 浏览器或者客户端从身份提供者STS获取一个token，这里是用ADFS2.0实现的
• 浏览器或客户端发送token到ACS STS(step4)
• ACS STS验证这个idp token，然后通过ACS规则引擎生成一个FP token(step5)；这个新的Token可能有一些与原始的ADFS生成的token不同的申明内容；通常联合提供者STS能执行申明转换
• ACS生成FP Token之后会返回给浏览器和客户端(step6)；
• User拿到token发送给应用程序(step7)
• 应用程序通过WIF验证token，然后就可以使用其中的声明内容做想做的操作了(step8)

要注意对于云应用程序如何使用ACS作为联合提供者STS让开发变得简单。并不是配置许可每一个客户的身份提供者STS，因为它只许可ACS STS。因为ACS STS被明确的设计成处理这种联合场景，给各种身份提供者STS配置许可是很直接的。使用基于云的联合提供者STS也能让应用程序依赖于ACS提供的规则引擎，给它一个定义必要的声明转换的地方。而不是处理不同的身份提供者STS发布的不同的token，应用程序总是会获取一个相同格式的token，包含那些预期的声明(Cliams)。