ASP.NET Form身份验证方式详解

注：不会涉及ASP.NET的登陆系列控件以及membership的相关话题， 我只想用比较原始的方式来讲明在ASP.NET中是如何实现身份认证的过程。　

  ASP.NET身份认证基础

　　在开始今天的博客以前，我想有二个最基础的问题首先要明确：

　　1. 如何判断当前请求是一个已登陆用户发起的?

　　2. 如何获取当前登陆用户的登陆名?

　　在标准的ASP.NET身份认证方式中，上面二个问题的答案是：

　　1. 若是Request.IsAuthenticated为true，则表示是一个已登陆用户。

　　2. 若是是一个已登陆用户，访问HttpContext.User.Identity.Name可获取登陆名(都是实例属性)。

 

　ASP.NET身份认证过程

　　在ASP.NET中，整个身份认证的过程其实可分为二个阶段：认证与受权。

　　1. 认证阶段：识别当前请求的用户是否是一个可识别(的已登陆)用户。

　　2. 受权阶段：是否容许当前请求访问指定的资源。

　　这二个阶段在ASP.NET管线中用AuthenticateRequest和AuthorizeRequest事件来表示。

　　在认证阶段，ASP.NET会检查当前请求，根据web.config设置的认证方式，尝试构造HttpContext.User对象供咱们在后续的处理中使用。 在受权阶段，会检查当前请求所访问的资源是否容许访问，由于有些受保护的页面资源可能要求特定的用户或者用户组才能访问。 因此，即便是一个已登陆用户，也有可能会不能访问某些页面。 当发现用户不能访问某个页面资源时，ASP.NET会将请求重定向到登陆页面。

　　受保护的页面与登陆页面咱们均可以在web.config中指定，具体方法可参考后文。

　　在ASP.NET中，Forms认证是由FormsAuthenticationModule实现的，URL的受权检查是由UrlAuthorizationModule实现的。

　   1. 登陆：调用FormsAuthentication.SetAuthCookie()方法，传递一个登陆名便可。

　　2. 注销：调用FormsAuthentication.SignOut()方法。

 

　保护受限制的页面

　　为了保护受限制的页面的访问，ASP.NET提供了一种简单的方式： 能够在web.config中指定受限资源容许哪些用户或者用户组(角色)的访问，也能够设置为禁止访问。

　　好比，网站有一个页面：MyInfo.aspx，它要求访问这个页面的访问者必须是一个已登陆用户，那么能够在web.config中这样配置：

<location path="MyInfo.aspx">
   <system.web>
     <authorization>
        <deny users="?"/>
     </authorization>
   </system.web>
</location>

 为了方便，我可能会将一些管理相关的多个页面放在Admin目录中，显然这些页面只容许Admin用户组的成员才能够访问。 对于这种状况，咱们能够直接针对一个目录设置访问规则：

<location path="Admin">
<system.web>
<authorization>
<allow roles="Admin"/>
<deny users="*"/>
</authorization>
</system.web>
</location>

这样就没必要一个一个页面单独设置了，还能够在目录中建立一个web.config来指定目录的访问规则。在前面的示例中，有一点要特别注意的是：

1. allow和deny之间的顺序必定不能写错了，UrlAuthorizationModule将按这个顺序依次判断。

2. 若是某个资源只容许某类用户访问，那么最后的一条规则必定是在allow和deny的配置中，咱们能够在一条规则中指定多个用户：

　　1. 使用users属性，值为逗号分隔的用户名列表。

　　2. 使用roles属性，值为逗号分隔的角色列表。

　　3. 问号 (?) 表示匿名用户。

　　4. 星号 (*) 表示全部用户。

在ASP.NET内部，当发现是在访问登陆面时，会设置HttpContext.SkipAuthorization = true (实际上是一个内部调用)， 这样的设置会告诉后面的受权检查模块：跳过此次请求的受权检查。所以，登陆页老是容许全部用户访问，可是登陆页所引用的CSS文件以及JS文件（页面在访问CSS, JS文件时，实际上是被重定向到登陆页面了） 是在另外的请求中发生的，那些请求并不会要跳过受权模块的检查。

