.NET Web的身份认证

Posted 2020-06-17

    百度一下”asp.net身份认证“，你会得到很多相关的资料，这些资料通常上来就会介绍诸如”Form认证“”Windows认证“等内容，而没有给出一个完整的流程。初学者对此往往一头雾水，我也曾经被坑过很多回，于是写下此文，算是复习。

    现代的Windows Server系统都是基于严格的用户机制的，当你想操作服务器时肯定需要账号密码验证的。当我们把开发好的Web应用程序部署在服务器后，用户通过浏览器访问该站点，实际上就是该用户通过HTTP操作这台服务器的过程，本质上也是用户操作服务器（至少是读）的过程。这就产生了一个被大多数人忽略的问题：网络用户根本不知道服务器的账号密码，怎么会有读写服务器的权限？答案可以用下面一个简单的图给出：

              

   

         用户发起一个请求后，授权主要经历IIS阶段和ASP.NET阶段。经过IIS时会得到系统账号相关权限标识（或票据），使用该标识进入站点，这是asp.net运行时会把该标识转化成.NET的一个用户实体对象，我们就可以在自己的代码中对该实体进行处理。通过一个具体的实例来认识一下，首先我们新建一个【不进行身份认证】的MVC项目（WebForm项目亦可），为了方便描述，就叫WebAuth吧！

        项目默认有HomeController和三个Action：Index/About/Contact。编译生成，并把它部署到iis上，为了方便我直接部署成http://localhost。就从这里开始身份认证之旅吧！

IIS阶段

一、匿名身份认证

        一般公司或个人开发ASP.NET的网站用的都是这种方式。比如刚刚部署的Web，我们在IIS的功能视图中打开身份验证：

        可以看到默认的就是匿名身份认证。这种情况下不需要任何的认证，我们就可以访问服务器上的内容。之所以能这么方便的访问服务器的内容，是因为IIS在后台帮我们做了很多事情。当我们安装IIS时，安装程序会自动创建 IUSR_ComputerName 帐户（其中 ComputerName 是正在运行 IIS的电脑名称），普通用户使用浏览器访问该站点时，就是直接使用这个账号来操作服务器。我们在开发过程中常常碰到读写服务器某文件没有权限，这时百度一下，都会告诉你要修改IUSR_Computername用户权限，就是这个原因。

二、基本身份认证

        不修改任何代码。我们在IIS中禁用”匿名身份认证“，启用”基本身份认证“，这时我们再访问项目的项目中的时，浏览器会弹出一个对话框要求用户输入自己的用户名和密码,如下图：

        这个账号必须是服务器系统的账号，且拥有对站点根目录读（写）的权限。可以在目录的文件夹属性->安全性上设置。我专门添加了个账号test，如下：

        返回浏览器，输入用户名test和设置的密码即可访问项目的所有页面。在不需要复杂用户逻辑的项目中使用该方法，可以不用修改任何代码实现认证。

        不过基本身份认证有个非常严重的安全问题，通过这种方式的用户名和密码都以明文形式在网络间进行发送，很容易被拦截获取。而且要知道这个账号可是服务器的账号！可以用SSL加密来解决这个问题。

三、摘要式身份认证

        摘要式身份验证提供与基本身份验证相同的功能，即当用户访问http://localhost 时同样弹出输入账号和密码的对话框。但是这种认证方式在通过网络发送用户凭据方面提高了安全性。具体流程如下：

1. 客户从运行 IIS 的服务器请求文件。
2. IIS 拒绝请求，告诉给客户端正在使用摘要式身份验证，并发送领域名称。
3. Internet Explorer 提示用户输入凭据（用户名和密码）。然后，Internet Explorer 合并这些凭据和领域名称以创建一个 MD5 哈希，并从运行 IIS 的服务器重新提交文件请求，此时发送的是 MD5 哈希。
4. 运行 IIS 的服务器接收哈希，并将客户端的哈希发送到域控制器以进行验证。
5. 域控制器向运行 IIS 的服务器通知验证结果。
6. 如果客户端已经过身份验证，则 IIS 将请求的文档或数据发送到客户端。

这里特别注意一下：什么是Active Directory？它就是一个普通的Windows服务，通过数据库把系统的网络对象信息存储起来，比如系统的账号，用户组，共享资源等。可以方便使用者方便的查找和使用这些信息。

四 Windows身份认证

        同上，这种认证方式对于客户端用户来说和基本认证并没有什么区别，但实际上它比基本认证要复杂的多。这种方式在通过网络发送用户名和密码之前，先将它们进行哈希计算。当启用集成 Windows 身份验证时，用户的浏览器通过与 Web 服务器进行密码交换（包括哈希）来证明其知晓密码。集成 Windows 身份验证是 Windows Server 2003 家族成员中使用的默认验证方法。

        Windows 身份认证主要有两种方式：NTLM 方式和Kerberos V5。如果在 Windows 2000 或更高版本域控制器上安装了 Active Directory 服务，并且用户的浏览器支持 Kerberos v5 验证协议，则使用 Kerberos v5 验证，否则使用 NTLM 验证。这两种方式的详细讲解可参考A大的这篇文章：http://www.cnblogs.com/artech/archive/2011/01/24/kerberos.html

asp.net阶段

       上面四种是IIS服务器提供的验证方式，当用户通过IIS的用户验证后，就可以得到一个Windows的身份，这个身份将会被传到我们自己的项目WebAuth中。打开工程的Web.config文件，有一项authentication配置：

<authenticationmode="Windows"/>

        这里的Windows和IIS里的Windows身份认证不同。这里指将IIS获取的Windows用户直接传到网站中使用，可以在index.cshtml中添加以下代码访问：

当前登录状态:@Request.IsAuthenticated<br/>
当前登录用户:@User.Identity.Name

        IIS使用匿名认证以外的任何带输入框的认证，效果如下：

        通常情况这种方式并没什么卵用，绝大多说情况我们的IIS都只用“匿名身份认证”方式。然后在自己的站点里开发自己的用户逻辑，将authentication的mode设置为forms，即我们耳熟能详的Form认证。

        Form认证的核心原理很简单，用户在请求信息中携带自己的身份证明（用户名&密码），站点验证通过后，向用户颁发一张证明身份的票据，客户端通过Cookie的方式来存储这个票据，在以后的请求中，通过在请求中附带票据来证明身份。园子里有位大神通过以系列的实例讲的非常清楚：http://www.cnblogs.com/fish-li/archive/2012/04/15/2450571.html，微软官方为Form认证提供了全方位的支持与扩展----Membership及Identity！关于这两种方式，腾飞兄在他的博客里面讲解的也非常详细：http://www.cnblogs.com/jesse2013/p/membership.html