本文分別以ASP.NET1.1與ASP.NET2.0在Forms 身份驗(yàn)證上的實(shí)現(xiàn)方法,以及ASP.NET2.0較上一版本有哪些改進(jìn)或變化進(jìn)行說(shuō)明.相信讀者都己經(jīng)看過(guò)許多類(lèi)似這樣的文章,不倫是在網(wǎng)上或是某些專(zhuān)業(yè)書(shū)籍上,最近又有模式&實(shí)踐小組成員發(fā)布WCF安全模型指南,可見(jiàn)構(gòu)建網(wǎng)站安全總是不過(guò)時(shí)的話題,作者認(rèn)為此文也絕對(duì)是您應(yīng)該收藏的參考資料.

ASP.NET 安全性的工作原理

網(wǎng)站在安全性方面有一個(gè)常見(jiàn)的要求：特定的頁(yè)面僅允許某些成員或其他經(jīng)過(guò)身份驗(yàn)證的用戶(hù)瀏覽.充分利用Forms身份驗(yàn)證是最好的方式.
身份驗(yàn)證
從實(shí)現(xiàn)機(jī)制來(lái)說(shuō)ASP.NET1.1與ASP.NET2.0的安全模型是一致的.首先配置網(wǎng)站為Forms 身份驗(yàn)證模式,之后用戶(hù)訪問(wèn)網(wǎng)站的URL,Forms 身份驗(yàn)證系統(tǒng)會(huì)將未經(jīng)身份驗(yàn)證的請(qǐng)求重定向到指定的登錄頁(yè).用戶(hù)輸入憑據(jù)（用戶(hù)名密碼）并提交該頁(yè).如果驗(yàn)證程序驗(yàn)證用戶(hù)的身份合法,則系統(tǒng)會(huì)向客戶(hù)端發(fā)出一個(gè)特定 Cookie（.NET1.1不支持無(wú)Cookie模式）,它代表用戶(hù)的身份驗(yàn)證票據(jù).這樣后續(xù)的請(qǐng)求中,客戶(hù)端瀏覽器會(huì)把該Cookie一同發(fā)送致服務(wù)器,如果該Cookie有效則用戶(hù)通過(guò)身份驗(yàn)證并允許對(duì)原始請(qǐng)求的資源的訪問(wèn).
授權(quán)
如果用戶(hù)的請(qǐng)求被驗(yàn)證通過(guò)了,但是他請(qǐng)求的URL是否允許用戶(hù)訪問(wèn)了呢,這就用到了授權(quán).可以通過(guò)應(yīng)用程序配置文件來(lái)進(jìn)行授友也可以在程序中使用代碼來(lái)驗(yàn)證用戶(hù)是否有資格訪問(wèn)該資源.如果授權(quán)失敗,則 ASP.NET 將用戶(hù)重定向到登錄頁(yè).如果用戶(hù)已被授權(quán),則將允許用戶(hù)訪問(wèn)受保護(hù)資源.
ASP.NET1.1實(shí)現(xiàn)方式
ASP.NET1.1的實(shí)現(xiàn)方式非常簡(jiǎn)單,不過(guò)我們還是需要手寫(xiě)一些代碼的,下面我們就一步一步地實(shí)現(xiàn).應(yīng)用程序配置節(jié)的詳細(xì)說(shuō)明請(qǐng)參考MSDN相關(guān)文檔.
l 配置應(yīng)用程序使用 Forms 身份驗(yàn)證,編輯web.config文件

l 創(chuàng)建登錄頁(yè)面Login.aspx
頁(yè)面預(yù)覽如下,代碼詳細(xì)參考本文附件的項(xiàng)目源碼.

