百度一下”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 时同样弹出输入账号和密码的对话框。但是这种认证方式在通过网络发送用户凭据方面提高了安全性。具体流程如下：
- 客户从运行 IIS 的服务器请求文件。
- IIS 拒绝请求，告诉给客户端正在使用摘要式身份验证，并发送领域名称。
- Internet Explorer 提示用户输入凭据（用户名和密码）。然后，Internet Explorer 合并这些凭据和领域名称以创建一个 MD5 哈希，并从运行 IIS 的服务器重新提交文件请求，此时发送的是 MD5 哈希。
- 运行 IIS 的服务器接收哈希，并将客户端的哈希发送到域控制器以进行验证。
- 域控制器向运行 IIS 的服务器通知验证结果。
- 如果客户端已经过身份验证，则 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