全新的membership框架Asp.net Identity(2)——绕不过的Claims

原本想直接就开始介绍Identity的部分，奈何本身挖坑太深，高举高打的方法不行。只能本身默默下载了Katana的源代码研究了好一段时间。发现要想可以理解好用好Identity, Claims是一个绕不过的内容。今天就和你们一块儿分享一下什么是Claims以及为何Identity要基于Claims.

阅读目录:

一. 什么是Claims以及基于Claims的identity验证

二. 使用基于Claims的Identity验证的优点

三. Claims是如何应用在Asp.net中?

四，一些更深刻的补充说明

一，什么是Claims以及基于Claims的identity验证

实际上，基于Claims的identity验证早已经被应用到咱们生活中的不少方面。一个很是典型的例子就是咱们到机场登机的过程。咱们乘坐飞机，是不可以直接直接拿着机票和身份证就上飞机的，须要先到柜台上领登机牌. 到了指定柜台上，出示身份证和机票，办理物品托运，选好座位，确认后，才能换取登机牌。这个时候你才能凭借登机牌过安检和上飞机。

登机过程当中，工做人员扫一下这个小小的登机牌，就能获取到不少信息: 好比，你已是通过航空公司认证过的乘客，你的航班号，座位号，你的名字等。工做人员只要核对这些信息，就会容许你上对应的飞机和指定的座位。

以Claims的角度从新看待登机过程

OK. 咱们再来捋一捋这个过程，用Claims的角度来从新描述和整理一下。

首先Claim就是一个描述. 这个例子中, 包含在登机牌上的一个一个信息，就是一个一个Claim. 这些Claims是这样的:

乘客的名字叫Justrun

乘坐的航班是MF8858

座位号是34J

............................

全部上面的Claims就组成了Identity, 也就是登机牌。这个登机牌是基于Claims的。

这个登机牌是通过航空公司的工做人员验证后，发给个人，那么发行者航空公司就是Issuer。

登机的时候，工做人员看到你的登机牌就会放行的缘由是， 他信任这些Claims, 由于这些Claims的Issuer是trust的(航空公司)。比对完这些Claims，若是你登机的航班正确，就会让你登机。

二，使用基于Claims的Identity验证的优点

看起来上面的过程好像很是麻烦，不是吗? 为何不就拿着身份证和机票直接登机，不是更加方便乘客吗?

它的好处就是简单的隔离了验证(Authentication)和受权(authorization)两个部分，但这也是它最大的优点。

想一想看，若是咱们没有了登机牌会是一个什么景象。工做人员要在飞机门口摆上设备，验证你的机票和身份证信息，给你办理行李托运，而后让你选座位........ 简直就不可想象。

有了登机牌, 验证就由航公公司来作，航空公司负责验证和发放登机牌，空姐就只须要查看你的登机牌，让你登机并决定你有没有权限座头等舱。

有了Claims Identity, 那么建立Claims Identity就能够由多种多样的验证过程来作，好比能够经过用户名密码，Active Direcity, 第三方登陆(Google, Facebook，QQ，微博等)，而咱们的程序就主要根据Claims Identity来判断用户是否可以使用咱们的系统，以及决定用户可使用和不能使用系统中的那些功能。

这样，验证就彻底和应用程序分开，开发应用程序的时候，只要咱们使用的是基于Claims的Identity验证，就不用担忧之后验证方式的的扩展和修改。

三，Claims是如何应用在Asp.net中?

在Visual Studio 2013中，建立一个Asp.net MVC项目。这个默认的Asp.net MVC项目中，权限验证默认使用的是CookieAuthentication。

app.UseCookieAuthentication(new CookieAuthenticationOptions
{
     AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
     LoginPath = new PathString("/Account/Login"),
     Provider = new CookieAuthenticationProvider
     {
          // Enables the application to validate the security stamp when the user logs in.
          // This is a security feature which is used when you change a password or add an external login to your account.  
          OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<ApplicationUserManager, ApplicationUser>(
          validateInterval: TimeSpan.FromMinutes(30),
          regenerateIdentity: (manager, user) => user.GenerateUserIdentityAsync(manager))
      }
});  

启动网站，可以看到常规的登陆注册流程。当咱们要访问受保护的页面的时候，会转到登陆页面上。

如今咱们在这个默认的MVC项目中作个小试验，不经过注册，登陆，直接写入伪造的Claims信息来经过验证。

首先，咱们在ManageController上，添加一个ProtectedPage页面，因为ManageController整个Controller都添加上了[Authorize]，因此默认ProtectedPage是须要登陆以后才能访问的。

public async Task<ActionResult> ProtectedPage()
{
    return new ContentResult { Content = "This is a protected Page" };
}

直接敲入网址，http://localhost:4572/Manage/ProtectedPage , 和咱们的预期同样，直接转到了登陆页面。

接下来，是咱们的重头戏，咱们将给本身伪造Claims, 骗过Authentication, 得到访问ProtectedPage的权限。

在HomeController上，建立一个AddClaim页面，伪造Claims的过程以下:

public ActionResult AddClaim()
{
     var claims = new List<Claim>//建立咱们的Claim
     {
           new Claim(ClaimTypes.Name, "Peter"),
           new Claim(ClaimTypes.Email, "justrun_test@outlook.com")
     };
     var identity = new ClaimsIdentity(claims, DefaultAuthenticationTypes.ApplicationCookie);//构建ClaimsIdentity
     var ctx = Request.GetOwinContext();
     var authenticationManager = ctx.Authentication;//经过OWIN Context获取咱们的Authentication Manager
     authenticationManager.SignIn(identity);
     return Content("Login Success");
}

　　访问AddClaims页面，看看效果。

 

咱们的AddClaims起到效果了，经过人为的添加Claims信息，咱们顺利的获得了访问ProtecedPage的权限。

 四，一些更深刻的补充说明

1. AuthenticationMiddleware如何判断用户是不是合法用户的?

ClaimIdentity至关因而登机牌，也就是咱们的系统的通行证。构建的ClaimIdentity，最后会经过加密的方式，转换成加密字符，保存到Cookie中。Authentication中间层会经过检查用户Cookie中是否有ClaimIdentity，来判断当前访问的用户是不是合法用户。

2. 谁是Issuer?

在上面的例子中，Issuer就是咱们本身，在AddClaims Action中，咱们直接构造了CliamIdentity. 若是使用传统的用户名，密码登录的方式的话，当验证经过，也是一样构造ClaimIdentity, 只是上面的例子中，咱们跳过了这步。

在Katana中，还有FacebookAuthenticationMiddleware, GoogleAuthenticationMiddleware等实现，它们是Issuer就分别是Facebook和Google. 以FacebookAuthenticationMiddleware为例子，当FacebookAuthenticationMiddleware检查Cookie，发面没有ClaimIdentity，就会转到Facebook，要求提供Facebook帐号信息。当用户登陆Facebook帐号，赞成受权给咱们的站点该用户Facebook信息。这个时候FacebookAuthenticationMiddleware根据这些信息，构造CliamIdentity。

3. 补充阅读:

想更多的了解OWIN以及Katana，能够看看下面这些文章

OWIN产生的背景以及简单介绍

Katana介绍以及使用

OWIN Middleware

了解更多细节，能够直接down源码:

Katana源码: https://katanaproject.codeplex.com/SourceControl/latest#README

Asp.net Identity源码: https://github.com/aspnet/Identity/tree/dev/src/Microsoft.AspNet.Identity