探索身份验证与授权
在这一小节中，我将阐述和证明ASP.NET 身份验证和授权的工作原理和运行机制，然后介绍怎样使用Katana Middleware 和 ASP.NET Identity 进行身份验证。
1. 理解ASP.NET 表单身份验证与授权机制
谈到身份验证，我们接触的最多的可能就是表单身份验证（Form-based Authentication）。为了更好的去理解ASP.NET 表单身份验证与授权机制，我搬出几年前的一张旧图，表示HttpApplication 19个事件，它们分别在HttpModule 中被注册，这又被称为ASP.NET 管道（Pipeline）事件。通俗的讲，当请求到达服务器时，ASP.NET 运行时会依次触发这些事件。
HttpApplication对象是由Asp.net帮助我们创建的，它是asp.net中处理请求的重要对象。为了便于扩展，HttpApplication采用处理管道的方式进行处理，将处理的步骤分为多个步骤，每个步骤通过事件的形式暴露给程序员，这些事件按照固定的处理顺序依次触发，程序员通过编写事件处理方法就可以定义一个请求的扩展过程。
对于HttpApplication，到ASP.NET 4.0,提供了19个标准事件。
1.BeginRequest：asp.net开始处理请求的第一个事件，表示处理的开始。
2.AuthenticateRequest：验证请求，一般用来取得请求的用户信息。
3.PostAuthenticateRequest：已经获取请求的用户信息。
4.AuthorizeRequest：授权，一般用来检查用户的请求是否获得权限。
5.PostAuthorizeRequest：用户请求已经获得授权。
6.ResolveRequestCache：获取以前处理缓存的处理结果，如果以前缓存过，那么，不用再进行请求的处理工作，直接返回缓存的结果。
7.PostResolveRequestCache：已经完成缓存的处理工作。
8.PostMapRequestHandler：已经根据用户的请求，创建了请求的处理器对象。
9.AcquireRequestState：取得请求的状态，一般用于session
10.PostAcquireRequestState：已经获得了session
11.PreRequestHandlerExecute：准备执行处理程序。
12.PostRequestHandlerExecute：已经执行了处理程序
13.ReleaseRequestState：释放请求的状态。
14.PostReleaseRequestState：已经释放了请求的状态。
15.UpdateRequestCache：更新缓存。
16.PostUpdateRequestCache:已经更新了缓存。
17.LogRequest:请求的日志操作
18.PostLogRequest：已经完成请求的日志操作。
19.EndRequest：本次请求处理完成。
HttpApplication事件管道处理过程简单描述见 :https://www.cnblogs.com/wfy680/p/12331836.html
身份验证，验证的是用户提供的凭据（Credentials）。一旦验证通过，将产生唯一的Cookie标识并输出到浏览器，来自浏览器的下一次请求将包含此Cookie。
对于ASP.NET 应用程序，我们熟知的FormsAuthenticationModule会对HttpApplication 的管道（Pipeline）事件AuthenticateRequest 进行注册，当请求经过ASP.NET Pipeline时，由ASP.NET Runtime 触发它，在该事件中，它会验证并解析该Cookie为对应的用户对象，它是一个实现了 IPrincipal接口的对象。PostAuthenticateRequest 事件在AuthenticateRequest 事件之后触发，表示用户身份已经检查完成 ，检查后的用户可以通过HttpContext的User属性获取并且HttpContext.User.Identity.IsAuthenticated属性为True。
如果将身份验证看作是"开门"的话，主人邀请你进屋，但这并不意味着你可以进入到卧室或者书房，可能你的活动场所仅限书房——这就是授权。在PostAuthenticateRequest事件触发过后，会触发AuthorizeRequest 事件，它在UrlAuthorizationModule 中被注册（题外插一句：UrlAuthorizationModule 以及上面提到的FormsAuthenticationModule你可以在IIS 级别的.config文件中找到，这也是ASP.NET 和 IIS紧耦合关系的体现）。在该事件中，请求的URL会依据web.config中的authorization 配置节点进行授权，如下所示授予Kim以及所有Role为Administrator的成员具有访问权限，并且拒绝John以及匿名用户访问。
- <authorization>
- <allow users="Kim"/>
- <allow roles="Administrator"/>
- <deny users="John"/>
- <deny users="?"/>
- </authorization>
通过身份验证和授权，我们可以对应用程序敏感的区域进行受限访问，这确保了数据的安全性。