Asp.net中基於Forms驗證的角色驗證授權

Asp.net的身份驗證有有三種，分別是"Windows | Forms | Passport"，其中又以Forms驗證用的最多，也最靈活。
Forms 驗證方式對基於使用者的驗證授權提供了很好的支援，可以透過一個登入頁面驗證使用者的身份，將此使用者的身份發回到客戶端的Cookie，之後此使用者再訪問這個web應用就會連同這個身份Cookie一起傳送到服務端。服務端上的授權設定就可以根據不同目錄對不同使用者的訪問授權進行控制了。

問題來了，在實際是用中我們往往需要的是基於角色，或者說基於使用者組的驗證和授權。對一個網站來說，一般的驗證授權的模式應該是這樣的：根據實際需求把使用者分成不同的身份，就是角色，或者說是使用者組，驗證過程不但要驗證這個使用者本身的身份，還要驗證它是屬於哪個角色的。而訪問授權是根據角色來設定的，某些角色可以訪問哪些資源，不可以訪問哪些資源等等。要是基於使用者來授權訪問將會是個很不實際的做法，使用者有很多，還可能隨時的增減，不可能在配置檔案中隨時的為不斷增加的新使用者去增加訪問授權的。

下面大概的看一下Forms的過程。

Forms身份驗證基本原理：

一 身份驗證

要採用Forms身份驗證，先要在應用程式根目錄中的Web.config中做相應的設定:

其中 表示本應用程式採用Forms驗證方式。
1. 標籤中的name表示指定要用於身份驗證的 HTTP Cookie。預設情況下，name 的值是 .ASPXAUTH。採用此種方式驗證使用者後,以此使用者的資訊建立一個FormsAuthenticationTicket型別的身份驗證票,再加密序列化為一個字串,最後將這個字串寫到客戶端的name指定名字的Cookie中.一旦這個Cookie寫到客戶端後,此使用者再次訪問這個web應用時會將連同Cookie一起傳送到服務端,服務端將會知道此使用者是已經驗證過的.

再看一下身份驗證票都包含哪些資訊呢,我們看一下FormsAuthenticationTicket類:
CookiePath： 返回發出 Cookie 的路徑。注意，窗體的路徑設定為 /。由於窗體區分大小寫，這是為了防止站點中的 URL 的大小寫不一致而採取的一種保護措施。這在重新整理 Cookie 時使用
Expiration： 獲取 Cookie 過期的日期/時間。
IsPersistent： 如果已發出持久的 Cookie，則返回 true。否則，身份驗證 Cookie 將限制在瀏覽器生命週期範圍內。
IssueDate： 獲取最初發出 Cookie 的日期/時間。
Name： 獲取與身份驗證 Cookie 關聯的使用者名稱。
UserData ：獲取儲存在 Cookie 中的應用程式定義字串。
Version： 返回位元組版本號供將來使用。

2. 標籤中的loginUrl指定如果沒有找到任何有效的身份驗證 Cookie，為登入將請求重定向到的 URL。預設值為 default.aspx。loginUrl指定的頁面就是用來驗證使用者身份的,一般此頁面提供使用者輸入使用者名稱和密碼,使用者提交後由程式來根據自己的需要來驗證使用者的合法性(大多情況是將使用者輸入資訊同資料庫中的使用者表進行比較),如果驗證使用者有效,則生成同此使用者對應的身份驗證票,寫到客戶端的Cookie,最後將瀏覽器重定向到使用者初試請求的頁面.一般是用FormsAuthentication.RedirectFromLoginPage 方法來完成生成身份驗證票,寫回客戶端,瀏覽器重定向等一系列的動作.

public static void RedirectFromLoginPage( string userName, bool createPersistentCookie, string strCookiePath );

其中:
userName： 就是此使用者的標示,用來標誌此使用者的唯一標示,不一定要對映到使用者賬戶名稱.
createPersistentCookie： 標示是否發出持久的 Cookie。
若不是持久Cookie，Cookie的有效期Expiration屬性有當前時間加上web.config中timeout的時間，每次請求頁面時，在驗證身份過程中，會判斷是否過了有效期的一半，要是的話更新一次cookie的有效期；若是持久cookie，Expiration屬性無意義，這時身份驗證票的有效期有cookie的Expires決定，RedirectFromLoginPage方法給Expires屬性設定的是50年有效期。
strCookiePath： 標示將生成的Cookie的寫到客戶端的路徑，身份驗證票中儲存這個路徑是在重新整理身份驗證票Cookie時使用（這也是生成Cookie的Path），若沒有strCookiePath 引數，則使用web.config中 path屬性的設定。

