摘要： Microsoft SOAP Toolkit 2.0 提供一个灵活的框架，可以为各种 Intranet 和 Internet 解决方案构建可伸缩的 Web 服务。在这两种方案中，安全性都是建立可靠服务的重要因素。SOAP Toolkit 2.0 支持基于 IIS 安全基础结构的 Internet 安全性。本文介绍了如何使用 Microsoft SOAP Toolkit 2.0 建立安全解决方案。
简介
与任何分布式协议相同，成功的 SOAP 应用程序的关键在于获得安全性权限。SOAP 标准不指定任何安全性机制，而是将安全处理委派给传输层。对 SOAP Toolkit 2.0 而言，传输层是 HTTP。在 HTTP 上运行的 SOAP 基本上是一个 Web 应用程序，与其它在 IIS 上运行的 ASP 或 ISAPI 应用程序很相似。SOAP 的身份验证、授权和加密机制与您通常使用的 Web 应用程序完全相同。如果熟悉 Web 安全性，也就了解了 SOAP 安全性。如果对 Web 应用程序不够熟悉，本文将为您提供充分的入门知识背景。每个主题都介绍的非常详细。如果需要更详细的信息，请参见 MSDN Library 或由 Michael Howard、Marc Levy 和 Richard Waymire 编著的《设计 Microsoft Windows 2000 基于 Web 的安全应用程序》。
重要规则
根据《设计 Microsoft Windows 2000 基于 Web 的安全应用程序》中阐述的观点，我们首先从概述建立安全 Web 服务应遵守的重要规则开始。安全 Web 服务可归纳为以下七类：
身份验证
授权
审核
保密
完整性
可用性
认可
身份验证是一个实体（也称为主题）验证另一个实体是否符合它所声称的身份的过程。SOAP Toolkit 2.0 支持以下身份验证方法：
基本
摘要式
Kerberos
Windows NTLM
SSL 客户端证书
基于 SOAP 头的身份验证
代理身份验证
本文档介绍如何配置服务器端和客户端使用上述身份验证方法。
授权是为经过身份验证的用户提供资源访问权限的机制。只要使用 SOAP Toolkit 建立的 Web 服务基于 IIS，这些服务就可以利用 IIS 支持的授权机制。本文档也将讲述用户应注意的一些问题。
审核的目的是为了收集有关对 Web 服务的成功和失败请求的信息。可以使用 IIS 审核功能和 SOAP Toolkit 跟踪功能实现这一目的。本文档没有介绍这方面的内容，您可以参考 IIS 文档、netmon 日志和 SoapServer 对象的 SOAP Toolkit 帮助。
保密是指确保攻击者看不到客户端与服务器之间的通信信息。完整性是指保护数据不被删除或更改（不管是恶意还是不慎）的能力。为了实现保密和完整性，SOAP Toolkit 允许使用安全套接字层 (SSL) 加密数据。本文档将介绍如何启用 IIS 上的 SSL 支持以及如何将其用于客户端。
可用性确保不会拒绝合法用户对请求的资源的访问。可用性技术的示例包括负载平衡以及硬件和软件的故障转移。SOAP Toolkit 已成功通过了 Microsoft Application Center 负载平衡软件的测试。
认可是一种技术，为发生的操作提供证据以防止客户端在事务处理中欺诈或否认。SOAP Toolkit 采用 IIS 提供的认可功能。本文档不对认可进行介绍。
身份验证
本节介绍了 SOAP Toolkit 支持的身份验证方法，包括其优点和缺点，以及如何对其进行设置。还介绍了 SOAP Toolkit 在支持平台上的已知局限性，以及服务器具有多个可用身份验证方案时 SOAP Toolkit HTTP 连接器的行为。
身份验证握手是如何进行的？每个身份验证握手都是如下开始：
客户端发出页面请求。
服务器返回状态 401“拒绝访问”和一组 HTTP 头。
WWW 验证它支持的每一个身份验证方法。
如何使用 SoapClient 验证自身？如果 Web 服务要求身份验证（基本、摘要式、NTLM 或 Kerberos），需要为 SoapClient 提供用户名和密码，以将其传递到 Web 服务。也可以使用 SoapClient.ConnectorProperty 包完成此操作：
dim SoapClient
set SoapClient = createobject("MSSoap.SoapClient")
SoapClient.mssoapinit("http://your-server/webservice/service.wsdl ")
SoapClient.ConnectorProperty("AuthName") = "username"
SoapClient.ConnectorProperty("AuthPassword") = "userpwd"
Quote = SoapClient.GetQuote()
注意：使用 SOAP Toolkit 2.0 时，只有在调用远程方法时才必须设置 SoapClient 上的 ConnectorProperties。
如果包含服务描述的 wsdl 文件所在的虚拟目录也要求身份验证，可以在 URL 内传递用户名和密码：
SoapClient.mssoapinit
("http:// username:userpwd@your-server/webservice/service.wsdl ")
人们往往错误地认为将用户名和密码放入 URL 是不安全的。事实并非如此。在发送 HTTP 请求之前，客户端 HTTP 代码将分析 URL，移出用户名和密码，并在身份验证握手时使用此用户名和密码。事实上，代码：
SoapClient.ConnectorProperty("AuthName") = "username"
SoapClient.ConnectorProperty("AuthPassword") = "userpwd"
Quote = SoapClient.GetQuote()
与下列代码的功能相同（假设 WSDL 文件 service.wsdl 指向自身）：
SoapClient.ConnectorProperty("EndPointURL")=
"http:// username:userpwd@your-server/webservice/service.wsdl"
Quote = SoapClient.GetQuote()
虚拟目录设置如何要求身份验证？若要在服务器上更改特定虚拟目录的身份验证设置，请执行下列操作：
在 IIS 4.0 和 IIS 5.0 上，用鼠标右键单击虚拟目录，单击“属性”，然后单击“目录安全性”选项卡。
在“匿名访问和身份验证控制”之下，单击“编辑”。将出现以下两个选项：
匿名访问
匿名访问不是身份验证方法。Windows 2000 和 NT4 要求用户在访问任何资源之前验证自身，这种情况下，IIS 使用一个特殊帐户作为匿名 Web 用户（默认为 IUSR_machinename）。可以单击“匿名访问编辑”按钮更改此默认匿名 Web 用户的帐户或其密码。
注意：小心不要将特权帐户用作匿名 Web 用户帐户。若要将虚拟目录设置为要求身份验证，需要清除“匿名访问”标记。
基本身份验证
若要将虚拟目录设置为要求基本身份验证，需要：
转至“属性”/“目录安全性”/“编辑匿名访问验证控制”菜单。
取消选中“匿名访问”。
启用“基本身份验证”。将显示一条警告消息。如果要继续使用基本身份验证，请单击“确定”。
单击“基本身份验证编辑”按钮。输入域名。如果要使用默认域名，请输入“\”（不加引号）。
缺点：基本身份验证是非常不安全的。用户名和密码以不加密的 Base64 编码形式通过线路传输。问题不仅在于攻击者能访问基本身份验证保护的资源，他们还能够获取您的用户名和密码的实际值，并用来访问其它更安全的资源。使用 SSL 连接会更安全一些，因为 SSL 握手在身份验证握手之前发生。这样，可以通过安全连接传送用户名和密码。
优点：基本身份验证是 HTTP 1.0 协议的一部分，是得到最广泛支持的身份验证方案。
结论：基本身份验仅当与 SSL 功能共同使用时才是一个好的解决方案。如果希望您的服务具有安全性和高互操作性，请使用本方法。
摘要式身份验证
这是一个相对较新的方法，是 HTTP1.1 协议的一部分，但没有被 Web 服务器广泛采用。对于 Windows，它只在出现 Windows 2000 之后才被采用。若要在 IIS 5.0 上设置摘要式身份验证，请执行下列步骤：
转至“属性”/“目录安全性”/“编辑匿名访问”和“身份验证控制”菜单。
取消选中“匿名访问”。
启用“摘要式身份验证”。将显示一条警告消息。如果要继续使用摘要式身份验证，请单击“确定”。
使用摘要式身份验证具有以下要求：
运行 Windows 2000 Server 的系统位于 Active Directory 域。
域控制器上安装 iissuba.dll 文件。该 DLL 在匿名访问和摘要式身份验证期间发挥作用。
在 Active Directory 设置中使用摘要式身份验证的所有帐户的日志记录都启用“使用可逆加密存储密码”选项。这是对 Active Directory 中帐户密码的纯文本副本进行摘要式身份验证访问时所必需的。这样，可确保存储这些密码的服务器是非常安全的。
缺点：如果摘要式身份验证不与 SSL 一起使用，将不能保护资源免于重复攻击。目前尚未在其它 HTTP 客户端和服务器中被广泛采用。在 IIS 5.0 上的实现具有局限性，如果通过摘要式身份验证登录到服务器，标识将无法委派到其它服务器。这就将服务器限制为服务器方案。
优点：摘要式身份验证简单，可能会越来越普及。它比基本身份验证更安全，因为尽管仍可能遭到重复攻击，但攻击者无法获得访问其它资源所要求的用户名和密码的实际值。
结论：摘要式身份验证可以用于保护通过 Web 服务公开到 Internet 的低价值资源。在 SSL 上使用基本身份验证可以获得更好的性能，因为 SSL 速度慢，但不会象基本身份验证那样将用户名和密码暴露给攻击者。
Windows 集成身份验证 (NTLM)
Windows 集成身份验证（IIS 4 中的 Windows 请求/响应身份验证）在 Windows 2000 和 NT4 上表现为不同的方法。在具有 IIS 4 的 NT 4 下，它描述为 NTLM 身份验证。若要将 IIS 服务器设置为要求 Windows 集成身份验证（在 IIS 5 上）或 NTLM（在 IIS 4 上），请完成基本或摘要式身份验证步骤 1 和 2，并在步骤 3 中选择相应的复选框。
NTLM 身份验证（NT LAN Manager 或 Windows 请求/响应身份验证）是本机 Windows 身份验证方案。如果未指定用户名/密码，将使用当前登录用户凭据。通过 Intranet 访问时，如果用户已经登录的域与 Web 服务器的域相同，而且使用自己的凭据，则这些用户不必重新进行身份验证。在 NTLM 握手过程中，客户端用服务器（请求）发送的随机值散列密码，然后将此散列（响应）发送给服务器。这意味着密码不会通过线路显式发送。人们通常错误地认为 NTLM 只能用于 Intranet 解决方案，不应用于 Internet。实际上，NTLM 可以用于 Internet，只不过用于 Intranet 时速度更快，因为它依赖于 Windows 登录过程。若要同时传送域名和登录名称，请使用 SAM 帐户名称：
SoapClient.ConnectorProperty("AuthName") = "DOMAIN\username"
缺点：NTLM 只能用于 Windows。与基本和摘要式身份验证方案一样，它只对客户端进行身份验证。使用 NTLM 时，服务器上的模拟线程无法将自己的权限委派给另一台服务器。这限制了 NTLM 身份验证在“服务器至服务器”方案中的使用；但仍可以在这种方案中使用基本和摘要式身份验证。NTLM 不能通过代理工作。
优点：NTLM 比基本和摘要式身份验证更安全，因为它不容易受到重复攻击。由于依赖 Windows 登录过程，因此在 Intranet 方案中速度很快。
结论：推荐将 NTLM 用于“客户端至服务器”Intranet 解决方案。也可用于限制为 Windows 体系结构的公司 Internet 解决方案。
Kerberos 身份验证
Kerberos 身份验证是在 Windows 2000 中出现的。当指定 IIS 5 使用 Windows 集成身份验证时，IIS 5 和 SoapClient HTTP 连接器通过协商协议确定是使用 NTLM 还是使用 Kerberos。如果在 Windows 2000 上运行 SoapClient，则使用 Kerberos，否则使用 NTLM。指定 SoapClient 上用户凭据时所应用的规则与 NTLM 相同。
缺点：仅 Windows 2000 平台支持 Kerberos。Kerberos 要求具有一个可向其请求服务票证的 KDC 服务器。通常，人们不想将自己的 KDC 服务器公开于 Internet。因此，Kerberos 通常只限于 Intranet 应用。默认情况下，只有服务器的 NetBIOS 名称在 Kerberos KDC 中进行了注册。如果您希望请求票证时使用 IIS 服务器的 DNS 名称，则必须在 KDC 中注册 DNS 名称。
优点：与 NTLM 相比，Kerberos 速度更快、更安全，而且同时对服务器和客户端进行身份验证。Kerberos 不是 Windows 专有的身份验证方案，也可以由其它平台实现。很重要的一点在于它允许将标识委派给另一台计算机，因此可以在“服务器至服务器”方案中使用。
结论：推荐在基于 Windows 2000 的 Intranet 解决方案中使用 Kerberos。
有时，需要服务器支持多种身份验证方案（以便允许对多种类型的客户端进行身份验证）。这种情况下，IIS 将发送多个 WWW 身份验证头，详细说明它支持的身份验证方案，客户端将选择它支持的第一个身份验证方案。了解 SoapClient 在特定情况下选择哪种身份验证方案非常重要。请参考表 1，其中描述了 SOAP Toolkit 2.0（更准确的说是 HttpConnector）在各种平台上的行为。
表 1：SOAP Toolkit 2.0 HttpConnector 与 IIS 5.0 的比较
基本
摘要式
Windows 集成
Windows 98
Windows Me
Windows NT 4.0
Windows 2000
X
X
基本
基本
基本
摘要式
X
X
NTLM
NTLM
NTLM
Kerberos
X
X
NTLM
NTLM
NTLM
Kerberos
X
X
X
NTLM
NTLM
NTLM
Kerberos
左边的三列代表服务器提供的身份验证方案。每一行都代表服务器允许的身份验证方案集的一个不同组合。右边的四列显示了可以运行 SOAP Toolkit Client (HttpConnector) 的平台。例如，如果服务器既允许基本身份验证也允许摘要式身份验证，SOAP 将在除 Windows 2000 之外的所有平台上选择基本身份验证。
表 2 显示了 Microsoft SOAP 行为与 IIS 4.0 服务器的比较。
表 2：SOAP Toolkit 2.0 HttpConnector 与 IIS 4.0 的比较
基本
Windows 集成
Windows 98
Windows Me
Winodws NT 4.0
Windows 2000
X
X
NTLM
NTLM
NTLM
NTLM
身份验证支持中的已知局限性：SOAP Toolkit 2.0 使用 NTLM/Kerberos 同时发送域名和帐户名时具有某种局限性。但已经在 SP2 中进行了修正。
代理支持和身份验证
SOAP Toolkit 广泛支持通过代理服务器进行通信，包括在代理服务器上进行身份验证。我们将具体说明以下方案，讲述如何通过代理服务器使用 Web 服务。
直接访问
默认情况下，SOAP Toolkit HttpConnector 尝试对 Web 服务进行直接调用。如果您不具有 Web 服务的直接访问权限（例如，Web 服务位于您的 Intranet 之外，必须通过代理才能访问），以下脚本将失败：
dim SoapClient
set SoapClient = createobject("MSSoap.SoapClient")
SoapClient.mssoapinit("http://services.xmethods.net/soap/
urn:xmethods-CurrencyExchange.wsdl")
Quote = SoapClient.GetQuote()
通过默认代理访问
试图访问 Intranet 之外的网站时，Internet Explorer Web 浏览器将通过在 IE 设置中指定的默认代理服务器。您可以通过 IE/“工具”/“选项”/“连接”/“局域网设置”对话框查看这些设置。若要使 Microsoft SOAP Toolkit (HTTPConnecter) 使用这些设置，应将 UseProxy 属性设置为 TRUE。示例：
dim SoapClient
set SoapClient = createobject("MSSoap.SoapClient")
SoapClient.mssoapinit("http://services.xmethods.net/soap/
urn:xmethods-CurrencyExchange.wsdl")
SoapClient.ConnectorProperty("UseProxy") = true
Quote = SoapClient.GetQuote()
绕过代理服务器列表。请注意，IE 代理设置中有一个主机列表，您可以连接这些主机来绕过代理服务器。
转至 IE/“工具”/“选项”/“连接”/“局域网设置”对话框。
若要绕过本地服务器，请启用设置“对于本地地址不使用代理服务器”。
若要在连接到其它特定服务器时绕过代理，请单击“高级”按钮。可以在“例外”编辑控件中列出要绕过的服务器，各个服务器名称之间用分号隔开。可以使用通配符“*.soap-company.com”绕过名称中含有 .soap-company.com 的所有服务器。
需要代理服务器来允许绕过本地 Intranet 之外的任何服务器。请注意，用于 HTTP 和用于通过 SSL (HTTPS) 连接的代理服务器不同。代理应允许使用任一协议，以便 SSL 正常工作。
局限性：使用默认代理时，在 Windows 2000 和 Windows NT4 上使用 Microsoft SOAP Toolkit 2.0 HttpConnector 有一个已知问题：它不理解默认 IE 代理设置的“绕过代理”列表。如果选中了“对于本地地址不使用代理服务器”并且在 URL 中指定的主机名不包含“.”，它将绕过代理服务器。但它不理解在 IE 代理设置“高级”菜单中的“例外”文本框中指定的复杂模板。
通过指定代理连接
可以指定哪个代理使用 ProxyServer 和 ProxyPort 连接器属性：
set SoapClient = createobject("MSSoap.SoapClient")
SoapClient.mssoapinit("http://services.xmethods.net/soap/
urn:xmethods-CurrencyExchange.wsdl")
SoapClient.ConnectorProperty("UseProxy") = true
SoapClient.ConnectorProperty("ProxyServer") = "yourproxy"
SoapClient.ConnectorProperty("ProxyPort") = 80
Quote = SoapClient.GetQuote()
请注意，如果使用 ProxyServer 属性，则不必将 UseProxy 设置为 True，它将自动设置。
代理身份验证
代理服务器可以在允许连接之前要求您对自身进行身份验证。例如，可以使用它限制在公司 Intranet 内使用 Internet。代理服务器可使用上述所有身份验证方案。Microsoft SOAP Toolkit 2.0 允许您指定代理身份验证的用户名和密码：
set SoapClient = createobject("MSSoap.SoapClient")
SoapClient.ConnectorProperty("UseProxy") = true
SoapClient.mssoapinit("http://services.xmethods.net/soap/
urn:xmethods-CurrencyExchange.wsdl")
SoapClient.ConnectorProperty("ProxyServer") = "secureproxy"
SoapClient.ConnectorProperty("ProxyPort") = 80
SoapClient.ConnectorProperty("ProxyUser") = "username"
SoapClient.ConnectorProperty("ProxyPassword") = "password"
Quote = SoapClient.GetQuote()
如果代理要求 NTLM 身份验证，可以省略用户名和密码，这是将使用当前登录凭据。如果需要指定代理 NTLM 身份验证的域名，请添加“DOMAIN\username”进行服务器身份验证。
局限性。Microsoft SOAP Toolkit 2.0 不支持通过要求身份验证的代理连接到也要求身份验证的服务器。另外，通过要求身份验证的代理的 SSL 连接在 Windows 2000 和 Windows NT4 上不能正常工作。
SSL 和客户端证书
在本节中，我们将具体讨论如何通过安全套接字层 (SSL) 和客户端证书支持进行连接。我们还将讨论 Microsoft SOAP Toolkit 2.0 在使用客户端证书支持的支持平台上的已知局限性。
通常认为 SSL 只是一种加密机制，其实它还提供身份验证。若要使 IIS 4.0/IIS 5.0 支持 SSL 连接，需要获取 X.509 证书，并将其安装在服务器上。
何谓 X.509 证书？
证书是一种结构，其中包含主题、颁发者名称、有效期和其它特征等信息。（有关证书的详细信息，请参阅由 Michael Howard 编著的《设计 Microsoft Windows 2000 基于 Web 的安全应用程序》。） 每个证书都与用于 SSL 加密的一对私有和公用密钥相关。SSL 始终使用 X.509 证书对 Web 服务器进行身份验证。
若要获得证书，需要向证书颁发机构发出证书请求。证书颁发机构 (CA) 是颁发证书的单位。当 CA 向主题（发出请求的实体）颁发证书时，它验证该主题是否与它所声称的相符，并签发新证书和私有密钥。这样，主题可以信任 CA。如果信任颁发证书的 CA，则表示信任向您提供此证书的主题。根目录证书保证 CA 的可信性。多个 CA 可以形成一条信任链：如果信任根 CA，就信任具有根 CA 颁发的证书的中间 CA，因此将信任具有中间 CA 颁发的证书的所有主题。
“信任”的实际意义是什么？可以将 CA 的证书放入“受信任的根目录证书颁发机构”存储区来表示信任该 CA。所有证书都存储在所谓的证书存储区中。有多个默认存储区，例如：
CURRENT_USER\MY\，个人证书存储区，用于当前登录的用户，对其它登录用户不可见
LOCAL_MACHINE\MY\，个人证书存储区，用于所有用户
CURRENT_USER\Root\，受信任的根目录证书颁发机构，包含当前用户信任的根 CA 的证书，如果证书具有到根 CA 证书的证书路径，则当前用户信任该证书的有效性。
LOCAL_MACHINE\Root\，相同，但被所有用户信任
具有被默认信任的根 CA，例如 Verisign。尽管我们的示例将使用一个试用版的 Verisign 证书，但是它们是由不被默认信任的 Verisign 测试机构颁发的。
在服务器上启用 SSL
本节介绍如何创建证书请求、从 Verisign 站点获得试用版的测试服务器端证书，并将其安装在 Web 服务器上。
使用 IIS 4.0 启用服务器上的 SSL
用鼠标右键单击要启用 SSL 的网站，并选择“属性”。
在“目录安全性”选项卡上，单击“编辑安全通信”。
在对话框中，单击“密钥管理器”。
展开树状视图中的“本地计算机”节点。用鼠标右键单击 WWW 叶，并选择“新建密钥”。这将启动称为“密钥管理器”的密钥请求向导。
选择“将请求放入要发送到颁发机构的文件中”和一个文件名。单击“下一步”。
输入一个易记的密钥名称。输入密码，当获取由颁发机构颁发的证书时需要此密码。对于加密密钥字节长度，请选择 1024（1024 为推荐长度，某些颁发机构不颁发小于此长度的证书）。单击“下一步”。
输入您的组织和部门名称。输入等同于完整站点名称的公用名称，例如 www.yoursite.com。在启动 SSL 连接之前，客户端将检查站点名称是否与证书的公用名称相同。单击“下一步”。
输入国家（地区）、省/自治区、市/县所在地。证书颁发机构可能检查这些信息是否一致，以确保输入的信息有效。输入省时，请输入完整的省名称。
输入管理服务器的人员的姓名、电子邮件地址和电话号码。这些信息不包含在证书中，但证书颁发机构需要这些信息。
包含您的请求的文件已经创建。该文件为 Base64 编码格式。在此过程中，IIS 还将为该证书请求创建一个私有密钥和一个公用密钥。私有密钥将保存在您的计算机上，而公用密钥将随请求一起发往 Verisign，并用以加密证书数据。
转至 www.verisign.com（英文），并单击“Get Trial SSL ID”。注册证书时，会要求您提供 CSR（证书签名请求）。复制并粘贴您的请求文件中自行“BEGIN NEW CERTIFICATE REQUEST;”之后的内容，否则，将会出错。Verisign 以邮件形式将测试服务器端证书发送给您。该过程同样适用于商业证书，不同之处在于它收费并仔细验证提交的信息。
确保从证书颁发机构获得的证书是 Base64 编码的。如果证书颁发机构是 Verisign，则您可以通过电子邮件获得证书。创建一个扩展名为 .cer 的空文件，复制行“BEGIN CERTIFICATE”和“END CERTIFICATE”之间（包含这两行）的所有内容并粘贴到该文件。
转至要启用 SSL 的站点的“属性”/“目录安全性”选项卡。单击“编辑安全通信”，然后单击“密钥管理器”。
在对话框中，展开树状视图中的“本地计算机”节点，再展开 WWW 叶，将显示您的证书请求的密钥。由于该证书尚未安装，它标记为红色。用鼠标右键单击该证书，并选择“安装密钥证书”。选择具有要安装的证书的文件。将提示您提供以前设置的密码。输入密码。现在，您的证书已安装。
使用 IIS 5.0 启用服务器上的 SSL
用鼠标右键单击要启用 SSL 的网站，并选择“属性”。
在“目录安全性”选项卡上，单击“编辑安全通信”。
单击“服务器证书”打开服务器证书向导。该向导将记忆网站的当前状态，例如您是否已拥有服务器证书。（现在假设您没有证书。）
在证书向导中，单击“下一步”，选择“创建一个新证书”，然后单击“下一步”。
选择“现在准备请求，但稍后发送”，并单击“下一步”。
输入证书的友好名称。该名称不会在证书结构中使用，但作为区分请求和证书的一种方法。选择公用密钥长度。推荐密钥长度不小于 1024 字节。单击“下一步”。
输入可以由颁发机构验证的组织名称和部门名称，如果您请求用于商业目的的真实证书，请输入有效名称。输入要被认证的计算机的名称。注意：它必须等同于您的完整站点名称，例如 www.yoursite.com。单击“下一步”。
输入国家（地区）、省/自治区、市/县所在地。请输入有效信息，证书颁发机构将检查这些信息是否一致。输入省时，请输入完整的省名称。单击“下一步”。
输入用于保存请求的请求文件名称。单击“下一步”。
将摘要显示您输入的内容。确认内容正确，并单击“下一步”完成向导。包含请求的文件将以 Base 64 格式保存。
包含您的请求的文件已经创建。该文件为 Base64 编码格式。在此过程中，IIS 还将为该证书请求创建一个私有密钥和一个公用密钥。私有密钥将保存在您的计算机上，而公用密钥将随请求一起发往 Verisign，并用以加密证书数据。
转至 www.verisign.com（英文），并单击“Get Trial SSL ID”。注册证书时，会要求您提供 CSR（证书签名请求）。复制并粘贴您的请求文件中自行“BEGIN NEW CERTIFICATE REQUEST;”之后的内容，否则，将会出错。Verisign 以邮件形式将测试服务器端证书发送给您。该过程同样适用于商业证书，不同之处在于它收费并仔细验证提交的信息。
确保从证书颁发机构获得的证书是 Base64 编码的。如果证书颁发机构是 Verisign，则您可以通过电子邮件获得证书。创建一个扩展名为 .cer 的空文件，复制行“BEGIN CERTIFICATE”和“END CERTIFICATE”之间（包含这两行）的所有内容并粘贴到该文件。
转至要启用 SSL 的站点的“属性”/“目录安全性”选项卡。单击“编辑安全通信”，然后单击“服务器证书”。服务器证书向导知道您刚刚提出证书请求，所以期望您已颁发证书并准备好在 IIS 5.0 中安装。
选择“处理挂起申请并安装证书”，并单击“下一步”。选择从证书颁发机构获得的证书的文件名。单击“下一步”。查看证书概述，并单击“下一步”。单击“完成”。您的 Web 服务器证书已安装在 IIS 5.0 中。
为 SSL 连接配置客户端
仅仅具有配置正确的服务器并不足以启用成功的 SSL 连接。请记住，SSL 连接始终包含身份验证，其中客户端验证服务器的身份。特别是客户端将验证服务器是否具有有效证书，例如证书是否过期、是否被注销、是否由客户端信任的证书颁发机构颁发等。在上述详细步骤中，将收到一个由 Verisign 测试根颁发机构颁发的试用版 Verisign 服务器端证书。默认情况下，该颁发机构并不被信任，例如，其证书不默认存储在您计算机上的根存储区。按照 Verisign 站点中的关于如何获得 Verisign 测试颁发机构根目录证书的指导进行操作。获得包含 Verisign 测试颁发机构根目录证书的文件之后，需要将其安装在客户端（您要用这些客户端执行至服务器的 SSL 连接）上，以在对服务器进行身份验证时信任服务器端证书。请执行以下步骤：
双击包含证书的文件，打开证书浏览器窗口。
单击“安装证书”。在证书导入向导欢迎页上，单击“下一步”。
选择要保存该证书的存储区。
默认情况下，Windows 将该证书放置到 CURRENT_USER\Root\存储区中。这意味着只以您的帐户使用计算机时，才能够信任由该颁发机构颁发的证书。若要确保对其它用户也有效，推荐始终将根 CA 证书放置到 LOCAL_MACHINE\Root 存储区。这需要执行以下操作：
选择“将所有证书放置到以下存储区”，并单击“浏览”。
选择“显示物理存储区”，展开“受信任的根目录证书颁发机构”节点，选择“本地计算机”，然后选择“LOCAL_MACHINE\Root”节点。
完成该向导安装 CA 根目录证书。
执行 SSL 连接
尝试打开到 Web 服务器的 SSL 连接。若要实现此目的，让我们首先设置 Calc/Service/Rpc/AspVbsVb SOAP Toolkit 示例。需要执行以下操作：
在服务器上，执行 SOAP Toolkit 2.0 示例描述文件 C:\Program Files\MSSOAP\Samples\default.html 中有关示例设置的所有指导。
在服务器上，编辑 C:\ProgramFiles\MSSOAP\Samples\Calc\Service\Rpc\AspVbsVb\calc.wsdl 文件，并在位置 URL 而不是在 MSSOAP 的以下位置指定 Web 服务器名称：
/Service/Rpc/AspVbsVb/Calc.asp"
在客户端上运行以下 VBScript：
Set Calc = CreateObject("MSSOAP.SoapClient")
Calc.mssoapinit https://your-server/MSSoapSamples/Calc/Service/Rpc/AspVbsVb/Calc.wsdl
Answer = Calc.add(14,28)
WScript.Echo "14+28=" & Answer
这样，即建立了一个 SSL 连接。请注意，如果将 URL 改回 HTTP，将建立一个通常意义上的非安全 HTTP 连接。若要使您的服务器要求 Web 服务实现 SSL 连接，需要在服务所在的虚拟目录上设置“要求 SSL”。请执行以下操作：
在 IIS 4.0 上
用鼠标右键单击 IIS 管理器中的虚拟目录，并选择“属性”。
在“目录安全性”选项卡上，单击“编辑安全通信”。
启用“访问本资源时要求安全通道”。
在 IIS 5.0 上
用鼠标右键单击 IIS 管理器中的虚拟目录，并选择“属性”。
在“目录安全性”选项卡上，单击“编辑安全通信”。
启用“要求 SSL”。
现在，如果试图建立与该服务的非安全 HTTP 连接，将会出错。
SSL 中的服务器身份验证
常见错误是在 SSL 连接中使用 localhost 或服务器主机名的其它别名。在 SSL 握手期间，客户端验证服务器证书主题名称的公用名称 (CN) 部分与 HTTP 请求中的主机名是否匹配。如果不匹配，SSL 连接将失败。客户端还同时验证服务器端证书是否有效、是否撤消以及是否由信任的 CA 颁发。
客户端证书身份验证
除了必要的服务器身份验证，SSL 还有一个可选步骤：对客户端进行身份验证。这是使用客户端证书进行的。客户端证书与服务器证书相似。如果服务器配置为要求客户端证书，客户端会将客户端证书发送到服务器。服务器至少要检查它是否信任此客户端证书，例如，它是否由信任的证书颁发机构颁发。
在服务器上配置客户端证书身份验证
IIS 4.0 和 IIS 5.0 都可以配置为：
忽略客户端证书。这种情况下，客户端证书身份验证将关闭。
接受但不要求客户端证书。这种情况下，如果提供了客户端证书，将对客户端进行身份验证。这时，所谓的身份验证仅是检查客户端证书是否有效、可信。
要求客户端证书。如果没有提供客户端证书，连接将被拒绝。将如前一选项那样对提供的客户端证书进行检查。
要求客户端证书，并将其映射到指定的用户帐户。这种身份验证方式与要求客户端证书相同，但 IIS 工作线程还模拟指定用户的凭据。
使用由 CA 而不是默认信任的颁发机构（例如 Verisign 或 Thawte）颁发的客户端证书时，需要确保该 CA 根目录证书存储在服务器上的 LOCAL_MACHINE\Root\ 存储区中，而不是存储在 CURRENT_USER\Root\ 存储区中。默认情况下，向导将 CA 的证书放置在 CURRENT_USER\Root\ 中，这使该证书对 IIS 不可见，因为它使用不同的用户帐户。
如何配置 IIS 使用上述客户端证书选项之一？请按照上述步骤执行，但第三步要执行以下操作（IIS 4.0 和 IIS 5.0 中的对话框相似）：
若要忽略客户端证书，请在 IIS 5.0 上选择“忽略客户端证书”或在 IIS 4.0 上选择“不接受客户端证书”；
若要接受但不要求客户端证书，请选择“接受客户端证书”；
若要要求客户端证书，请选择“要求客户端证书”；
若要要求客户端证书与指定的用户帐户匹配，请选择“要求客户端证书”以及“启用客户端证书映射”。此时，您需要具有一个文件，该文件包含要映射的导出客户端证书。要获得该文件，请在客户端证书所在的客户端计算机上，执行以下操作：
在 Internet Explorer 中，单击“工具”菜单上的“Internet 选项”。单击“内容”选项卡，然后单击“证书”。
在出现的对话框上，将具有 CURRENT_USER\MY、CURRENT_USER\Root 等证书存储区。（请注意不会显示 LOCAL_MACHINE\ 中的任何存储区。）
选择要导出的证书，并单击“导出”。在向导中，选择“不，不要导出私有密钥”和“Base64 编码 X.509(.CER)”格式。选择文件名。结果文件将包含导出的客户端证书。
若要将文件添加到服务器，请在“编辑客户端证书映射”对话框中，单击“添加”并选择包含客户端证书的文件。
将要求您提供映射名称。选择任意帐户名称以映射到证书和密码。每当连接到此虚拟目录中的服务时，客户端都发出此证书，将使用所选帐户模拟请求处理线程。有关使用客户端证书进行身份验证的详细信息，请参阅 Windows 2000 网站上将证书映射到用户帐户的逐步指导（英文）。
在客户端使用 SSL 客户端证书
本节介绍为了与服务交流而需要提供客户端证书时，如何在客户端上进行操作。如何获取和安装客户端证书？可以从 Verisign 或任何其它 CA 获取客户端证书（Web 标识）。
注意：服务器证书和客户端证书的用途不同。不能将服务器端证书用作客户端证书。
获得包含证书的文件（.cer 文件）之后，双击该文件即可进行安装。按照前述安装 Verisign 测试 CA 根目录证书的步骤进行操作。将要求您指定存放证书的存储区。客户端证书的默认（推荐）存储区是 CURRENT_USER\MY\。
注意：准备客户端证书的请求时，通常会询问您是否使用 CURRENT_USER 或 LOCAL_MACHINE 存储区来存储证书。
如果希望只能从创建请求时所使用的帐户访问证书，则使用 CURRENT_USER 存储区。
如果希望几个特权用户可以共享访问此证书，则使用 LOCAL_MACHINE 存储区。只有本地管理帐户具有 LOCAL_MACHINE 存储区的访问权限。例如，如果在具有客户端证书身份验证的 SSL 之上使用 SOAP 进行远程配置，并且希望从任何本地管理员帐户都可以使用客户端脚本，可能要使用该存储区。
以下是一些创建客户端证书请求并将证书安装到所选存储区的简单脚本。脚本使用证书注册控制，与上述用于服务器证书的脚本很相似：
CERT_SYSTEM_STORE_LOCAL_MACHINE= 131072
OID_CLIENT_AUTH = "1.3.6.1.5.5.7.3.2"
REQUEST_FILENAME = "ClientCertReq.txt"
bUseLM = true
set enroll = CreateObject("CEnroll.CEnroll.1")
'建立证书的辨别名称
strDN = "CN=your-server,OU=UserUnit,O=UserOrg,L=UserCity,S=WA,C=US"
if bUseLM then
'如果希望将请求和证书保存在 LOCAL_MACHINE 存储区中
enroll.MyStoreFlags = CERT_SYSTEM_STORE_LOCAL_MACHINE
enroll.RequestStoreFlags = CERT_SYSTEM_STORE_LOCAL_MACHINE
end if
'否则，请求和证书将默认保存在
' CURRENT_USER 存储区中
'创建请求，指定证书用途（客户端身份验证）
strReq = Enroll.createPKCS10( strDN, OID_CLIENT_AUTH)
'添加 BEGIN/END 标记
strReq = "-----BEGIN NEW CERTIFICATE REQUEST-----" & vbCRLF & _
strReq & _
"-----END NEW CERTIFICATE REQUEST-------"
set fso = CreateObject("Scripting.FileSystemObject")
set f = fso.OpenTextFile(REQUEST_FILENAME, 2, true)
call f.Write(strReq)
f.Close()
ClientCertReq.txt 文件将包含一个 Base64 编码的 PKCS10 请求。若要在从 CA 接收到 SSL 客户端证书后进行安装，请使用下列脚本：
FILE_CERTIFICATE = "certnew.cer"
CERT_SYSTEM_STORE_LOCAL_MACHINE= 131072
bUseLM = true
set enroll = CreateObject("CEnroll.CEnroll.1")
if bUseLM then
'如果希望请求和证书保存在 LOCAL_MACHINE 存储区中
enroll.MyStoreFlags= CERT_SYSTEM_STORE_LOCAL_MACHINE
enroll.RequestStoreFlags= CERT_SYSTEM_STORE_LOCAL_MACHINE
end if
'否则，Cenroll 将默认使用 CURRENT_USER 存储区。
'指定的存储区应与保存请求的存储区相同。
enroll.acceptFilePKCS7(FILE_CERTIFICATE)
该脚本将从指定文件获取证书，并将其安装到 IIS 保存服务器证书的 LOCAL_MACHINE 存储区。可以使用这些脚本自动进行配置。
如何使 SoapClient 使用客户端证书？这相当容易。您需要了解证书保存在哪个存储区以及证书公用名称（主题名称的 CN 部分）。当从 IE5 或 Microsoft Management Console（mmc.exe）浏览时，公用名称显示在“颁发给”列。以下脚本：
Set Calc = CreateObject("MSSOAP.SoapClient")
Calc.mssoapinit https://your-server/MSSoapSamples/Calc/Service/Rpc/AspVbsVb/Calc.wsdl
SoapClient.ConnectorProperty("SSLClientCertificateName") = "MyCert"
Answer = Calc.add(14,28)
WScript.Echo "14+28=" & Answer
从 CURRENT_USER\MY 存储区提取 CN=MyCert 的证书，并使用此证书请求安全服务。也可以显式指定要使用的存储区：
SoapClient.ConnectorProperty("SSLClientCertificateName") = "LOCAL_MACHINE\MY\MyCert"
证书名称不区分大小写，但存储区名称区分大小写。
“服务器至服务器”方案中的客户端证书
我们详细介绍并提供了一个使用客户端证书的安全 B2B 解决方案示例。为了防止攻击，在“服务器至服务器”方案中正确使用客户端证书至关重要。
方案：Internet 商店使用第三方付费的 Web 服务验证提交的客户信息（例如信用卡号）。付费的 Web 服务要求客户端证书身份验证。
Internet 商店应用程序要求下列组件：
Web 应用程序：在高保护（隔离）Web 应用程序中运行的一组 ASP 页（这是很重要的）。当需要使用信用卡号验证服务时，调用执行该任务的 COM+ 应用程序。这些 ASP 页不访问客户端证书，也不直接使用 SoapClient。该应用程序允许匿名访问。
COM+ 应用程序：配置为以特定本地帐户标识在独立进程中运行。用于对第三方信用卡号验证服务进行身份验证的客户端证书保存在该本地帐户的个人 (CURRENT_USER\MY\) 存储区。该 COM+ 对象是信用卡号验证服务的代理，而且使用 SoapClient 访问该服务，并如上所述使用客户端证书进行身份验证。
信用卡号验证服务：要求 SSL 连接和客户端证书身份验证。
客户端证书存储在证书存储区中，并且该证书存储区不能从 ASP 页能够模拟的任何帐户访问。这样，就确保了攻击者无法通过执行脚本代码使用客户端证书，即使他们获得了对 ASP 页的更新访问权限。不要从 ASP 页直接访问客户端证书。
SSL 和客户端证书支持的已知局限性
Windows 98：Windows 98 上的某些 WinInet 版本不支持客户端证书。
Windows 98、Windows Me 和 Windows XP：如果包含服务的虚拟目录（在 IIS 4.0 或 IIS 5.0 上）配置为要求客户端证书，则无法连接到要求客户端证书的本主机上的任何其它 URL。这是由于 WinInet 中的证书缓存问题所致，而且在整个进程生存期内都存在。但是，您可以连接到另一台主机上的安全 URL。
在 Windows ME 中，SSL 连接可能在关闭时挂起。有关详细信息，请参阅知识库文章 Q238934。有关此 Windows ME 问题的 QFE，请与 Microsoft 产品支持服务联系。
Windows 2000 和 Windows NT4 上的 SoapClient 只能通过端口 443 进行 SSL 连接。
身份验证问题
这里，我们将讨论使用 SOAP Toolkit 2.0 提供 COM 对象时可能遇到的某些身份验证问题。这些并非安全漏洞，但您可能希望在部署安全 Web 服务时避免这些问题并确保资源的可用性。
以匿名登录方式访问文件和其它资源
当对允许匿名登录的 Web 服务发出 SOAP 请求时，IIS 将使用特殊 IUSR_machinename 帐户模拟请求处理服务器线程。如果已作为 Web 服务公开的 COM 对象试图使用禁止 IUSR_machinename 帐户访问的资源，将收到“拒绝访问”错误。为了避免此错误，可以更改 IUSR_machinename 对该资源的权限，或者更改虚拟目录设置以使用另一匿名访问帐户。（请参阅身份验证部分）
“服务器至服务器”方案
“服务器至服务器”是非常普遍的方案，其中 SoapClient 对象是从 ASP 文件内部使用。为了提高性能，需要缓存 global.asa 文件内的 SoapClient 对象。这样，可以避免重新调用 SoapClient.mssoapinit 和分析 WSDL 文件。在该解决方案中，如果正在访问另一台要求身份验证的安全服务器，需要在 global.asa 文件中设置凭据。
不能执行 NTLM 身份验证，因为它具有委派局限性（请参阅身份验证部分）。
注意：对于 Kerberos，请务必显式指定要使用哪些凭据。不要依赖当前线程凭据，因为具有较强凭据的客户端发出第一个请求后，所有后续调用都将继续使用此连接。这可能会在您的解决方案中导致安全漏洞。
注意：为了使解决方案更安全，我们推荐您采用使用 SoapClient 的独立 COM+ 应用程序代码并执行经过身份验证的连接。请参阅有关使用上述客户端证书身份验证的“服务器至服务器”解决方案的详细描述。这样 ，可以避免用户名和密码受到已经获得 ASP 页源代码访问权限的攻击者的攻击。
注意：如果决定在 ASP 页中使用 SoapClient，推荐在高保护（隔离）模式下运行 ASP 页。出于优化目的，执行 HTTP 连接的 SoapClient 代码以进程帐户而不是调用线程的帐户运行。这意味着，如果在低保护（进程内）模式下运行的 ASP 页中使用 SoapClient，HTTP 代码将在系统帐户下运行。如果使用隔离模式，它将在较安全的 IWAM_machinename 帐户下运行。
在 NT4 上的 MTS 中运行的对象：
如果提供的 COM 对象是在 NT 4.0 上的 MTS Server Package 中运行，则可能会导致一些安全问题。在 NT 4.0 中，COM 在进行本地 COM 调用时始终使用进程标识。这意味着，当 SOAP 侦听器创建和调用 COM 对象时，将使用进程标识进行调用，并且将忽略处理线程正在模拟用户凭据的事实。MTS 数据包始终认为传入调用是由同一个用户帐户发出的。用户帐户将是 IWAM 帐户（如果 SOAP 侦听器所在的虚拟目录配置为进程外运行）或 SYSTEM 帐户（如果 SOAP 侦听器所在的虚拟目录配置为进程内运行）。这会导致两种不同结果：
由于忽略被模拟的用户并使用进程标识进行调用，这种情况下，MTS 角色安全性不是非常有效。
无法将被模拟用户与 MTS COM 对象区分开来。例如，调用 GetDirectCallerName 时不会返回被模拟用户，而是返回 IWAM 或 SYSTEM。
有关详细信息，请参阅知识库文章 #Q243437“PRB：默认情况下 MTS 和 COM+ 库数据包中的标识是不同的”。
疑难解答
本节将介绍使用 Microsoft SOAP Toolkit 2.0 设计安全 Web 应用程序时遇到的典型问题，以及如何根据上一节提供的信息解决这些问题。
拒绝访问
通过 SOAP 调用公开的服务器端对象时，可能出现“拒绝访问”错误，而本地且不通过 SOAP 调用对象时不会出现此错误。您很可能正在以匿名帐户运行服务，并访问了无法从 IIS 匿名帐户访问的资源（文件系统或其它内容）。需要更改对此资源的访问权限，或者禁止匿名登录此 Web 服务。有关详细信息，请参阅身份验证部分。
基本身份验证不能正常工作
确保将运行服务的虚拟目录配置为要求基本身份验证，并在基本身份验证设置中指定了域名（默认使用“\”）。请参阅基本身份验证部分。
摘要式身份验证不能正常工作
阅读摘要式身份验证部分列出的要求，并确认完全符合这些要求。请认真斟酌是否确实需要使用摘要式身份验证。
Windows 集成身份验证不能正常工作
检查客户端和服务器是否位于同一个域。如果不是，请按 Windows 集成身份验证 (NTLM) 部分中的示例所示指定域名和用户名。如果在“服务器至服务器”方案下无法正常工作，请确保两个服务器都运行 Windows 2000。如果正在 Windows NT4.0 上使用 NTLM，则不适用于“服务器至服务器”方案。
SOAP Toolkit 不能通过代理正常工作
检查是否设置了 UseProxy 属性以及是否正确指定了代理服务器名称，或者在默认 Internet Explorer 设置中对其进行了设置（如果使用这些属性和名称）。SOAP Toolkit 2.0 代理支持已经通过市场上许多可用代理进行了测试（包括 Microsoft Proxy 2.0、ISA 代理、Apache 代理服务器、Netscape 代理服务器等）。只有用于 Netscape 代理时出现了问题。
SSL 不能正常工作
这是最常见的问题。通常是由于服务器未正确配置为支持 SSL 引起的。请参考 SSL 部分中的指导。若要查看服务器是否启用 SSL，请使用 Internet Explorer 访问您的服务 URL。
另一种可能是客户端不信任服务器端证书。在客户端，确保为颁发服务器端证书的 CA 安装了根目录证书。
如果正在运行“服务器至服务器”方案，例如尝试在 ASP 页中使用 SoapClient 调用另一台服务器，请确保已将为颁发服务器端证书的 CA 安装的根目录证书安装到了 LOCAL_MACHINE 存储区中。有关详细信息，请参阅 SSL 部分。
SSL 客户端证书不能正常工作
确保在 SSLClientCertificateName 连接器属性中正确指定了客户端证书的名称和存储区。应该指定证书主题名称的公用名称 (CN) 部分。若要检查 CURRENT_USER\MY 存储区中证书的 CN 名称，请转至 Internet Explorer/“工具”/“选项”/“内容”/“证书”菜单，并在可用的客户端证书列表中选中“颁发给”。
确保客户端证书合法，例如，转至 Internet Explorer/“工具”/“选项”/“内容”/“证书”菜单，并单击证书，应不提示任何警告并显示“证书正常”和“您具有证书的私有密钥。”
确保服务器信任您的客户端证书，例如，颁发客户端证书的 CA 的根目录证书位于服务器上的 LOCAL_MACHINE\Root 存储区中。有关如何检查这些内容的详细信息，请参阅 SSL 客户端证书部分。
确保运行进程的帐户对指定的证书存储区具有访问权限。请参阅身份验证问题部分中“服务器至服务器”一节的注释。
有关详细信息
《设计 Microsoft Windows 2000 基于 Web 的安全应用程序》，Michael Howard、Marc Levy 和 Richard Waymire 编著。
《运行 Microsoft Internet Information Server》，Leon Braginski 和 Matt Powell 编著。
知识库文章 #Q243437，PRB：默认情况下 MTS 和 COM+ 库数据包中的标识是不同的（英文）。
