使用 Microsoft SOAP Toolkit 2.0 建立安全 Web 服务

Kirill Gavrylyuk
测试组长，Web 数据 SOAP 组
Microsoft Corporation

 

2001年7月

摘要： Microsoft SOAP Toolkit 2.0 提供一个灵活的框架，可以为各种 Intranet 和 Internet 解决方案构建可伸缩的 Web 服务。在这两种方案中，安全性都是建立可靠服务的重要因素。SOAP Toolkit 2.0 支持基于 IIS 安全基础结构的 Internet 安全性。本文介绍了如何使用 Microsoft SOAP Toolkit 2.0 建立安全解决方案。

目录

• 简介
• 重要规则
• 身份验证
• 代理支持和身份验证
• SSL 和客户端证书
• 身份验证问题
• 疑难解答
• 其它信息

   

简介

与任何分布式协议相同，成功的 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 连接器的行为。

身份验证握手是如何进行的？每个身份验证握手都是如下开始：

1. 客户端发出页面请求。
2. 服务器返回状态 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()

虚拟目录设置如何要求身份验证？若要在服务器上更改特定虚拟目录的身份验证设置，请执行下列操作：

1. 在 IIS 4.0 和 IIS 5.0 上，用鼠标右键单击虚拟目录，单击“属性”，然后单击“目录安全性”选项卡。
2. 在“匿名访问和身份验证控制”之下，单击“编辑”。将出现以下两个选项：

匿名访问

匿名访问不是身份验证方法。Windows 2000 和 NT4 要求用户在访问任何资源之前验证自身，这种情况下，IIS 使用一个特殊帐户作为匿名 Web 用户（默认为 IUSR_machinename）。可以单击“匿名访问编辑”按钮更改此默认匿名 Web 用户的帐户或其密码。

注意：小心不要将特权帐户用作匿名 Web 用户帐户。若要将虚拟目录设置为要求身份验证，需要清除“匿名访问”标记。

基本身份验证

若要将虚拟目录设置为要求基本身份验证，需要：

1. 转至“属性”/“目录安全性”/“编辑匿名访问验证控制”菜单。
2. 取消选中“匿名访问”。
3. 启用“基本身份验证”。将显示一条警告消息。如果要继续使用基本身份验证，请单击“确定”。
4. 单击“基本身份验证编辑”按钮。输入域名。如果要使用默认域名，请输入“\”（不加引号）。

缺点：基本身份验证是非常不安全的。用户名和密码以不加密的 Base64 编码形式通过线路传输。问题不仅在于攻击者能访问基本身份验证保护的资源，他们还能够获取您的用户名和密码的实际值，并用来访问其它更安全的资源。使用 SSL 连接会更安全一些，因为 SSL 握手在身份验证握手之前发生。这样，可以通过安全连接传送用户名和密码。

优点：基本身份验证是 HTTP 1.0 协议的一部分，是得到最广泛支持的身份验证方案。

结论：基本身份验仅当与 SSL 功能共同使用时才是一个好的解决方案。如果希望您的服务具有安全性和高互操作性，请使用本方法。

摘要式身份验证

1. 这是一个相对较新的方法，是 HTTP1.1 协议的一部分，但没有被 Web 服务器广泛采用。对于 Windows，它只在出现 Windows 2000 之后才被采用。若要在 IIS 5.0 上设置摘要式身份验证，请执行下列步骤：
2. 转至“属性”/“目录安全性”/“编辑匿名访问”和“身份验证控制”菜单。
3. 取消选中“匿名访问”。
4. 启用“摘要式身份验证”。将显示一条警告消息。如果要继续使用摘要式身份验证，请单击“确定”。

使用摘要式身份验证具有以下要求：

1. 运行 Windows 2000 Server 的系统位于 Active Directory 域。
2. 在域控制器上安装 iissuba.dll 文件。该 DLL 在匿名访问和摘要式身份验证期间发挥作用。
3. 在 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()

通过默认代理访问