創(chuàng)建用戶(hù)身份主體
ASP.NET1.1安全模型提供了四種授權(quán)方法,這四種方法都使用HttpContext.User對(duì)象進(jìn)行驗(yàn)證授權(quán).
l 使用應(yīng)用程序配置進(jìn)行授權(quán),只有具有指定角色的用戶(hù)才能訪問(wèn)web.config所在的文件夾與子文件夾
<authorization>
<allow roles="Admins"/>
<deny users="?"/>
</authorization>
l 使用PrinciplePermissionAttribute控制對(duì)類(lèi)和方法的訪問(wèn),只允許角色為Admins的成員才能調(diào)用該方法
[System.Security.Permissions.PrincipalPermission(System.Security.Permissions.SecurityAction.Demand,Role=” Admins”)]
public static bool MethodName()
{
...
}
l 以編程方式使用PrinciplePermission類(lèi)控制對(duì)代碼塊的訪問(wèn),只允許角色為Admins的成員調(diào)用Demand之后的代碼
public static bool MethodName()
{
System.Security.Permissions.PrincipalPermission perm = new System.Security.Permissions.PrincipalPermission(null, "Admins");
perm.Demand();
...
}
l 使用Iprincipal.IsInRole方法,只允許角色為Admins的成員運(yùn)行ｉｆ中的代碼,大部分情況我們都使用這種方法判斷用戶(hù)是否有權(quán)限.
public static bool MethodName()
{
if (HttpContext.Current.User.IsInRole("Admins"))
{
//some code
}
}
針對(duì)以上的特點(diǎn),程序員必須在合適的地方創(chuàng)建HttpContext.User對(duì)象,以達(dá)到驗(yàn)證模型的要求.開(kāi)發(fā)人員必須編寫(xiě)HttpApplication:: AuthenticateRequest事件.該事件的發(fā)生代表著用戶(hù)己經(jīng)通過(guò)Forms身份驗(yàn)證.
在Global.asax中實(shí)現(xiàn)Application_AuthenticateRequest.
protected void Application_AuthenticateRequest(Object sender, EventArgs e)
{
HttpApplication app = (HttpApplication)sender;
HttpCookie cookie = Request.Cookies[FormsAuthentication.FormsCookieName];
if (cookie != null)
{
string encryptedTicket = cookie.Value;
FormsAuthenticationTicket ticket = FormsAuthentication.Decrypt(encryptedTicket);
//獲取在登錄驗(yàn)證時(shí)加入驗(yàn)證票據(jù)的用戶(hù)所擁有的角色,但真正開(kāi)發(fā)時(shí)請(qǐng)不這樣做,建議從數(shù)據(jù)庫(kù)中獲取該用戶(hù)角色信息.
//因?yàn)镃ookie本身有長(zhǎng)度的限制,并且將用戶(hù)角色存儲(chǔ)到客戶(hù)端也不是安全的行為.
//大家想想如果Cookie不限制大小,那么它的尺寸大到幾MB或GB時(shí),客戶(hù)端與服務(wù)器的每一次通迅,將是怎樣的一種情況了,呵呵.
//這里僅展示如何將角色信息加入到用戶(hù)主體GenericPrincipal中.
string[] roles = ticket.UserData.Split(new char[] { ',' });//獲取角色
FormsIdentity identity = new FormsIdentity(ticket);
System.Security.Principal.GenericPrincipal user = new System.Security.Principal.GenericPrincipal(identity, roles);
app.Context.User = user;
//app.Context.User = new System.Security.Principal.GenericPrincipal(new System.Web.Security.FormsIdentity(FormsAuthentication.Decrypt(cookie.Value)), new string[]{"Admins"});
}
}
或者在Global.asax中實(shí)現(xiàn)FormsAuthentication_Authenticate效果是一樣的.
void FormsAuthentication_OnAuthenticate(object sender, FormsAuthenticationEventArgs e)
{
HttpCookie cookie = Request.Cookies[FormsAuthentication.FormsCookieName];
if (cookie != null)
{
string encryptedTicket = cookie.Value;
FormsAuthenticationTicket ticket = FormsAuthentication.Decrypt(encryptedTicket);
string[] roles = ticket.UserData.Split(new char[] { ',' });
FormsIdentity identity = new FormsIdentity(ticket);
System.Security.Principal.GenericPrincipal user = new System.Security.Principal.GenericPrincipal(identity, roles);
e.Context.User = user;
}
}
其實(shí)FormsAuthenticationModule會(huì)自動(dòng)生成一個(gè)User對(duì)象,只不過(guò)這個(gè)對(duì)象的角色列表為空,它只能是代表通過(guò)身份驗(yàn)證,而不能通過(guò)授權(quán),因?yàn)槲覀兿拗屏四夸浀脑L問(wèn)角色,所以開(kāi)發(fā)人員必須實(shí)現(xiàn)上面代碼,才能滿足我們的要足,如果說(shuō)你的網(wǎng)站僅需要通過(guò)身份驗(yàn)證的話,就可不必實(shí)現(xiàn)這些方法了.
用戶(hù)在請(qǐng)求URL時(shí),ASP.NET請(qǐng)求通道會(huì)連續(xù)觸發(fā)一堆的事件,這些事件完成了一系列任務(wù),其中就包括Forms身份驗(yàn)證事件與授權(quán)事件.如下所示:
BeginRequest 請(qǐng)求開(kāi)始事件
AuthenticateRequest 驗(yàn)證通過(guò)事件 (上面兩段代碼就是在這個(gè)事件中被執(zhí)行)
PostAuthenticateRequest 用戶(hù)標(biāo)識(shí)己建立時(shí)發(fā)生 ASP.NET 2.0引入的事件,后面會(huì)講到.
AuthorizeRequest 當(dāng)安全模塊已驗(yàn)證用戶(hù)授權(quán)時(shí)發(fā)生
....其它事件略;
正是這些事件的壘加促成了ASP.NET框架驗(yàn)證模型的實(shí)現(xiàn), 而且通過(guò)完成上面的幾個(gè)步驟,網(wǎng)站內(nèi)容就己經(jīng)受到授權(quán)機(jī)制的保護(hù)了.
下面讓我們看看ASP.NE安全模型是如何做到授權(quán)的.
l ASP.NET 1.1 安全模型驗(yàn)證授權(quán)的原理
在 ASP.NET 中,有兩種方式限制對(duì)資源訪問(wèn)的權(quán)限：文件授權(quán)與URL 授權(quán),這里我們僅討倫后者.
URL 授權(quán)由 UrlAuthorizationModule 執(zhí)行,它將用戶(hù)和角色映射到 ASP.NET 應(yīng)用程序中的 URL.這個(gè)模塊可用于有選擇地允許或拒絕特定用戶(hù)或角色對(duì)應(yīng)用程序的任意部分（通常在web.config文件中為目錄指定授權(quán)用戶(hù)或角色）的訪問(wèn)權(quán)限.
HTTP模塊是在ASP.NET框架默認(rèn)應(yīng)用程序配置文件中注冊(cè)的,如下：

