ASP.NET生命周期中的驗證以及身份驗證子產品
前言：最近一直很忙，沒有來得及把之前的文章寫完，已經有不少朋友在給我留言催我了，很感謝朋友們的關注，也跟大家說聲對不起！
系列文章連結:
ASP.NET開發安全問題
ASP.NET安全問題－－ 建立安全的Web應用程式
ASP.NET安全問題－－ASP.NET安全架構
ASP.NET安全問題--ASP.NET安全架構－－如何實作.NET安全
ASP.NET安全問題－－ASP.NET生命周期中的驗證以及身份驗證子產品
ASP.NET安全問題－－Forms驗證的具體介紹(上篇)
ASP.NET安全問題－－Froms驗證的具體介紹(中篇)
ASP.NET安全問題－－Forms驗證(後篇)－－實戰篇
ASP.NET安全問題－－ASP.NET中的授權問題(前篇)
本篇主要一下話題：
1.ASP.NET運作的生命周期的驗證
2.身份驗證子產品
3.授權子產品
1.ASP.NET運作的生命周期的驗證
其實在ASP.NET中每一個請求都進行了驗證和授權的。進行驗證和授權的過程實際上是通過觸發相應的事件來完成的。
在講述驗證事件之前，首先清晰一個流程：ASP.NET運作時接到一個請求的處理的流程。
先把流程描述一下，使得大家有個總體把握：一個請求來了，經過IIS，通過ISAPI，就到達了ASP.NET的管道中，然後經過一些的轉化和包裝，然後ASP.NET運作時開始處理這個請求了,然後是進行驗證和授權，然後再進行一系列的處理，最後确定請求是是什麼檔案，如果是.aspx的，那麼然後就開始頁面的生命周期，如下圖。
下面就處理請求時候觸發的事件順序如下：
BeginRequest: 開發處理請求，是處理ASP.NET請求時觸發的第一個事件
AuthenticateRequest：處理身份驗證
...
AuthorizeRequest：處理授權
...
是以大家可以看出，其實在請求的處理過程中，身份的驗證和授權發生的時期是很早的。而且有關驗證的一些資訊，如使用者名和角色在處理完這兩個事件之後就已經确定，并且填充。下面我想用個圖來講述：
一般對于請求的驗證和授權，我們是希望也應該自己控制這個過程的，是以我們可以在AuthenticateRequest和AuthorizeRequest的事件進行中加入我們自己的代碼。一般在網站中加入 Global.asax檔案。
AuthenticateRequest事件：
當一個請求需要進行身份驗證時，HttpApplication對象就會觸發AuthenticateRequest事件，這也意味着每次對ASP.NET應用程式進行頁面請求時都會觸發這個事件。
在這個事件中實際上是調用相應的身份驗證子產品來處理身份驗證的。例如對于Forms身份驗證子產品而言，就是從加密的cookie中提取使用者資訊。
AuthorizeRequest事件：
AuthorizeRequest事件是在AuthenticateRequest事件中通過了身份驗證時候才觸發的。AuthorizeRequest事件調用相應的授權子產品來檢查使用者是否被授權通路他們請求的資源。因為在AuthenticateRequest事件完成之後就已經有了使用者的表示Identity和IPricipal，也就知道了使用者名和角色的資訊。
2.身份驗證子產品
身份驗證是利用ASP.NET中的身份驗證子產品來實作的。在ASP.NET中内置有四個驗證子產品：
DefaultAuthenticateModule,FormsAuthenticateModule,WindowsAuthenticateModule,PassportAuthenticateModule.他們都實作了IHttpModule接口，當然，如果需要，我們也可以實作自定義的驗證子產品。
從驗證子產品就可以看出我們一般的身份驗證是怎麼進行的，決定采用個驗證子產品是由我們決定采用哪種身份驗證決定的，如Forms驗證就是用了FormsAuthenticateModule來處理的。而且還要配置web.config檔案
中的<authentication/>元素。
下面我們就先來看看身份驗證子產品的實作(僞碼)
Code
public class FormsAuthenticationModule:IHttpModule
{
#region IHttpModule 成員
public void Dispose()
{
throw new NotImplementedException();
}
public void Init(HttpApplication context)
{
context.AuthenticateRequest += new EventHandler(context_AuthenticateRequest);
}
public event FormsAuthenticationEventHandler Authenticate;
#endregion
}
大家可以看到，其實在子產品的Init方法中就訂閱了AuthenticateRequest事件，而我們在Global.asax中寫的代碼就是我們具體處理的代碼：
void context_AuthenticateRequest( object sender, EventArgs e)
{
// 自定義驗證代碼
}
還有一點要注意的就是：每個子產品都有一個Authenticate事件。
下面就說說常用的兩個個驗證子產品，因為大同小異：
WindowsAuthenticateModule：
WindowsAuthenticateModule是和IIS身份驗證聯合試用的，當web.config 的中配置如下：
<authentication mode="Windows"/>
此時，這個子產品就激活了，在Global.asax檔案中就的Application_Authenticate(object sender,eventArgs e)就是給Windows驗證用的。
這裡有一個問題要澄清：如果是我們配置的是Windows身份驗證，我們在Application_Authenticate中就隻能寫和Windows身份驗證有關的代碼，如果是配置的是Forms驗證，我們在Application_Authenticate就隻能寫和Forms有關的代碼，如擷取cookie資訊等。也就是說，Application_Authenticate方法是"一法多用"。
接着談 Windows驗證，在上面的處理程式中，我們可以建立自己的使用者資訊，如我們建立一個WindowsPrincipal類的執行個體(實作了IPrincipal接口，包含使用者名和角色的資訊),然後它指派給 HttpContext.User屬性。這正如我們之前說的，驗證事件執行完之後，我們就知道了這個請求的發起者的使用者名和角色資訊。
FormsAuthenticateModule：
首先還是要配置：<authentication mode="Forms"/>.
FormsAuthenticateModule可以利用cookie解析儲存在cookie中的使用者的資訊，并且建立一個GenericPrincipal，把使用者名和角色資訊儲存在其中，然後指派給User屬性，以備後用。
3.授權子產品
在ASP.NET中内置的授權子產品主要有兩個：FileAuthorizationModule和UrlAuthorizationModule。他們也實作了IHttpModule接口。這些子產品可以參照所試用的身份驗證類型來決定到底采用哪個授權子產品：
如果試用的是Windows身份驗證，那麼在授權檢查的時候就會使用FileAuthorizationModule；
如果在web.config中提供了<authorization/>元素，那麼就會采用UrlAuthorizationModule。如下面的：
< authorization >
< allow roles ="" users ="" />
< deny users ="" />
</ authorization >
FileAuthorizationModule：
如果使用 Windows身份驗證，就會采用FileAuthorizationModule子產品。這個子產品可以處理Authorization事件，并且能夠對IIS提供的請求的令牌和目标資源執行通路檢查。而且這也用到了系統的ACL(通路控制清單).
例 如,如果請求的資源是Default.aspx，目前的使用者是xiaoyang，那麼FileAuthorizationModule就會執行通路檢查，看看xiaoyang時候具備通路Default.aspx的讀的權限，如果在Windows的使用者賬戶中有xiaoyang這個賬戶，并且具有通路的權限，那麼請求成功，否則，FileAuthorizationModule就把Reponse.StatusCode設定為401(未授權)，之後請求就結束了。
UrlAuthorizationModule：
和上面的處理子產品不一樣，不管使用何種類型的身份驗證，隻要配置了web.config中的<authorization/>元素，就要使用UrlAuthorizationModule子產品。這個子產品在處理的時候執行如下：
1，把<authorization/>中聲明的使用者名和HttpContext.User.Identity進行比較
2.把<authorization/>聲明的角色資訊和HttpContext.User.IsInRole比較
如果比較成功就可以通路相應的授權的資源，否則把Reponse.StatusCode設定為401(未授權)，之後請求就結束了。
今天就到這裡，下篇我們詳細談談Forms驗證和授權的各種細節。