增强Web服务安全性的新技术Web服务器教程 -免费技术教程下载中心

本文假设读者熟悉 XML 和安全性基础知识。

摘要

如果没有良好的安全性，Web 服务将永远不能发挥它的潜能。本文重点讨论了 WS-Security 及其相关的技术，它们代表了 Web 服务安全性的未来。本文对这些新兴的安全标准进行了概述，并对这些安全标准的作用、工作方式和协作形式进行了说明。讨论的主题包括完整性、保密性以及如何通过公钥加密、WS-Security 和其他技术来实现完整性和保密性。本文还讨论了一些关键的 WS-Security 组件，例如 wsu 命名空间。

本页内容
WS-Security
发送安全令牌
完整性
保密性
指定策略：WS-SecurityPolicy
获得安全令牌：WS-Trust
建立上下文：WS-SecureConversation
使用 SAML 和其他基于 XML 的令牌
小结

如果没有良好的安全性，Web 服务就不能发挥它的作用。然而，SOAP 的最初设计者选择了推迟定义解决此问题的方法。由于 Web 服务开发初始希望其简单易用 — 但要确保其安全却不是一件简单的事情，因此，这是一个合理的选择。但是，安全问题不能永远推迟下去。因此，Microsoft 和 IBM 以及其他公司强强联合，共同致力于解决此问题。其成果是制定了一组提供 Web 服务安全性的规范，其中最重要的是 WS-Security。本文将对这些技术如何工作进行全面概述。

从某个角度来看，Web 服务安全性的设计者所面临的任务看起来很简单。毕竟，分布式安全已经存在有效的机制，包括 Kerberos、公钥技术以及其他，因此，这些设计者所面临的任务并不是要发明新的安全机制。相反，他们的目标是定义 Web 服务领域（一个构建于 XML 和 SOAP 之上的领域）中现有安全机制的使用方式。目前已经有几个与安全相关的规范，包括：

• WS-Security：其他所有规范的基础。它定义了允许传递安全令牌的 SOAP 扩展，安全令牌可安全地对客户端进行标识和身份验证、确保消息完整性以及提供消息保密性。Web Services Security Addendum：一种附加规范，向原始文档中添加了一些细节和修正。

• WS-SecurityPolicy：指定如何定义明确声明 Web 服务优先权和要求的安全声明。

• WS-Trust：定义如何获得安全令牌。

• WS-SecureConversation：定义如何创建与 Web 服务进行特殊会话的上下文，以及如何创建用于该上下文的密钥。

• Web Services Security Profile for XML-based Tokens：定义如何将基于 XML 的技术（例如，安全声明标记语言 (SAML) 和可扩展权限标记语言 (XrML)）与 WS-Security 一起使用。该规范还获得了最长规范名奖。

这些规范自成体系，并以此为基础构成了易使用、可协作以及相当完善的方法，以提供 Web 服务安全性。

WS-Security

WS-Security 定义了向 SOAP 中添加安全性的基本技术。其宏伟目标是为 SOAP 消息提供端对端的消息级别的安全，但 WS-Security 规范并不十分冗长，细数起来也只有 20 多页。这是因为 WS-Security 几乎没有定义什么新技术，而是定义了一种使用 SOAP 的现有安全技术的方法。

或许，WS-Security 定义的最基本内容是位于 SOAP 标头中的元素。包含该元素的 SOAP 消息的结构如图 1 所示。如这个简单的架构显示，WS-Security 定义了它自己的命名空间。在任何可能的位置上，WS-Security 的设计者都会遵守现有的这些标准和技术，而只是会集中于指定如何在 SOAP 中使用它们。

WS-Security 描述如何实现完整性和保密性。完整性允许接收方确保从消息中接收的数据在传输过程中没有被篡改；保密性可确保数据在传输过程中不会被窥视。它还描述了如何发送安全令牌，例如用户名/密码组合、Kerberos 票据或 X.509 证书等。下面三方面内容描述 WS-Security 如何处理其中的每个领域。

返回页首
发送安全令牌

消息接收方遇到的最基本的问题可能是：我正在和谁交谈？问题虽然简单，但答案却非想象的那么简单。在网络中表明身份的方法有多种（用户名、 Kerberos 票据或 X.509 证书等），进行身份验证的方法也有不少。例如，通过用户名以及随附的密码，可以证明用户的真实身份。相反，Kerberos 票据由发行方使用票据接收方可验证其正确性的密钥进行加密。此外，可以随证书一起发送数字签名来验证用户身份。（有关数字签名的详细信息，请参阅补充文章 “什么是数字签名？”）

WS-Security 的设计者选择了依赖多种传输方法和身份验证方法。实际上，WS-Security 根本没有定义如何进行身份验证。相反，该规范指定了如何在 SOAP 标头的 Security 元素中传输多种不同的安全令牌。令牌的接收方可以根据偏好，以任何方式使用其中包含的信息。最常见的用法可能是验证令牌发送方的身份，但也可采用其他方式使用令牌。