下面簡(jiǎn)單分析UrlAuthorizationModule的源碼,便可了解驗(yàn)證模型是如何驗(yàn)證在web.config中指定的授權(quán)規(guī)則.

UrlAuthorizationModule在應(yīng)用程序初始化時(shí)向HttpApplication::AuthorizeRequest事件(安全模塊已驗(yàn)證用戶(hù)授權(quán)時(shí)發(fā)生)注冊(cè)委托代碼,該代碼內(nèi)部調(diào)用AuthorizationConfig::IsUserAllowed.方法實(shí)現(xiàn)截圖如下：

上面代碼又調(diào)用了AuthorizationConfigRule::IsUserAllowed方法,截圖如下:

由于HttpApplication::AuthorizeRequest事件是在HttpApplication::AuthenticateRequest事件之后執(zhí)行的(請(qǐng)看我提到過(guò)的事件列表), 在前面介紹的AuthenticateRequest事件中我們修改了Context.User對(duì)象,而且加入了角色信息,所以AuthorizeRequest事件在驗(yàn)證用戶(hù)的權(quán)限時(shí)發(fā)現(xiàn)Context.User對(duì)象中什么都有,所以它才允許用戶(hù)訪問(wèn)請(qǐng)求的資源,否則請(qǐng)求將被返回到指定的頁(yè)面.以上就是ASP.NET1.1的原理,怎么樣你理解了嗎?

