IIS 5 中的安全认证系统

IIS 5 中的安全认证系统

青苹果工作室

绪论
本文将讨论的内容是实现一个基于Internet的受保护应用程序，这种保护是用IIS5提供的安全选项实现的，包括：

安全的数据传输和完整性
客户端和服务器端的验证
IIS服务器验证和数据保护
X.509协议 (IETF 标准)是在Internet上使用的标准服务器验证机制，IIS当然也秉承了这个标准。这个协议是建立在一个验证权威机构签署的证书基础上的。

当客户要求服务器的验证时，Web服务器就将其证书发送给浏览器。如果能成功完成以下步骤，服务器验证就算成功了：

客户浏览器信任所提供证书的证明机构的签署。
客户使用证明机构的公共关键字来打开证书，然后验证证书内的公共名称与浏览器正在指向的 URL是否相匹配。
客户验证证书没有过期。
最后浏览器可能会检查CRL(证书撤回列表)，它的URL包含在证书内，看看证书是否在失效期之前被收回。

如果客户端接受了服务器的证书，那么就将开始安全Sockets层（SSL）协议的握手阶段，以建立起受保护的数据传输。SSL协议是一种基于会话（session）关键字的私用关键字算法。

在握手阶段，客户向服务器发送一个session关键字，这个关键字是用服务器公共关键字加密的。只有知道相应的私用关键字的服务器才能对这个session关键字进行解密。当服务器和客户安全地共享session关键字后，通讯就可以在希望的保护中进行了。

基于证书的不对称加密法只局限于在握手阶段使用，这是因为象SSL的对称算法在加密和解密数据方面比不对称算法要有效得多。

请注意服务器证明和数据加密是紧密联系的。从理论上说，不进行服务器证明也能使用SSL，但是在实际中这种情况不会发生。以上所描述的证书和SSL通常指的是 HTTPS 协议。

IIS客户证明安全选项
IIS客户证明的全部内容就是映射身份，这个映射身份通过HTTP协议，在点击一个windows域中身负责验证的 web服务器时发生的。根据 IIS应用程序安全性的设置，为请求提供服务的IIS线程都会担当一个特定的身份，这样所有的访问检查，比如文件存取、ASP 脚本等等，都会参照这个线程身份进行，而不是参照IIS的程序身份。这种身份可以应用在以下访问检查中：

当请求HTML 或ASP页面时，在NTFS 驱动器上进行的文件系统访问检查。
在执行ASP脚本期间所要求的访问检查。
对标准和配置过的COM+ 组件的激活和访问检查。
对配置的COM+组件应用基于角色的安全。
使用Windows综合安全与SQL服务器相连接时，在ASP脚本内执行的数据库访问。
你可以为IIS应用程序定义下面5种可能的安全设置以提供客户证明：

Anonymous（匿名）：所有的请求都被映射到一个唯一域用户。默认的用户是 IUSR_ ，如果愿意也可以改变。
Basic（基本）：当你请求一个位于虚拟目录下、要求基本证明的资源时(HTML 或ASP页面)， 浏览器会提示你输入用户名和口令。IIS挑选出来完成这个请求的线程会用客户输入的信息试着登录到虚拟目录设置中定义的域上，这不一定是IIS服务器注册的那个。这个安全机制在IE和Netscape中能工作，但是有一个很大的缺点：用户口令是用明码发送的。通常这个问题是通过要求HTTPS 通讯来解决的。使用HTTPS这种方法，整个的通讯，包括口令，都是加密发送的。可以对 IIS线程进行配置，以执行对域的不同类型的登录。就是说，你可以指示IIS调用交互性LogonUser（默认值）、批登录或网络登录。
Digest (在IIS4下不可用)：这是基于一个挑战响应机制上的新标准安全协议，只在IE5 和IIS5上支持。Digest证明不太吸引人，因为Web服务器必须要位于PDC 上才能工作。
SPNEGO：这个Microsoft私有的证明协议在http上执行一个标准登录会话，就象你按ALT+CTRL+DEL一样，被要求输入一个用户名、一个口令以及域名。实际使用的协议要由NTLM 和Kerberos进行协商。使用Kerberos的情况是在Windows 2000 计算机上运行IE 5浏览器和在一个Windows 2000 域中注册的计算机上的运行IIS5 Web服务器。综合证明只在IE中支持，并且通过代理是不能工作的，因此它只能用在 Intranet 环境。
客户证书映射：配置一个虚拟目录在HTTPS连接上运行，你就可以通过客户证书指示 IIS要求客户证明。如果这样做了，那么当用户连接到虚拟目录时，会被要求提供一个证书，然后IIS采用1对1或多对1的方式，将这个证书映射到一个域帐户上。
有两种建立证书映射的方法：1、私有IIS 映射 2、活动目录 (AD)映射

默认状态下激活的是私有IIS映射。选中Windows 目录服务映射器单选框就可以切换到AD映射。
有两种类型的AD 映射：UPN (唯一主要名称)映射和明确映射。

前者是一种暗指的映射，是由Windows安全服务完成的，当它发现证书的UPN 域（如果有的话）和注册到域上的一个用户的UPN之间存在一个匹配的时候（表达形式是@）就执行这个映射。后者必须在活动目录管理snap-in 上明确定义。

与AD映射相比，IIS私有映射包括更多负荷，但是它所提供的映射远远不止所能说出的多对1映射。
基于Internet 应用程序的COM+中的流动身份
如果你想提供到一个基于配置COM+组件的应用程序的Internet入口，所需要的就是建立适当的 IIS客户证明选项，这样每个客户的身份都从IIS透明地流向COM+ 应用程序。用这种方法，当

应用基于角色的安全时，就可以使用客户的身份。如果不这样的话，基于角色的安全就没用了。

你可以有三种选择：

IIS综合安全：前面已经说过，这只用于 Intranet环境。注意，如果 IE5 被用做客户浏览器，IIS5 在一个注册到W2K 域的服务器上运行，你就可以跳过客户身份到其它服务器；如果不是这种情况的话，比如Web服务器是Windows NT上的IIS4，你就不得不配置COM 组件，这些组件在IIS运行的同一个服务器上的一个 MTS包中。否则，当引用基于角色的安全时，就要使用IIS程序身份。
HTTPS 上的IIS 基本安全：要求互动或批登录，在任何浏览器中都能工作。
1对1客户证明映射
现在第二个选择是应用最广泛的，但是预计未来，基于证书的安全方案会得到越来越多的应用。

结论
你能看到，IIS5 为你提供了不同的证明选择。我建议你寻找并使用最适合应用程序安全的一个，而不仅仅是执行一些基于私有用户帐号数据库的定制安全机制。