這裡可以看到,此方法引數只有三個,而身份驗證票的屬性有七個,不足的四個引數是這麼來的:
IssueDate： Cookie發出時間由當前時間得出,
Expiration：過期時間由當前時間和下面要說的標籤中timeout引數算出。此引數對非永續性cookie有意義。
UserData： 這個屬性可以用應用程式寫入一些使用者定義的資料,此方法沒有用到這個屬性,只是簡單的將此屬性置為空字串,請注意此屬性,在後面我們將要使用到這個屬性。
Version： 版本號由系統自動提供.

RedirectFromLoginPage方法生成生成身份驗證票後，會呼叫FormsAuthentication.Encrypt 方法，將身份驗證票加密為字串，這個字串將會是以.ASPXAUTH為名字的一個Cookie的值。這個Cookie的其它屬性的生成：Domain，Path屬性為確省值，Expires視createPersistentCookie引數而定，若是持久cookie，Expires設為50年以後過期；若是非持久cookie，Expires屬性不設定。
生成身份驗證Cookie後，將此Cookie加入到Response.Cookies中，等待傳送到客戶端。
最後RedirectFromLoginPage方法呼叫FormsAuthentication.GetRedirectUrl 方法獲取到使用者原先請求的頁面，重定向到這個頁面。

3. 標籤中的timeout和path,是提供了身份驗證票寫入到Cookie過期時間和預設路徑。

以上就是基於Forms身份驗證的過程，它完成了對使用者身份的確認。下面介紹基於Forms身份驗證的訪問授權。

二 訪問授權

驗證了身份，是要使用這個身份，根據不同的身份我們可以進行不同的操作，處理，最常見的就是對不同的身份進行不同的授權，Forms驗證就提供這樣的功能。Forms授權是基於目錄的，可以針對某個目錄來設定訪問許可權，比如，這些使用者可以訪問這個目錄，那些使用者不能訪問這個目錄。
同樣，授權設定是在你要控制的那個目錄下的web.config檔案中來設定：

roles="comma-separated list of roles"
verbs="comma-separated list of verbs" />
roles="comma-separated list of roles"
verbs="comma-separated list of verbs" />

標籤表示允許訪問，其中的屬性
1. users：一個逗號分隔的使用者名稱列表，這些使用者名稱已被授予對資源的訪問許可權。問號 (?) 允許匿名使用者；星號 (*) 允許所有使用者。
2. roles：一個逗號分隔的角色列表，這些角色已被授予對資源的訪問許可權。
3. verbs：一個逗號分隔的 HTTP 傳輸方法列表，這些 HTTP 傳輸方法已被授予對資源的訪問許可權。註冊到 ASP.NET 的謂詞為 GET、HEAD、POST 和 DEBUG。

標籤表示不允許訪問。其中的屬性同上面的。

在執行時，授權模組迭代透過 和 標記，直到它找到適合特定使用者的第一個訪問規則。然後，它根據找到的第一項訪問規則是 還是 規則來允許或拒絕對 URL 資源的訪問。Machine.config 檔案中的預設身份驗證規則是 ，因此除非另行配置，否則在預設情況下會允許訪問。

那麼這些user 和roles又是如何得到的呢？下面看一下授權的詳細過程：