ASP.NET2.0你仍可以用這樣的機(jī)制,但又增加新特性.下面就看看在ASP.NET2.0中是如何實(shí)現(xiàn)的吧!

ASP.NET 2.0 實(shí)現(xiàn)方式

ASP.NET2.0的實(shí)現(xiàn)方式與ASP.NET1.1實(shí)現(xiàn)方式大同小異,同樣支持前一版本的安全模型.不過(guò)又新增了成員資格與角色管理授權(quán)模型.這里就介紹ASP.NET2.0新增的內(nèi)容.

 

l         應(yīng)用程序配置新增屬性

<system.web>

 <authentication mode="Forms">

       //defaultUrl是ASP.NET2.0版本新增的屬性, 在驗(yàn)證模型重定向URL時(shí)將重定向到的URL.默認(rèn)值為"default.aspx".

//雖然ASP.NET1.1版本沒(méi)有該屬性,但程序中的默認(rèn)為"default.aspx".還是ASP.NET2.0的配置更為靈活.

    <forms loginUrl="logon.aspx" protection="All" name=".ASPXFORMSAUTH" path="/" defaultUrl="Index.aspx"></forms>

 </authentication>

 <authorization>

    <deny users="?" />/*匿名用戶(hù)*/

 </authorization>

</system.web>

l         使用成員資格驗(yàn)證登錄

ASP.NET 成員資格主要用于ASP.NET Forms 身份驗(yàn)證,配合ASP.NET2.0登錄控件可以不用寫(xiě)任何代碼就能實(shí)現(xiàn)Forms身份驗(yàn)證.

首先創(chuàng)建登錄頁(yè)Login.aspx,將登錄控件托入到窗體中即可,不用寫(xiě)任何登錄事件代碼,相比ASP.NET1.1節(jié)省時(shí)間不是一點(diǎn)半點(diǎn).

l         使用角色管理進(jìn)行訪問(wèn)授權(quán)

角色管理可以幫助您管理授權(quán),使您能夠指定應(yīng)用程序中的用戶(hù)可訪問(wèn)的資源.角色管理可讓您通過(guò)將用戶(hù)分配到相應(yīng)角色來(lái)對(duì)其進(jìn)行分組,從而更容易控制訪問(wèn)權(quán)限.

1.         啟用角色管理

要啟用該功能,修改web.config文件在<system.web>配置節(jié)點(diǎn)內(nèi)增加子節(jié)點(diǎn)如下:

<roleManager enabled="true" cacheRolesInCookie="true" />

cacheRolesInCookie屬性代表是否緩存角色信息,這樣不用每次都從數(shù)據(jù)庫(kù)中獲取角色,以提高應(yīng)用程序的性能.

但是將角色放在Cookie里總是風(fēng)險(xiǎn)的,它可能被篡改,然后用它訪問(wèn)未被授權(quán)的資源.

不過(guò)可以在用戶(hù)每次登錄時(shí),先使用Role API的DeleteCookie方法刪除這個(gè)緩存Cookie, 這樣可使風(fēng)險(xiǎn)小一點(diǎn).

推薦代碼:

if(Membership.ValidateUser(username, password)){

 Roles.DeleteCookie();

 FormsAuthentication.RedirectFromLoginPage(username, false);

}