　　为了解决登陆页不能正确显示的问题，咱们能够这样处理：

　　1. 在网站根目录中的web.config中设置登陆页所引用的JS, CSS文件都容许匿名访问。

　　2. 也能够直接针对JS, CSS目录设置为容许匿名用户访问。

　　3. 还能够在CSS, JS目录中建立一个web.config文件来配置对应目录的受权规则。可参考如下web.config文件：

<?xml version="1.0"?>
<configuration>
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</configuration>

注意：在IIS中看到的状况就和在Visual Studio中看到的结果就不同了。由于，像js, css, image这类文件属于静态资源文件，IIS能直接处理，不须要交给ASP.NET来响应，所以就不会发生受权检查失败， 因此，若是这类网站部署在IIS中，看到的结果又是正常的。

 

认识Forms身份认证

HTTP是一个无状态的协议， 在开发WEB应用程序时，咱们一般会使用Cookie来保存一些简单的数据供服务端维持必要的状态。如下是我用FireFox所看到的Cookie列表：

　　

　　这个名字：LoginCookieName，是在web.config中指定的：

<authentication mode="Forms" >
<forms cookieless="UseCookies" name="LoginCookieName" loginUrl="~/Default.aspx"></forms>
</authentication>

理解Forms身份认证

为了实现安全性，ASP.NET采用【Forms身份验证凭据】(即FormsAuthenticationTicket对象)来表示一个Forms登陆用户， 加密与解密由FormsAuthentication的Encrypt与Decrypt的方法来实现。

　　用户登陆的过程大体是这样的：

　　1. 检查用户提交的登陆名和密码是否正确。

　　2. 根据登陆名建立一个FormsAuthenticationTicket对象。

　　3. 调用FormsAuthentication.Encrypt()加密。

　　4. 根据加密结果建立登陆Cookie，并写入Response。

　　在登陆验证结束后，通常会产生重定向操做， 那么后面的每次请求将带上前面产生的加密Cookie，供服务器来验证每次请求的登陆状态。

每次请求时的(认证)处理过程以下：

　　1. FormsAuthenticationModule尝试读取登陆Cookie。

　　2. 从Cookie中解析出FormsAuthenticationTicket对象。过时的对象将被忽略。

　　3. 根据FormsAuthenticationTicket对象构造FormsIdentity对象并设置HttpContext.User

　　4. UrlAuthorizationModule执行受权检查。

　　在登陆与认证的实现中，FormsAuthenticationTicket和FormsAuthentication是二个核心的类型， 前者能够认为是一个数据结构，后者可认为是处理前者的工具类。

UrlAuthorizationModule是一个受权检查模块，其实它与登陆认证的关系较为独立， 所以，若是咱们不使用这种基于用户名与用户组的受权检查，也能够禁用这个模块

　　因为Cookie自己有过时的特色，然而为了安全，FormsAuthenticationTicket也支持过时策略， 不过，ASP.NET的默认设置支持FormsAuthenticationTicket的可调过时行为，即：slidingExpiration=true 。 这两者任何一个过时时，都将致使登陆状态无效。

　　FormsAuthenticationTicket的可调过时的主要判断逻辑由FormsAuthentication.RenewTicketIfOld方法实现，代码以下：

public static FormsAuthenticationTicket RenewTicketIfOld(FormsAuthenticationTicket tOld)
{
// 这段代码是意思是：当指定的超时时间逝去大半时将更新FormsAuthenticationTicket对象。

if( tOld == null ) 
return null;

DateTime now = DateTime.Now;
TimeSpan span = (TimeSpan)(now - tOld.IssueDate);
TimeSpan span2 = (TimeSpan)(tOld.Expiration - now);
if( span2 > span ) 
return tOld;

return new FormsAuthenticationTicket(tOld.Version, tOld.Name,
now, now + (tOld.Expiration - tOld.IssueDate),
tOld.IsPersistent, tOld.UserData, tOld.CookiePath);
}

View Code

 

在多台服务器之间使用Forms身份认证（Passport单点身份验证）

