摘要
\n
安全性是 ASP.NET Web 应用程序中一个非常重要的方面,它涉及内容非常广泛,不能在一篇文章内说明所有的安全规范,本文讲述如何利用IIS以及Forms 身份验证构建安全的 ASP.NET 应用程序,它是目前被使用最多最广的验证／授权方式.
\n
本文分别以ASP.NET1.1与ASP.NET2.0在Forms 身份验证上的实现方法,以及ASP.NET2.0较上一版本有哪些改进或变化进行说明.相信读者都己经看过许多类似这样的文章,不伦是在网上或是某些专业书籍上,最近又有模式&实践小组成员发布WCF安全模型指南,可见构建网站安全总是不过时的话题,作者认为此文也绝对是您应该收藏的参考资料.
\nASP.NET 安全性的工作原理
\n
网站在安全性方面有一个常见的要求：特定的页面仅允许某些成员或其他经过身份验证的用户浏览.充分利用Forms身份验证是最好的方式.
\n
身份验证
\n
从实现机制来说ASP.NET1.1与ASP.NET2.0的安全模型是一致的.首先配置网站为Forms 身份验证模式,之后用户访问网站的URL,Forms 身份验证系统会将未经身份验证的请求重定向到指定的登录页.用户输入凭据（用户名密码）并提交该页.如果验证程序验证用户的身份合法,则系统会向客户端发出一个特定 Cookie（.NET1.1不支持无Cookie模式）,它代表用户的身份验证票据.这样后续的请求中,客户端浏览器会把该Cookie一同发送致服务器,如果该Cookie有效则用户通过身份验证并允许对原始请求的资源的访问.
\n
授权
\n
如果用户的请求被验证通过了,但是他请求的URL是否允许用户访问了呢,这就用到了授权.可以通过应用程序配置文件来进行授友也可以在程序中使用代码来验证用户是否有资格访问该资源.如果授权失败,则 ASP.NET 将用户重定向到登录页.如果用户已被授权,则将允许用户访问受保护资源.
\n
ASP.NET1.1实现方式
\n
ASP.NET1.1的实现方式非常简单,不过我们还是需要手写一些代码的,下面我们就一步一步地实现.应用程序配置节的详细说明请参考MSDN相关文档.
\n
l 配置应用程序使用 Forms 身份验证,编辑web.config文件
\n
<configuration>
<system.web>
\n
<authentication mode=”Forms”>
<forms name=”.ASPXCOOKIEAUTH” loginUrl=”Login.aspx” protection=”All” timeout=”30″ path=”/” />
</authentication>
<authorization>
\n
<deny users=”?” /> <!—拒绝匿名 –>
</authorization>
……
\n
</system.web>
\n
<location path=”Admin”><!—配置授权,只允许拥有Admins角色的用户访问这个目录下的文件（＊.ａｓｐｘ）–>
\n
<system.web>
\n
<authorization>
\n
<allow roles=”Admins”/><!—虽然下面配置为拒绝所有用户,但是allow的优先级比deny高.–>
\n
<deny users=”*” /><!—拒绝所有用户 –>
\n
<!—
\n
一个用户或角色必须特别指定为拒绝,才能拒绝该用户或角色对URL的权限.如果上面的示例没有指定<deny users=”*” />元素,则将允许所有通过身份验证的用户访问所请求的 URL,而不考虑其所属的角色.
\n
–>
\n
</authorization>
\n
</system.web>
\n
</location>
\n
</configuration>
\n
l 创建登录页面Login.aspx
\n
页面预览如下,代码详细参考本文附件的项目源码.
\n
\n
l 创建用户身份主体
\n
ASP.NET1.1安全模型提供了四种授权方法,这四种方法都使用HttpContext.User对象进行验证授权.
\n
l 使用应用程序配置进行授权,只有具有指定角色的用户才能访问web.config所在的文件夹与子文件夹
\n
<authorization>
\n
<allow roles=”Admins”/>
\n
<deny users=”?”/>
\n
</authorization>
\n
l 使用PrinciplePermissionAttribute控制对类和方法的访问,只允许角色为Admins的成员才能调用该方法
\n
[System.Security.Permissions.PrincipalPermission(System.Security.Permissions.SecurityAction.Demand,Role=” Admins”)]
\n
public static bool MethodName()
\n
{
\n
…
\n
}
\n
l 以编程方式使用PrinciplePermission类控制对代码块的访问,只允许角色为Admins的成员调用Demand之后的代码
\n
public static bool MethodName()
\n
{
\n
System.Security.Permissions.PrincipalPermission perm = new System.Security.Permissions.PrincipalPermission(null, “Admins”);
\n
perm.Demand();
\n
…
\n
}
\n
l 使用Iprincipal.IsInRole方法,只允许角色为Admins的成员运行ｉｆ中的代码,大部分情况我们都使用这种方法判断用户是否有权限.
\n
public static bool MethodName()
\n
{
\n
if (HttpContext.Current.User.IsInRole(“Admins”))
\n
{
\n
//some code
\n
}
\n
}
\n
针对以上的特点,程序员必须在合适的地方创建HttpContext.User对象,以达到验证模型的要求.开发人员必须编写HttpApplication:: AuthenticateRequest事件.该事件的发生代表着用户己经通过Forms身份验证.
\n
在Global.asax中实现Application_AuthenticateRequest.
\n
protected void Application_AuthenticateRequest(Object sender, EventArgs e)
\n
{
\n
HttpApplication app = (HttpApplication)sender;
\n
HttpCookie cookie = Request.Cookies[FormsAuthentication.FormsCookieName];
\n
if (cookie != null)
\n
{
\n
string encryptedTicket = cookie.Value;
\n
FormsAuthenticationTicket ticket = FormsAuthentication.Decrypt(encryptedTicket);
\n
//获取在登录验证时加入验证票据的用户所拥有的角色,但真正开发时请不这样做,建议从数据库中获取该用户角色信息.
\n
//因为Cookie本身有长度的限制,并且将用户角色存储到客户端也不是安全的行为.
\n
//大家想想如果Cookie不限制大小,那么它的尺寸大到几MB或GB时,客户端与服务器的每一次通迅,将是怎样的一种情况了,呵呵.
\n
//这里仅展示如何将角色信息加入到用户主体GenericPrincipal中.
\n
string[] roles = ticket.UserData.Split(new char[] { ‘,’ });//获取角色
\n
FormsIdentity identity = new FormsIdentity(ticket);
\n
System.Security.Principal.GenericPrincipal user = new System.Security.Principal.GenericPrincipal(identity, roles);
\n
app.Context.User = user;
\n
//app.Context.User = new System.Security.Principal.GenericPrincipal(new System.Web.Security.FormsIdentity(FormsAuthentication.Decrypt(cookie.Value)), new string[]{“Admins”});
\n
}
\n
}
\n
或者在Global.asax中实现FormsAuthentication_Authenticate效果是一样的.
\n
void FormsAuthentication_OnAuthenticate(object sender, FormsAuthenticationEventArgs e)
\n
{
\n
HttpCookie cookie = Request.Cookies[FormsAuthentication.FormsCookieName];
\n
if (cookie != null)
\n
{
\n
string encryptedTicket = cookie.Value;
\n
FormsAuthenticationTicket ticket = FormsAuthentication.Decrypt(encryptedTicket);
\n
string[] roles = ticket.UserData.Split(new char[] { ‘,’ });
\n
FormsIdentity identity = new FormsIdentity(ticket);
\n
System.Security.Principal.GenericPrincipal user = new System.Security.Principal.GenericPrincipal(identity, roles);
\n
e.Context.User = user;
\n
}
\n
}
\n
其实FormsAuthenticationModule会自动生成一个User对象,只不过这个对象的角色列表为空,它只能是代表通过身份验证,而不能通过授权,因为我们限制了目录的访问角色,所以开发人员必须实现上面代码,才能满足我们的要足,如果说你的网站仅需要通过身份验证的话,就可不必实现这些方法了.
\n
用户在请求URL时,ASP.NET请求通道会连续触发一堆的事件,这些事件完成了一系列任务,其中就包括Forms身份验证事件与授权事件.如下所示:
\n
BeginRequest 请求开始事件
\n
AuthenticateRequest 验证通过事件 (上面两段代码就是在这个事件中被执行)
\n
PostAuthenticateRequest 用户标识己建立时发生 ASP.NET 2.0引入的事件,后面会讲到.
\n
AuthorizeRequest 当安全模块已验证用户授权时发生
\n
….其它事件略;
\n
正是这些事件的垒加促成了ASP.NET框架验证模型的实现, 而且通过完成上面的几个步骤,网站内容就己经受到授权机制的保护了.
\n
下面让我们看看ASP.NE安全模型是如何做到授权的.
\n
l ASP.NET 1.1 安全模型验证授权的原理
\n
在 ASP.NET 中,有两种方式限制对资源访问的权限：文件授权与URL 授权,这里我们仅讨伦后者.
URL 授权由 UrlAuthorizationModule 执行,它将用户和角色映射到 ASP.NET 应用程序中的 URL.这个模块可用于有选择地允许或拒绝特定用户或角色对应用程序的任意部分（通常在web.config文件中为目录指定授权用户或角色）的访问权限.
\n
HTTP模块是在ASP.NET框架默认应用程序配置文件中注册的,如下：
\n
\n
下面简单分析UrlAuthorizationModule的源码,便可了解验证模型是如何验证在web.config中指定的授权规则.
\n
UrlAuthorizationModule在应用程序初始化时向HttpApplication::AuthorizeRequest事件(安全模块已验证用户授权时发生)注册委托代码,该代码内部调用AuthorizationConfig::IsUserAllowed.方法实现截图如下：
\n
\n
上面代码又调用了AuthorizationConfigRule::IsUserAllowed方法,截图如下:
\n
\n
由于HttpApplication::AuthorizeRequest事件是在HttpApplication::AuthenticateRequest事件之后执行的(请看我提到过的事件列表), 在前面介绍的AuthenticateRequest事件中我们修改了Context.User对象,而且加入了角色信息,所以AuthorizeRequest事件在验证用户的权限时发现Context.User对象中什么都有,所以它才允许用户访问请求的资源,否则请求将被返回到指定的页面.以上就是ASP.NET1.1的原理,怎么样你理解了吗?
\n
ASP.NET2.0你仍可以用这样的机制,但又增加新特性.下面就看看在ASP.NET2.0中是如何实现的吧!
\n
ASP.NET 2.0 实现方式
\n
ASP.NET2.0的实现方式与ASP.NET1.1实现方式大同小异,同样支持前一版本的安全模型.不过又新增了成员资格与角色管理授权模型.这里就介绍ASP.NET2.0新增的内容.
\n
\n
l 应用程序配置新增属性
\n
<system.web>
\n
<authentication mode=”Forms”>
\n
//defaultUrl是ASP.NET2.0版本新增的属性, 在验证模型重定向URL时将重定向到的URL.默认值为”default.aspx”.
\n
//虽然ASP.NET1.1版本没有该属性,但程序中的默认为”default.aspx”.还是ASP.NET2.0的配置更为灵活.
\n
<forms loginUrl=”logon.aspx” protection=”All” name=”.ASPXFORMSAUTH” path=”/” defaultUrl=”Index.aspx”></forms>
\n
</authentication>
\n
<authorization>
\n
<deny users=”?” />/*匿名用户*/
\n
</authorization>
\n
</system.web>
\n
l 使用成员资格验证登录
\n
ASP.NET 成员资格主要用于ASP.NET Forms 身份验证,配合ASP.NET2.0登录控件可以不用写任何代码就能实现Forms身份验证.
\n
首先创建登录页Login.aspx,将登录控件托入到窗体中即可,不用写任何登录事件代码,相比ASP.NET1.1节省时间不是一点半点.
\n
l 使用角色管理进行访问授权
\n
角色管理可以帮助您管理授权,使您能够指定应用程序中的用户可访问的资源.角色管理可让您通过将用户分配到相应角色来对其进行分组,从而更容易控制访问权限.
\n
1. 启用角色管理
\n
要启用该功能,修改web.config文件在<system.web>配置节点内增加子节点如下:
\n
<roleManager enabled=”true” cacheRolesInCookie=”true” />
\n
cacheRolesInCookie属性代表是否缓存角色信息,这样不用每次都从数据库中获取角色,以提高应用程序的性能.
\n
但是将角色放在Cookie里总是风险的,它可能被篡改,然后用它访问未被授权的资源.
\n
不过可以在用户每次登录时,先使用Role API的DeleteCookie方法删除这个缓存Cookie, 这样可使风险小一点.
\n
推荐代码:
\n
if(Membership.ValidateUser(username, password)){
\n
Roles.DeleteCookie();
\n
FormsAuthentication.RedirectFromLoginPage(username, false);
\n
}
\n
特别提示:应用程序配置中当角色管理可用并且提供者程序为AspNetSqlProvider时, SqlRoleProvider的GetRolesForUser方法会调用System.Web.DataAccess.SqlConnectionHelper类的私有静态方法EnsureSqlExpressDBFile创建一个空的aspnetdb.mdf本地数据库,该数据库包含成员资格与角色管理,所需要的表结构等信息.
\n
2. 配置成员与角色
\n
使用VS2008自带的配置工具设定成员与角色是最简单不过的了,点击菜单栏中的[项目],下拉菜单的最后一项[ASP.NET配置],在弹出窗体中设置成员与角色关系.如下图展示:
\n
\n
在安全选项卡内有管理用户与角色的内容,如下图:
\n
\n
本示例创建了一个用户”iori”与一个角色”Admins”,并且指定了该用户是Admins角色的成员.
\n
另外该工具还会自动创建本地数据库(如果还没创建).与它相关的配置在machine.config文件中指定,如下图所示,你可以更改数据库的文件名,默认为”aspnetdb.mdf”.
\n
\n
\n
好了,通过完成上面的几个步骤,网站内容就己经受到授权机制的保护了,可以用刚刚添加的用户试试登录吧.
\n
相比上一版本,ASP.NET2.0在Forms身份验证里为开发人员节省很多时间,几乎不用开发人员写任何代码,方便了许多,下面让我们一探究竟.
\n
\n
l ASP.NET 2.0 安全模型验证授权的原理
\n
1. 验证原理
\n
在.net1.1中开发人员必须为登录页编写登录事件,用来验证用户输入的用户名与密码是否有效,而ASP.NET 2.0中引入了成员资格提供程序与标准登录服务器控件,它们隐式使用Forms 身份验证,登录控件己经包含了验证用户名的程序逻辑,也就是说登录控件会把用户输入的用户名与密码自动与成员资格数据库中的用户进行匹配,如果成功匹配就将特定Cookie写入客户端.
\n
2. 授权原理
\n
还是拿UrlAuthorizationModule说事儿, 如果不启用角色管理,实现方式与ASP.NET1.1差不多,不过由于ASP.NET2.0加入了角色管理模型,角色管理模型使用两个类: RolePrincipal与RoleManagerModule来实现角色授权.如果应用程序配置的角色管理可用时,这两个新对象将被应用到aspx页面的生命周期中, 由于RoleManagerModule 被初始化时会向HttpApplication对象的事件PostAuthenticateRequest加载委托代码,该代码会将app.Context.User对象包装成RolePrincipal对象.
\n
PostAuthenticateRequest事件是在ASP.NET 2.0中加入的,该事件发生在AuthenticateRequest事件之后,代表安全模块已建立了用户标识,所以在这个事件中使用用户标识重新生成RolePrincipal对象.
\n
下面为委托代码的节选.
\n
……//省略若干代码
\n
HttpApplication application = (HttpApplication) source;
\n
HttpContext context = application.Context;
\n
if (this._eventHandler != null)
\n
{
\n
RoleManagerEventArgs e = new RoleManagerEventArgs(context);
\n
this._eventHandler(this, e);
\n
if (e.RolesPopulated)
\n
{
\n
//判断开发人员是否在Global.asax中写了事件处理程序,如下显示的代码.
\n
/*
\n
//这里演示如何在Global.asax中自定义角色
\n
void RoleManager_GetRoles(object sender, RoleManagerEventArgs e)
\n
{
\n
if (e.Context.Request.IsAuthenticated)
\n
{
\n
e.Context.User = new GenericPrincipal(new GenericIdentity(e.Context.User.Identity.Name), new string[] { “Admins” });
\n
e.RolesPopulated = true;
\n
}
\n
}
\n
*/
\n
//如果e.RolesPopulated为真,代表开发人员自己创建了角色信息,
\n
//RoleManagerModule就不会 生成RolePrincipal 对象了.
\n
return;
\n
}
\n
}
\n
……
\n
if (!(context.User is RolePrincipal))
\n
{
\n
context.User = new RolePrincipal(context.User.Identity);
\n
}
\n
Thread.CurrentPrincipal = context.User;
\n
\n
注意:我们并没有像ASP.NET1.1中那样在AuthenticateRequest事件中生成User对象.但是User对象会在FormsAuthenticationModuleHTTP模块中使用Forms身份验证的特定Cookie重新被包装成一个GenericPrincipal对象(角色为空).
\n
在说明RolePrincipal对象有什么用之前,需要了解这个对象是何时被用到的.
在UrlAuthorizationModule被初始化时中向HttpApplication对象注册的事件AuthorizeRequest被触发.
在这个事件中会调用RolePrincipal对象(就是Context.User)的方法IsInRole, IsInRole方法会自动查找角色提供程序(本示例使用默认提供程序AspNetSqlProvider,数据库为前面自动生成的ASPNETDB.MDF),并验证用户角色,代码截图如下:
\n
而IsUserAllowed方法最终会调用RolePrincipal对角的IsInRole方法来判断当前用户是否拥有某角色,方法截图如下:
\n
\n
以上这些便是ASP.NET2.0成员资格与角色管理实现Forms身份验证的原理与实现,不过默认的成员资格与角色数据库的字段一般并不能满足具体项目的需要.好在ASP.NET 2.0中提供了可扩展提拱程序模型,开发人员可以定制成员资格提供程序与角色管理模型.
\n
结束语
\n
网站应用程序的身份验证和授权方法是一项具有挑战性的任务,而Forms身份验证在网站建设中提供了重要的安全性优势,通过提供用户配置文件以及对角色的支持, 简化了程序员通常需要编写大量代码才能完成的工作.如果读者还有什么问题或者对以上描述有不同的见解,欢迎与我联系互相交流!
\n
附件：AuthenticationVer2003.rar AuthenticationVer2008.rar
\n\n