特別提示:應(yīng)用程序配置中當(dāng)角色管理可用并且提供者程序?yàn)?/SPAN>AspNetSqlProvider時(shí), SqlRoleProvider的GetRolesForUser方法會(huì)調(diào)用System.Web.DataAccess.SqlConnectionHelper類(lèi)的私有靜態(tài)方法EnsureSqlExpressDBFile創(chuàng)建一個(gè)空的aspnetdb.mdf本地?cái)?shù)據(jù)庫(kù),該數(shù)據(jù)庫(kù)包含成員資格與角色管理,所需要的表結(jié)構(gòu)等信息.

2.         配置成員與角色

使用VS2008自帶的配置工具設(shè)定成員與角色是最簡(jiǎn)單不過(guò)的了,點(diǎn)擊菜單欄中的[項(xiàng)目],下拉菜單的最后一項(xiàng)[ASP.NET配置],在彈出窗體中設(shè)置成員與角色關(guān)系.如下圖展示:

在安全選項(xiàng)卡內(nèi)有管理用戶(hù)與角色的內(nèi)容,如下圖:

本示例創(chuàng)建了一個(gè)用戶(hù)”iori”與一個(gè)角色”Admins”,并且指定了該用戶(hù)是Admins角色的成員.

另外該工具還會(huì)自動(dòng)創(chuàng)建本地?cái)?shù)據(jù)庫(kù)(如果還沒(méi)創(chuàng)建).與它相關(guān)的配置在machine.config文件中指定,如下圖所示,你可以更改數(shù)據(jù)庫(kù)的文件名,默認(rèn)為”aspnetdb.mdf”.

 

好了,通過(guò)完成上面的幾個(gè)步驟,網(wǎng)站內(nèi)容就己經(jīng)受到授權(quán)機(jī)制的保護(hù)了,可以用剛剛添加的用戶(hù)試試登錄吧.

相比上一版本,ASP.NET2.0在Forms身份驗(yàn)證里為開(kāi)發(fā)人員節(jié)省很多時(shí)間,幾乎不用開(kāi)發(fā)人員寫(xiě)任何代碼,方便了許多,下面讓我們一探究竟.

 

l         ASP.NET 2.0 安全模型驗(yàn)證授權(quán)的原理

1.          驗(yàn)證原理

在.net1.1中開(kāi)發(fā)人員必須為登錄頁(yè)編寫(xiě)登錄事件,用來(lái)驗(yàn)證用戶(hù)輸入的用戶(hù)名與密碼是否有效,而ASP.NET 2.0中引入了成員資格提供程序與標(biāo)準(zhǔn)登錄服務(wù)器控件,它們隱式使用Forms 身份驗(yàn)證,登錄控件己經(jīng)包含了驗(yàn)證用戶(hù)名的程序邏輯,也就是說(shuō)登錄控件會(huì)把用戶(hù)輸入的用戶(hù)名與密碼自動(dòng)與成員資格數(shù)據(jù)庫(kù)中的用戶(hù)進(jìn)行匹配,如果成功匹配就將特定Cookie寫(xiě)入客戶(hù)端.

2.         授權(quán)原理

還是拿UrlAuthorizationModule說(shuō)事兒, 如果不啟用角色管理,實(shí)現(xiàn)方式與ASP.NET1.1差不多,不過(guò)由于ASP.NET2.0加入了角色管理模型,角色管理模型使用兩個(gè)類(lèi): RolePrincipal與RoleManagerModule來(lái)實(shí)現(xiàn)角色授權(quán).如果應(yīng)用程序配置的角色管理可用時(shí),這兩個(gè)新對(duì)象將被應(yīng)用到aspx頁(yè)面的生命周期中, 由于RoleManagerModule 被初始化時(shí)會(huì)向HttpApplication對(duì)象的事件PostAuthenticateRequest加載委托代碼,該代碼會(huì)將app.Context.User對(duì)象包裝成RolePrincipal對(duì)象.

PostAuthenticateRequest事件是在ASP.NET 2.0中加入的,該事件發(fā)生在AuthenticateRequest事件之后,代表安全模塊已建立了用戶(hù)標(biāo)識(shí),所以在這個(gè)事件中使用用戶(hù)標(biāo)識(shí)重新生成RolePrincipal對(duì)象.

