ASP.NET的身份验证

ASP.NET的身份验证分两种形式：“Windows身份验证”与“Forms身份验证”。其实可以这样粗略的理解验证过程：

 

 

所谓ASP.NET的“Windows身份验证”方式，其实就是ASP.NET自身并不对请求做任何身份验证，所有通过IIS验证的请求将直接获得资源。

ASP.NET的“Forms身份验证”是指对通过IIS验证的请求，编写代码提取请求中的身份信息，并与合法的身份信息集合比对，如能找到匹配，则验证通过，否则不通过。在这里，请求中的身份信息来源于用户在网页中的表单内的输入，因此而得名。

关键代码分析：

FormsAuthentication..::.Authenticate 方法：

public static bool Authenticate(

         string name,

         string password

)

MSDN对此方法的解释：“对照存储在应用程序配置文件中的凭据来验证用户名和密码。”。对此我相当困惑，难道ASP.NET认为所有的用户信息应该保存在配置文件中？那如果需要添加或删除用户就应该编写程序读取和修改配置文件，对吗？如果有成百上千个用户，那将会是一个相当壮观的配置文件了。结论：这是一个没有价值的方法。实际上用户信息总是保存在数据库中（而不是配置文件中），需要另外编写代码通过访问数据库来验证身份合法性。

FormsAuthentication..::.RedirectFromLoginPage 方法的一个重载：

public static void RedirectFromLoginPage(

         string userName,

         bool createPersistentCookie,

         string strCookiePath

)

MSDN对此方法的解释：“使用 Forms 身份验证 Cookie 的指定 Cookie 路径，将经过身份验证的用户重定向回最初请求的 URL 或默认 URL。”。实际上这个方法相当关键，除了重定向外，它还有两个重要处理：

1、  它认可了身份信息；

2、  它缓存了身份信息；

在这个方法被执行后，在Cookie有效的范围内：

1、  对应用程序（或简言之“网站”）的所有资源请求都被ASP.NET认为合法；

2、  任何时候可以通过“Context.User.Identity.Name”属性访问当前用户名。

谈到这里暂且按下不表，让我们看看身份验证与权限判断的关系先。事物总是不断发展的，而且越来越复杂。如果一个身份经过了验证就可以访问应用的全部资源，这样很可怕。权限判断这样限制：对通过验证的身份，根据权限设定有选择的提供部分资源。权限设定信息与合法用户信息一样存储于数据库中。

总结一下，我们看到了这样一些事实：

1、  要求用户输入用户名与密码的身份验证（称之为“表单身份验证”）需要访问特定的数据库，这种技术需求很难由ASP.NET直接满足；

2、  权限设定信息与合法用户信息在数据库中联系非常密切。

所以在实战中往往会抛开ASP.NET的“Forms身份验证”（换言之，这只是某软强卖给开发人员的鸡肋），而完全由自己开发“表单身份验证”与“权限判断”。

    身份验证实现首先面临的核心问题是“将当前身份信息保存在哪里？”。一个严肃的系统设计员会仔细的思考并慎重的决定。下面给出笔者对Session与Cookie的选择指导：

1、  企业级的应用（满足企业业务需求，部署于企业内部网络中）由于处理的是敏感的业务问题并且机器暴露在办公室内，所以安全性要求很高，往往采用Session保存用户信息。当用户关闭浏览器时，Session中的信息会全部丢弃。

2、  商业网站（部署于互联网上，比如某某论坛）由于家庭用户使用居多，往往采用Cookie保存用户信息。当用户关闭浏览器后，一段时间内再次浏览网站不用重复输入用户信息。

3、  如果是涉及单点登录的大型应用，要求用一次登录访问多个应用，恕我才拙，留给读者自己思考吧。

    这篇文章的目的在于解读ASP.NET的身份验证技术，使初学者可以少走一些弯路，不要在一些没有价值的地方消耗过多的时间。一句话总结：抛开ASP.NET的“Forms身份验证”。