很多时候，我们进行应用程序之间的交互。比如，一个员工登录了门户网站后，需要访问进销存系统、CRM系统，如果不进行特殊处理，就需要多次输入用户名和密码。用过SharePoint的朋友，可能知道有个“单点登录”的东东是用来解决这个问题的。单点登录并不完美，其中之一就是它将用户名和密码存成明文，一个程序员可能很容易的获得某个用户的用户名和密码，这在涉密的软件中简直是致命的缺陷。
因此，人们开始重新思索一种更可靠，更实用的认证方式。这时，Claims认证闪亮登场了。其实，Claims认证早就出现了，大概已经有10年的历史了，但是一直没有发扬光大。这次可以说是老树发新芽，Claims认证迎来了第二春。
Claims认证很难解释清楚，甚至我都找不到一个合适的中文词语来翻译它。只好用一个比喻来说明。
在实行社保卡之前，我们去医院看病的时候，需要拿着身份证去办理一张就诊卡，办卡的工作人员校验完你的身份证以后，会将你的个人信息录入到卡里面。当你去找医生就诊的时候，医生扫描一下你的就诊卡，就知道了你的所有信息。这个就诊卡就相当于Claims认证中的token,里面的每条信息就是一个Claim.
这里的就诊卡具有两个特点：（1） 里面包含了认证过的信息，也就是说，医生看到这些信息以后，不需要再去看你的身份证进行验证。(2) 医生需要验证发行者，也就是读磁条的过程。医生一旦确认这个就诊卡是由办卡的工作人员签发的，就可以信任里面的信息。
以上两个特点就是Claims认证区别于其他认证方式的两点。
就诊卡对应Claims认证里面的token,就诊卡里面的每条信息对应Claims认证里面的claim.而办卡的工作人员就是token的发行者。
一个token里面包含用户名，用户email,用户的manager的email等信息。使用claims认证时，很难扩展上面的属性。这就像你使用医院的就诊卡时，上面应该包含什么信息，是由医院软件决定的，如果你自己想增加一个别的属性，必须去改变医院的软件，这通常是很难得。所以尽量使用当前token中包含的属性，不要奢望去使用里面不包含的属性。除非你是卫生部长或者医院院长:(
Claims认证中有一个很重要的角色“发行者(Issuer)”，对于上面的例子，医院就是cliaims token的发行者。如果在我们自己的应用程序中想要使用claims认证，下面的元素是必不可少的。
我们分析一下我们需要做的事情：一个是Application,就是我们的应用程序，在里面我们要解析Claims token,得到里面包含的信息，这个很容易做到，因为.net framework提供了一些标准的方法;另一个是Issuer，它的作用是验证用户，然后将用户的信息制作成security token发送给我们的Application,这个如果我们自己来做会相当复杂，幸运的是，微软提供了一个标准的Issuer的组件：ADFS.
ADFS存在于windows server 2008 R2企业版中，全称为Active Directory Federation Services (ADFS) 2.0. ADFS支持多种用户认证方式，比如Kerbos,form验证等，它还支持SQL语句，这样可以从自定义的SQL数据源中提取用户信息。
Claims认证的其中优点之一是:比如你有很多个用户具有相同的权限，那么对于这些用户，只需要根据他们的角色产生一个claims token,而没有必要产生很多个token,这就大大减少了Application需要处理的认证的数量。
Claims 认证的具体实施步骤：
1. 在你的Application中加入逻辑用以支持Claims.
其中包括验证来自Issuer的token和解析token以便获得Claims信息。Windows Identity Foundation (WIF) 提供了标准的API,这些API既可以在WCF中使用，也可以在ASP.NET程序中使用。使用WIF的方法很简单，只需要在你的程序中引入Microsoft.IdentityModel.dll就可以了，举一些例子：IsInRole， Identity.Name， Identity.Claims等等。
2。 构建一个Issuer。
这个使用ADFS就可以了。具体的配置步骤查看ADFS的文档即可。当然，你也可以使用WIF自己构建一个Issuer,那会非常的复杂。
3。 配置你的Application,使之信任你的Issuer。
这种信任关系式必须建立的，就像医生必须信任办就诊卡的人员一样。
这里的关键是一个叫做“集成元数据(federation metadata)”的概念，它是一个Xml文档，这个Xml文档由Issuer提供给你的Application, 包含Issuer的证书，Issuer提供给Application的信息列表，Application用来去获得token的Url和其他一些技术细节，你把它想象成就诊卡上的磁条好了。
WIF提供了一个标准的向导，可以自动根据这个Xml文档包含的元数据省生成你的Application的认证设置，你只需要提供给Issuer的Url,WIF会自动下载这些元数据并且配置你的Application.
4. 配置Issuer使它知道你的Application.
Issuer需要知道关于Application的如下信息：
- Application的URL.
- Claims提供的属性中，哪些是必须的，哪些是可选的
- 是否需要对产生的token加密，用什么key来加密。
- Application暴漏出来用以接收token的URL.
WIF提供了一个工具edUtil.exe，可以用以生成一个元数据文档，所以你无需手动进行配置。
版权声明：本文原创发表于 博客园，作者为 今夜太冷
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则视为侵权。