下面為委托代碼的節(jié)選.

......//省略若干代碼

HttpApplication application = (HttpApplication) source;

HttpContext context = application.Context;

if (this._eventHandler != null)

{

     RoleManagerEventArgs e = new RoleManagerEventArgs(context);

     this._eventHandler(this, e);

     if (e.RolesPopulated)

     {      

              //判斷開(kāi)發(fā)人員是否在Global.asax中寫(xiě)了事件處理程序,如下顯示的代碼.

              /*

              //這里演示如何在Global.asax中自定義角色

        void RoleManager_GetRoles(object sender, RoleManagerEventArgs e)

        {

            if (e.Context.Request.IsAuthenticated)

            {

                e.Context.User = new GenericPrincipal(new GenericIdentity(e.Context.User.Identity.Name), new string[] { "Admins" });

                e.RolesPopulated = true;

            }

        }

              */

              //如果e.RolesPopulated為真,代表開(kāi)發(fā)人員自己創(chuàng)建了角色信息,

//RoleManagerModule就不會(huì) 生成RolePrincipal 對(duì)象了.

              return;

     }

}

......

if (!(context.User is RolePrincipal))

{

     context.User = new RolePrincipal(context.User.Identity);

}

Thread.CurrentPrincipal = context.User;

 

注意:我們并沒(méi)有像ASP.NET1.1中那樣在AuthenticateRequest事件中生成User對(duì)象.但是User對(duì)象會(huì)在FormsAuthenticationModuleHTTP模塊中使用Forms身份驗(yàn)證的特定Cookie重新被包裝成一個(gè)GenericPrincipal對(duì)象(角色為空).

在說(shuō)明RolePrincipal對(duì)象有什么用之前,需要了解這個(gè)對(duì)象是何時(shí)被用到的.

在UrlAuthorizationModule被初始化時(shí)中向HttpApplication對(duì)象注冊(cè)的事件AuthorizeRequest被觸發(fā).

在這個(gè)事件中會(huì)調(diào)用RolePrincipal對(duì)象(就是Context.User)的方法IsInRole, IsInRole方法會(huì)自動(dòng)查找角色提供程序(本示例使用默認(rèn)提供程序AspNetSqlProvider,數(shù)據(jù)庫(kù)為前面自動(dòng)生成的ASPNETDB.MDF),并驗(yàn)證用戶(hù)角色,代碼截圖如下:

而IsUserAllowed方法最終會(huì)調(diào)用RolePrincipal對(duì)角的IsInRole方法來(lái)判斷當(dāng)前用戶(hù)是否擁有某角色,方法截圖如下:

以上這些便是ASP.NET2.0成員資格與角色管理實(shí)現(xiàn)Forms身份驗(yàn)證的原理與實(shí)現(xiàn),不過(guò)默認(rèn)的成員資格與角色數(shù)據(jù)庫(kù)的字段一般并不能滿足具體項(xiàng)目的需要.好在ASP.NET 2.0中提供了可擴(kuò)展提拱程序模型,開(kāi)發(fā)人員可以定制成員資格提供程序與角色管理模型.

結(jié)束語(yǔ)

    網(wǎng)站應(yīng)用程序的身份驗(yàn)證和授權(quán)方法是一項(xiàng)具有挑戰(zhàn)性的任務(wù),而Forms身份驗(yàn)證在網(wǎng)站建設(shè)中提供了重要的安全性?xún)?yōu)勢(shì),通過(guò)提供用戶(hù)配置文件以及對(duì)角色的支持, 簡(jiǎn)化了程序員通常需要編寫(xiě)大量代碼才能完成的工作.如果讀者還有什么問(wèn)題或者對(duì)以上描述有不同的見(jiàn)解,歡迎與我聯(lián)系互相交流!