ASP.NET 下的 Claims-based认证实现
说完什么是Claims-based认证之后，我们接下来就可以看看ClaimsIdentity以及ClaimsPrincipal这两个类，他们是.NET下Claims-based认证的主要基石。当然正如我们所想，他们继承了接口IIdentity和IPrincipal。
IIdentity封装用户信息
这个接口很简单，它只包含了三个最基本的用户身份信息。
IPrincipal 代表着一个安全上下文
这个安全上下文对象包含了上面的identity以及一些角色和组的信息,每一个线程都会关联一个Principal的对象，但是这个对象是属性进程或者AppDomain级别的。ASP.NET自带的 RoleProvider就是基于这个对象来实现的。
CalimsIdentity和ClaimsPrincipal
在System.Security.Claims命名空间下去，我们可以发现这两个对象。下面我们来做一个小例子，这个小例子会告诉我们这两个对象是如何进行认证和授权的。我们要做的demo很简单，建一个空的mvc站点，然后加上一个HomeController，和两个Action。并且给这个HomeController打上Authroize的标签，但是注意我们没有任何登录的代码，只有这个什么也没有的Controller和两个什么也没有的Action。
当然，结果也是可想而知的，我们得到了401页面，因为我们没有登录。
下面我们就来实现登录，这里的登录非常简单，我们手动去创建这个ClaimsIdentity和ClaimsPrincipal对象，然后将Principal对象指给当前的HttpContext.Current.User。
我们在Global.asax中添加了Application_AuthenticateRequest方法，也就是每次MVC要对用户进行认证的时候都会进到我们这个方法里面，然后我们就这样神奇的把用户给登录了。
当然，我们没有Home/Manager的访问权限，因为我们上面只给了用户Users的Role。 
现在大家知道ClaimsIdentity和ClaimsPrincipal是如何使用了么？这里要注意一下的是，我们没有设置IsAutheiticated为true，在.NET4.5以前，对于GenericIdentity只要设置它的Name的时候IsAutheiticated就自动设置为true了，而对于ClaimsIdentity是在它有了第一个Claim的时候。在.NET4.5以后，我们就可以灵活控制了，默认ClaimsIdentity的IsAutheiticated是false，只有当我们构造函数中指定Authentication Type，它才为true。
转载自：http://www.cnblogs.com/zy-theone/p/5628663.html