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.

云场景

未完待续......