1. 一旦一個使用者訪問這個網站，就行登入確認了身份，身份驗證票的cookie也寫到了客戶端。之後，這個使用者再次申請這個web的頁面，身份驗證票的cookie就會傳送到服務端。在服務端，asp.net為每一個http請求都分配一個HttpApplication物件來處理這個請求，在HttpApplication.AuthenticateRequest事件後，安全模組已建立使用者標識，就是此使用者的身份在web端已經建立起來，這個身份完全是由客戶端傳送回來的身份驗證票的cookie建立的。
2. 使用者身份在HttpContext.User 屬性中，在頁面中可以透過Page.Context 來獲取同這個頁面相關的HttpContext物件。對於Forms驗證，HttpContext.User屬性是一個GenericPrincipal型別的物件，GenericPrincipal只有一個公開的屬性Identity，有個私有的m_role屬性，是string[]型別，存放此使用者是屬於哪些role的陣列，還有一個公開的方法IsInRole(string role)，來判斷此使用者是否屬於某個角色。
由於身份驗證票的cookie中根本沒有提供role這個屬性，就是說Forms身份驗證票沒有提供此使用者的role資訊，所以，對於Forms驗證，在服務端得到的GenericPrincipal 使用者物件的m_role屬性永遠是空的。
3. GenericPrincipal. Identity 屬性是一個FormsIdentity型別的物件，這個物件有個Name屬性，就是此使用者的標示，訪問授權就是將此屬性做為user來進行授權驗證的。FormsIdentity還有一個屬性，就是Ticket屬性，此屬性是身份驗證票FormsAuthenticationTicket型別，就是之前伺服器寫到客戶端的身份驗證票。
伺服器在獲取到身份驗證票FormsAuthenticationTicket物件後，檢視這個身份驗證票是不是非持久的身份驗證，是的話要根據web.config中timeout屬性設定的有效期來更新這個身份驗證票的cookie（為避免危及效能，在經過了超過一半的指定時間後更新該 Cookie。這可能導致精確性上的損失。永續性 Cookie 不超時。）
4. 在HttpApplication.ResolveRequestCache事件之前，asp.net開始取得使用者請求的頁面，建立HttpHandler控制點。這就意味著，在HttpApplication.ResolveRequestCache事件要對使用者訪問許可權就行驗證，看此使用者或角色是否有許可權訪問這個頁面，之後在這個請求的生命週期內再改變此使用者的身份或角色就沒有意義了。

以上是Forms驗證的全過程，可以看出，這個Forms驗證是基於使用者的，沒有為角色的驗證提供直接支援。身份驗證票FormsAuthenticationTicket 中的Name屬性是使用者標示，其實還有一個屬性UserData，這個屬性可以由應用程式來寫入自定義的一些資料，我們可以利用這個欄位來存放role的資訊，從而達到基於角色驗證的目的。

Forms身份驗證基於角色的授權

一 身份驗證

在web.config的的設定還是一樣：

/login.aspx驗證使用者合法性頁面中，在驗證了使用者的合法性後，還要有個取得此使用者屬於哪些role的過程，這個看各個應用的本身如何設計的了，一般是在資料庫中會有個use_role表，可以從資料庫中獲得此使用者屬於哪些role，在此不深究如何去獲取使用者對應的role，最後肯定能夠獲得的此使用者對應的所有的role用逗號分割的一個字串。
在上面的非基於角色的方法中，我們用了FormsAuthentication.RedirectFromLoginPage 方法來完成生成身份驗證票,寫回客戶端,瀏覽器重定向等一系列的動作。這個方法會用一些確省的設定來完成一系列的動作，在基於角色的驗證中我們不能用這一個方法來實現，要分步的做，以便將一些定製的設定加進來：

1. 首先要根據使用者標示，和使用者屬於的角色的字串來建立身份驗證票
public FormsAuthenticationTicket(
int version, //設為1
string name, //使用者標示
DateTime issueDate, //Cookie 的發出時間, 設定為 DateTime.Now
DateTime expiration, //過期時間
bool isPersistent, //是否永續性(根據需要設定,若是設定為永續性,在發出
cookie時,cookie的Expires設定一定要設定)
string userData, //這裡用上面準備好的用逗號分割的role字串
string cookiePath // 設為"/",這要同發出cookie的路徑一致,因為重新整理cookie
要用這個路徑
);

FormsAuthenticationTicket Ticket = new FormsAuthenticationTicket (1,"kent",DateTime.Now, DateTime.Now.AddMinutes(30), false,UserRoles,"/") ;