　　默认状况下，ASP.NET 生成随机密钥并将其存储在本地安全机构 (LSA) 中， 所以，当须要在多台机器之间使用Forms身份认证时，就不能再使用随机生成密钥的方式，须要咱们手工指定，保证每台机器的密钥是一致的。

　　用于Forms身份认证的密钥能够在web.config的machineKey配置节中指定，咱们还能够指定加密解密算法：

<machineKey 
decryption="Auto" [Auto | DES | 3DES | AES]
decryptionKey="AutoGenerate,IsolateApps" [String]
/>

Passport单点身份验证：（<machineKey validationKey="5029E82E1779497186D46F83D78FAD07" decryptionKey="82B8397DB5B4443FB035083EB662CD98" 

validation="SHA1" decryption="Auto" />）

             1：获取机器key 生成密钥

             2：在要实现单点登录的项目根web.config中添加密钥;

a) 两个项目Web.cinfig的<machineKey> 节点确保如下几个字段彻底同样：validationKey 、decryptionKey 、validation 
b) 两个项目的 Cookie 名称必须相同，也就是 <forms> 中的 name 属性，这里咱们把它统一为 name ="UserLogin" 
c) 注意区分大小写 
d) 登录页面整合到统一登录点登录   好比：loginUrl="www.wf.com/login.aspx", 在登录页面发放验证票    

 

在客户端程序中访问受限页面

　　有时咱们须要用代码访问某些页面，好比：但愿用代码测试服务端的响应。

　　若是是简单的页面，或者页面容许全部客户端访问，这样不会有问题， 可是，若是此时咱们要访问的页面是一个受限页面，那么就必须也要像人工操做那样： 先访问登陆页面，提交登陆数据，获取服务端生成的登陆Cookie， 接下来才能去访问其它的受限页面(但要带上登陆Cookie)。

在前面的示例中，我已在web.config为MyInfo.aspx设置过禁止匿名访问，若是我用下面的代码去调用：

private static readonly string MyInfoPageUrl = "http://localhost:51855/MyInfo.aspx";

static void Main(string[] args)
{
// 这个调用获得的结果实际上是default.aspx页面的输出，并不是MyInfo.aspx
HttpWebRequest request = MyHttpClient.CreateHttpWebRequest(MyInfoPageUrl);
string html = MyHttpClient.GetResponseText(request);

if( html.IndexOf("<span>Fish</span>") > 0 )
Console.WriteLine("调用成功。");
else
Console.WriteLine("页面结果不符合预期。");
}

View Code

　　此时，输出的结果将会是：页面结果不符合预期。

 　若是我用下面的代码：

private static readonly string LoginUrl = "http://localhost:51855/default.aspx";
private static readonly string MyInfoPageUrl = "http://localhost:51855/MyInfo.aspx";

static void Main(string[] args)
{
// 建立一个CookieContainer实例，供屡次请求之间共享Cookie
CookieContainer cookieContainer = new CookieContainer();

// 首先去登陆页面登陆
MyHttpClient.HttpPost(LoginUrl, "NormalLogin=aa&loginName=Fish", cookieContainer);

// 此时cookieContainer已经包含了服务端生成的登陆Cookie

// 再去访问要请求的页面。
string html = MyHttpClient.HttpGet(MyInfoPageUrl, cookieContainer);

if( html.IndexOf("<span>Fish</span>") > 0 )
Console.WriteLine("调用成功。");
else
Console.WriteLine("页面结果不符合预期。");

// 若是还要访问其它的受限页面，能够继续调用。
}

View Code

　　此时，输出的结果将会是：调用成功。

　　说明：在改进的版本中，我首先建立一个CookieContainer实例， 它能够在HTTP调用过程当中接收服务器产生的Cookie，并能在发送HTTP请求时将已经保存的Cookie再发送给服务端。 在建立好CookieContainer实例以后，每次使用HttpWebRequest对象时， 只要将CookieContainer实例赋值给HttpWebRequest对象的CookieContainer属性，便可实如今屡次的HTTP调用中Cookie的接收与发送， 最终能够模拟浏览器的Cookie处理行为，服务端也能正确识别客户的身份。