ad 单点登录 java 访问权限_AD 单点登录以及windows认证详细说明

上篇博客我谈到了一些关于ASP.NET Forms身份认证方面的话题，这次的博客将主要介绍ASP.NET Windows身份认证。

Forms身份认证虽然使用广泛，不过，如果是在 Windows Active Directory 的环境中使用ASP.NET， 那么使用Windows身份认证也会比较方便。 方便性表现为：我们不用再设计登录页面，不用编写登录验证逻辑。而且使用Windows身份认证会有更好的安全保障。

认识ASP.NET Windows身份认证

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

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

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

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

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

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

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

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

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

在授权阶段，UrlAuthorizationModule仍然会根据当前用户检查将要访问的资源是否得到许可。 接下来，FileAuthorizationModule检查 HttpContext.User.Identity 属性中的 IIdentity 对象是否是 WindowsIdentity 类的一个实例。 如果 IIdentity 对象不是 WindowsIdentity 类的一个实例，则 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技术文章：解释：ASP.NET 2.0 中的 Windows 身份验证。 在我看来，IIS最终使用哪种Windows身份认证方式并不影响我们的开发过程，因此本文不会讨论这个话题。

根据我的实际经验来看，使用Win