Windows身份认证

　　要使用Windows身份认证模式，需要在web.config设置：

　　的默认认证方式，与Forms身份认证在许多基础方面是一样的。 上篇博客我说过：的身份认证的最核心部分其实就是HttpContext.User这个属性所指向的对象。 在接下来的部分，我将着重分析这个对象在二种身份认证中有什么差别。

　　身份认证过程中，IPrincipal和IIdentity这二个接口有着非常重要的作用。前者定义用户对象的基本功能，后者定义标识对象的基本功能，不同的身份认证方式得到的这二个接口的实例也是不同的。

　　 Windows身份认证是由WindowsAuthenticationModule实现的。 WindowsAuthenticationModule管线的AuthenticateRequest事件中，使用从IIS传递到的Windows访问令牌(Token)创建一个WindowsIdentity对象，Token通过调用context.WorkerRequest.GetUserToken()获得，然后再根据WindowsIdentity 对象创建WindowsPrincipal对象，然后把它赋值给HttpContext.User。

　　在Forms身份认证中，我们需要创建登录页面，让用户提交用户名和密码，然后检查用户名和密码的正确性，接下来创建一个包含FormsAuthenticationTicket对象的登录Cookie供后续请求使用。 FormsAuthenticationModule管线的AuthenticateRequest事件中，解析登录Cookie并创建一个包含FormsIdentity的GenericPrincipal对象，然后把它赋值给HttpContext.User。

　　上面二段话简单了概括了二种身份认证方式的工作方式。

　　我们可以发现它们存在以下差别：

　　1. Forms身份认证需要Cookie表示登录状态，Windows身份认证则依赖于IIS

　　2. Windows身份认证不需要我们设计登录页面，不用编写登录验证逻辑，因此更容易使用。

　　在授权阶段，UrlAuthorizationModule仍然会根据当前用户检查将要访问的资源是否得到许可。接下来，FileAuthorizationModule检查 HttpContext.User.Identity 属性中的 IIdentity 对象是否是 WindowsIdentity 类的一个实例。如果 IIdentity 对象不是 Windo wsIdentity 类的一个实例，则 FileAuthorizationModule 类停止处理。如果存在 WindowsIdentity 类的一个实例，则 FileAuthorizationModule 类调用 AccessCheck Win32 函数(通过 P/Invoke)来确定是否授权经过身份验证的客户端访问请求的文件。如果该文件的安全描述符的随机访问控制列表 (DACL) 中至少包含一个 Read 访问控制项 (ACE)，则允许该请求继续。否则，FileAuthorizationModule 类调用 HttpApplication.CompleteRequest 方法并将状态码 401 返回到客户端。

　　在Windows身份认证中，验证工作主要是由IIS实现的，WindowsAuthenticationModule其实只是负责创建WindowsPrincipal和WindowsIdentity而已。顺便介绍一下：Windows 身份验证又分为“NTLM 身份验证”和“Kerberos v5 身份验证”二种，关于这二种Windows身份认证的更多说明可查看MSDN技术文章：解释： 2.0 中的 Windows 身份验证。在我看来，IIS最终使用哪种Windows身份认证方式并不影响我们的开发过程，因此本文不会讨论这个话题。

　　根据我的实际经验来看，使用Windows身份认证时，主要的开发工作将是根据登录名从Active Directory获取用户信息。因为，此时不需要我们再设计登录过程，已经为我们准备好了WindowsPrincipal和WindowsIdentity这二个与用户身份相关的对象。

　　访问 Active Directory

　　我们通常使用LDAP协议来访问Active Directory， framework中提供了DirectoryEntry和DirectorySearcher这二个类型让我们可以方便地从托管代码中访问 Active Directory 域服务。