尽管 WS-Security 规范允许任何类型的安全令牌，但它明确地定义了三种方案。最简单的（尽管不一定总是最安全的）方案是发送包含用户名和密码的安全令牌。要实现这个目标， WS-Security 定义了一个包含用户名和密码的元素。以下是仅包含的 Security 元素的一个简单示例：

Diana
mY5ecRet

还定义了功能更强大的方案，例如发送摘要版密码。由于通过网络发送未加密的密码并不是一种非常有效的身份验证机制，因此很可能会使用 UsernameToken 元素来验证经由加密连接发送的 SOAP 消息，例如使用安全套接字层 (SSL) 发送的消息等。

WS-Security 定义的第二个方案是发送包含 Kerberos 票据的安全令牌。像所有的安全令牌一样，在 SOAP 标头中发送的 Kerberos 票据是 Security 元素的一部分。下面是一个示例：

　QMwcAG ...　　　　

如该代码片段所示，Kerberos 票据是使用更一般的元素进行发送的。该元素的 ValueType 属性表明这是一个 Kerberos Version 5 服务票据，它用于验证请求特殊服务的客户端。（当发送票据授予票据时，ValueType 为 wsse:Kerberosv5TGT。）虽然也定义了十六进制编码方案，但是票据本身使用 base64 编码表示，并且只显示其前几个字节。

WS-Security 定义的第三个方案用于表示安全令牌、X.509 证书，它也依赖于元素。下面是一个示例：

　KkFPle ...　　　　

您可以发现，该示例与以前所述的 Kerberos 票据示例并没有多大区别。此时，的 ValueType 属性表明正在发送 X.509 证书。再次使用了 Base64 编码，而且证书本身也是该元素内容的一部分，正如 Kerberos 票据在先前示例中起到的作用一样。

与在 SOAP 消息的标头中直接嵌入安全令牌的这三个方案一起，WS-Security 还定义了元素。正如其名称所示，该元素包含一个指示从何处查找安全令牌的 URI。这样，消息接收方就可以从令牌所在地（例如 Internet 上的已命名位置）将其取回。该元素也可用于引用包含在该消息的 SOAP 标头中的安全令牌，在以下部分中将详细说明这一功能的用途。

WS-Security 采用一种非常灵活的方法进行传输和身份验证，然而这里还有一个重要含义：虽然两个系统都符合 WS-Security 的标准，但二者仍然不能进行相互验证。例如，其中一个系统可能只支持 Kerberos，而另一个系统只支持使用 X.509 证书进行基于数字签名的身份验证。仅仅允许使用 WS-Security 是不够的。有关确切地使用何种类型的安全令牌，还需要有一些协议。

返回页首
完整性

使用 SOAP 消息进行传输和身份验证是一个多方面的问题，可能存在多种解决方案。因此，WS-Security 采用了一种非常广泛的方法。但是，更明确的一点是要为 SOAP 消息提供完整性。解决方案是使用某种类型的数字签名。幸运的是，已经有了针对该领域的 W3C 标准。该标准称为 XML 签名，它为数字签名 XML 文档提供了详细的机制。WS-Security 没有彻底改造已有标准，而是简单地利用现有规范，并就如何在 SOAP 消息中使用这些规范提出了一些具体细节。

XML 签名规范定义的主要内容是元素，该元素的内容包括数字签名本身以及有关如何生成该签名的信息。虽然已经有了一些方案，但一个典型的实例与 SOAP 中使用的相同，也包含和元素。

元素描述正在进行签名的信息。该元素本身包含多个子元素，每个子元素都指定了一些有关已签名信息的内容。其中最重要的子元素包括以下元素：

• 标识用于在生成签名之前将此 XML 文档转换为标准形式的算法。这个过程是必须的，因为要使数字签名生效，已签名文档的每一方视图都必须逐位相同。然而，如果不进行标准化，那么两个语义相同的 XML 文档可能在位级上存在区别。例如，其中一个可能表示带有回车/换行符对的分行符，而另一个可能只使用换行符。标准化可将 XML 文档转换为标准形式，从而确保双方在签名之前能够以相同的方式查看文档。

• 标识用于创建数字签名的算法。XML 签名标准和 WS-Security 均要求支持数字签名标准（使用安全哈希算法 (SHA)-1 和 DSA 算法创建消息摘要），也建议支持使用 SHA-1 和 RSA 算法。

• 标识正在进行签名的信息以及对其进行的任何转换。与 SOAP 一同使用时，该部分签名一般引用此 SOAP 消息的已签名部分，例如，正文和标头部分。元素还包含从已签名信息生成的 base64 编码的消息摘要，并指定诸如 SHA-1 等用于创建摘要的算法。

• 包含构成数字签名的字节。

• 指示验证签名时应使用的密钥。密钥可以用多种方式进行标识，例如引用一个包含适当公钥的证书。由于接收方可能会通过其他手段了解要使用的密钥，因此甚至可以完全忽略该元素。

倘若了解 XML 签名的元素的这种基本特性，就可以理解 WS-Security 是如何使用该元素的。图 2 是包含数字签名的 SOAP 消息形式的一个示例。

在本例中，标头的元素以