2. 生成身份驗證票的Cookie
2.1 將身份驗證票加密序列化成一個字串
string HashTicket = FormsAuthentication.Encrypt (Ticket) ;
2.2 生成cookie
HttpCookie UserCookie = new HttpCookie(FormsAuthentication.FormsCookieName, HashTicket) ;
FormsAuthentication.FormsCookieName 是用來獲取web.config中設定的身份驗證cookie的名字,預設為" .ASPXAUTH".
若身份驗證票中的isPersistent屬性設定為持久類,則這個cookie的Expires屬性一定要設定,這樣這個cookie才會被做為持久cookie儲存到客戶端的cookie檔案中.
3. 將身份驗證票Cookie輸出到客戶端
透過Response.Cookies.Add(UserCookie) 將身份驗證票Cookie附加到輸出的cookie集合中,傳送到客戶端.
4. 重定向到使用者申請的初試頁面.

驗證部分程式碼(這部分程式碼是在login.aspx頁面上點選了登入按鈕事件處理程式碼):

private void Buttonlogin_Click(object sender, System.EventArgs e)
{
string user = TextBoxUser.Text; //讀取使用者名稱
string password = TextBoxPassword.Text; //讀取密碼
if(Confirm(user,password) == true) //confirm方法用來驗證使用者合法性的
{
string userRoles = UserToRole(user); //呼叫UserToRole方法來獲取role字串
FormsAuthenticationTicket Ticket = new FormsAuthenticationTicket (1,user,DateTime.Now, DateTime.Now.AddMinutes(30), false,userRoles,"/") ; //建立身份驗證票物件
string HashTicket = FormsAuthentication.Encrypt (Ticket) ; //加密序列化驗證票為字串
HttpCookie UserCookie = new HttpCookie(FormsAuthentication.FormsCookieName, HashTicket) ;
//生成Cookie
Context.Response.Cookies.Add (UserCookie) ; //輸出Cookie
Context.Response.Redirect (Context.Request["ReturnUrl"]) ; // 重定向到使用者申請的初始頁面
}
else
{
// 使用者身份未被確認時的程式碼
}
}
//此方法用來驗證使用者合法性的
private bool Confirm(string user,string password)
{
//相應的程式碼
}
//此方法用來獲得的使用者對應的所有的role用逗號分割的一個字串
private string UserToRole(string user)
{
//相應的程式碼
}

二 基於角色訪問授權

這裡我們要做的是,將客戶端儲存的身份驗證票中UserData中儲存的表示角色的資訊恢復到在服務端表示使用者身份的GenericPrincipal物件中(記住,原來的驗證過程中, GenericPrincipal物件只包含了使用者資訊,沒有包含role資訊)
一個Http請求的過程中,HttpApplication.AuthenticateRequest事件表示安全模組已建立使用者標識，就是此使用者的身份在web端已經建立起來, 在這個事件之後我們就可以獲取使用者身份資訊了.
在HttpApplication.ResolveRequestCache事件之前，asp.net開始取得使用者請求的頁面，建立HttpHandler控制點,這時就已經要驗證使用者的許可權了,所以恢復使用者角色的工作只能在HttpApplication.AuthenticateRequest事件和HttpApplication.ResolveRequestCache事件之間的過程中做.
我們選擇Application_AuthorizeRequest事件中做這個工作,可以在global.asax檔案中處理HttpApplication的所有的事件,程式碼如下:

protected void Application_AuthorizeRequest(object sender, System.EventArgs e)
{
HttpApplication App = (HttpApplication) sender;
HttpContext Ctx = App.Context ; //獲取本次Http請求相關的HttpContext物件
if (Ctx.Request.IsAuthenticated == true) //驗證過的使用者才進行role的處理
{
FormsIdentity Id = (FormsIdentity)Ctx.User.Identity ;
FormsAuthenticationTicket Ticket = Id.Ticket ; //取得身份驗證票
string[] Roles = Ticket.UserData.Split (',') ; //將身份驗證票中的role資料轉成字串陣列
Ctx.User = new GenericPrincipal (Id, Roles) ; //將原有的Identity加上角色資訊新建一個GenericPrincipal表示當前使用者,這樣當前使用者就擁有了role資訊
}
}

訪問者同時具有了user和role資訊,就可以據此在web.config中用role來控制使用者的訪問許可權了.

[@more@]