ASP.NET身份验证

时间:2024-10-14 22:34:33

Asp.net的身份验证有有三种,分别是"Windows | Forms | Passport",其中又以Forms验

证用的最多,也最灵活。

Forms 验证方式对基于用户的验证授权提供了很好的支持,可以通过一个登录页面验证

用户的身份,将此用户的身份发回到客户端的Cookie,之后此用户再访问这个web应用就

会连同这个身份Cookie一起发送到服务端。服务端上的授权设置就可以根据不同目录对不

同用户的访问授权进行控制了。

问题来了,在实际是用中我们往往需要的是基于角色,或者说基于用户组的验证和授权

。对一个网站来说,一般的验证授权的模式应该是这样的:根据实际需求把用户分成不同

的身份,就是角色,或者说是用户组,验证过程不但要验证这个用户本身的身份,还要验

证它是属于哪个角色的。而访问授权是根据角色来设置的,某些角色可以访问哪些资源,

不可以访问哪些资源等等。要是基于用户来授权访问将会是个很不实际的做法,用户有很

多,还可能随时的增减,不可能在配置文件中随时的为不断增加的新用户去增加访问授权

的。

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

Forms身份验证基本原理:

一 身份验证

要采用Forms身份验证,先要在应用程序根目录中的Web.config中做相应的设置:

<authentication mode="forms">

<forms name=".ASPXAUTH " loginUrl="/login.aspx" timeout="30" path= "/">

</forms>

</authentication>

其中<authentication mode= "forms"> 表示本应用程序采用Forms验证方式。

1. <forms>标签中的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. <forms>标签中的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:过期时间由当前时间和下面要说的<forms>标签中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. <forms>标签中的timeout和path,是提供了身份验证票写入到Cookie过期时间和默认

路径。

以上就是基于Forms身份验证的过程,它完成了对用户身份的确认。下面介绍基于Forms

身份验证的访问授权。

二 访问授权

验证了身份,是要使用这个身份,根据不同的身份我们可以进行不同的操作,处理,

最常见的就是对不同的身份进行不同的授权,Forms验证就提供这样的功能。Forms授权是

基于目录的,可以针对某个目录来设置访问权限,比如,这些用户可以访问这个目录,那

些用户不能访问这个目录。

同样,授权设置是在你要控制的那个目录下的web.config文件中来设置:

<authorization>

<allow users="comma-separated list of users"

roles="comma-separated list of roles"

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

<deny users="comma-separated list of users"

roles="comma-separated list of roles"

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

</authorization>

<allow>标签表示允许访问,其中的属性

1. users:一个逗号分隔的用户名列表,这些用户名已被授予对资源的访问权限。问号

(?) 允许匿名用户;星号 (*) 允许所有用户。

2. roles:一个逗号分隔的角色列表,这些角色已被授予对资源的访问权限。

3. verbs:一个逗号分隔的 HTTP 传输方法列表,这些 HTTP 传输方法已被授予对资源

的访问权限。注册到 ASP.NET 的谓词为 GET、HEAD、POST 和 DEBUG。

<deny>标签表示不允许访问。其中的属性同上面的。

在运行时,授权模块迭代通过 <allow> 和 <deny> 标记,直到它找到适合特定用户的

第一个访问规则。然后,它根据找到的第一项访问规则是 <allow> 还是 <deny> 规则来

允许或拒绝对 URL 资源的访问。Machine.config 文件中的默认身份验证规则是 <allow

users="*"/>,因此除非另行配置,否则在默认情况下会允许访问。

那么这些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的<authentication>的设置还是一样:

<authentication mode="forms">

<forms name=".ASPXAUTH " loginUrl="/login.aspx" timeout="30" path= "/">

</forms>

</authentication>

/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来控制用户的访

问权限了.