Java Web Services:不使用客户端证书的WS-Security

许多 WS-Security 配置要求客户端和服务器都使用 public/private 密钥对，使用 X.509 证书保证公共密钥的身份。这是使用 WS-Security 进行消息签名或加密中最广泛使用的技术，而且它有一些优势。特别地，客户端证书对请求提供了较严格的客户端身份验证和较严格的签名保证。但是它也有缺点，包括不对称加密的性能开销和每个客户端获取和维护证书的繁琐管理。

“WS-SecureConversation 性能” 介绍 WS-SecureConversation — 虽然仍然使用客户端证书 — 是如何使用对称加密来减少客户端和服务器之间持续交换消息的性能开销。在本文中，您将会了解您可以如何更一步地打破在普通的 WS-Security 和 WS-SecureConversation 交换方面都需要客户端证书的现状。

不需要客户端证书的加密和签名

使用不对称加密和 public/private 密钥对进行消息的签名和加密是很简单的（至少概念上很简单）。正如在 “Axis2 WS-Security 签名和加密” 中所介绍的，您可以使用您的私钥对消息进行签名，并使用接收者的公钥对消息进行加密。任何得到您的公钥（一般以 X.509 证书的形式封装在多层认证中）的人都可以验证您使用私钥生成的签名，但是只有对应私钥的拥有者才能够解密使用公钥加密的消息。

如果客户端没有 public/private 密钥对，您就无法使用完整的不对称加密技术。另外一种方法是对称加密，但是使用对称加密时，您必须拥有只有参与消息交换各方才知道的密钥。您可以如何创建这样一个保密密钥呢？

WS-Security 所使用的技术是要使客户端生成一个保密密钥值，然后再使用不对称加密和服务器公钥对它进行加密，并将它嵌入到一个 <xenc:EncryptedKey> 令牌的请求消息中。客户端可以使用这个保密密钥（或者更安全的做法是使用由保密密钥生成的单独密钥）来对请求消息进行加密和/或签名，而服务器也可以对响应消息做相同的操作。服务器不需要将保密密钥发送回客户端，因为客户端已经拥有了这个保密密钥。

WS-SecurityPolicy 配置

使用客户端生成密钥的对称加密的 WS-Policy/WS-SecurityPolicy 配置是很简单的。清单 1 显示的是本文所使用的版本。这个策略使用客户端生成的保密密钥来规定发送到两个方向的消息体加密方式。

清单 1. 用于加密所有消息体的 WS-Policy

<wsp:Policy　wsu:Id="SymmEncr"
　　xmlns:wsu="http://.../oasis-200401-wss-wssecurity-utility-1.0.xsd"
　　xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
　　xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"
　　xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
　<wsp:ExactlyOne>
　　<wsp:All>
　　　<sp:SymmetricBinding>
　　　　<wsp:Policy>
　　　　　<sp:ProtectionToken>
　　　　　　<wsp:Policy>
　　　　　　　<sp:X509Token　sp:IncludeToken=".../IncludeToken/Never">
　　　　　　　　<wsp:Policy>
　　　　　　　　　<sp:RequireDerivedKeys/>
　　　　　　　　　<sp:RequireThumbprintReference/>
　　　　　　　　　<sp:WssX509V3Token10/>
　　　　　　　　</wsp:Policy>
　　　　　　　</sp:X509Token>
　　　　　　</wsp:Policy>
　　　　　</sp:ProtectionToken>
　　　　　<sp:AlgorithmSuite>
　　　　　　<wsp:Policy>
　　　　　　　<sp:Basic128Rsa15/>
　　　　　　</wsp:Policy>
　　　　　</sp:AlgorithmSuite>
　　　　　<sp:Layout>
　　　　　　<wsp:Policy>
　　　　　　　<sp:Strict/>
　　　　　　</wsp:Policy>
　　　　　</sp:Layout>
　　　　</wsp:Policy>
　　　</sp:SymmetricBinding>
　　　<sp:Wss11>
　　　　<wsp:Policy>
　　　　　<sp:MustSupportRefKeyIdentifier/>
　　　　　<sp:MustSupportRefThumbprint/>
　　　　　<sp:MustSupportRefEncryptedKey/>
　　　　</wsp:Policy>
　　　</sp:Wss11>
　　　<sp:EncryptedParts>
　　　　<sp:Body/>
　　　</sp:EncryptedParts>
　　</wsp:All>
　</wsp:ExactlyOne>
</wsp:Policy>

清单 1 策略中的 <sp:SymmetricBinding> 断言是配置使用带有保密密钥的对称加密的代码。所嵌入的 <sp:X509Token> 断言表示有一个 X.509 证书将用于保护保密密钥的传输（即，加密所传输的保密密钥），而这是使用指纹引用（本质上是一个散列值）识别的证书。客户端生成的保密密钥是隐式使用带有 <sp:X509Token> 保护令牌的 <sp:SymmetricBinding> 断言。其他策略断言则规定了加密算法的细节和必要的特性，而最终 <sp:EncryptedParts> 断言表示将要使用保密密钥进行加密的 SOAP Body。

正如您在之前的文章中看到的，安全性处理的运行时参数（如密钥保存和密码）必须采用与实现无关的方式进行定义。在这里，这些参数是很简单的：客户端需要访问包含服务器证书的可信存储，而服务器端则需要访问包含证书中与公钥相匹配的私有密钥的密钥存储。请阅读这个 系列文章 了解参数在各个协议之间是如何传递的。

不使用客户端证书的 WS-SecureConversation

在使用 WS-SecureConversation 时，您可以使用相同的技术在没有客户端证书的情况下处理客户端和 Security Token Service (STS) 之间的消息交换。（阅读 “WS-Trust 和 WS-SecureConversation” 和 “WS-SecureConversation 性能” 了解 WS-SecureConversation 的细节。）要使用这种方法，您基本上需要将 清单 1 的策略替换为 <sp:BootstrapPolicy>，以实现安全会话。清单 2 显示了这是如何工作的，它用粗体显示的 <sp:SymmetricBinding> 替换 “WS-SecureConversation 性能” 中使用的 <sp:AsymmetricBinding>：

清单 2. WS-SecureConversation 中不使用客户端证书的 WS-Policy

<wsp:Policy　wsu:Id="SecureConv"
　xmlns:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd"
　xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
　xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
　<wsp:ExactlyOne>
　<wsp:All>
　　<sp:SymmetricBinding>
　　<wsp:Policy>
　　　<sp:ProtectionToken>
　　　<wsp:Policy>
　　　　<sp:SecureConversationToken
　　　　　sp:IncludeToken=".../IncludeToken/AlwaysToRecipient">
　　　　<wsp:Policy>
　　　　　<sp:BootstrapPolicy>
　　　　　<wsp:Policy>
　　　　　　<sp:SymmetricBinding>
　　　　　　<wsp:Policy>
　　　　　　　<sp:ProtectionToken>
　　　　　　　<wsp:Policy>
　　　　　　　　<sp:X509Token　sp:IncludeToken=".../IncludeToken/Never">
　　　　　　　　<wsp:Policy>
　　　　　　　　　<sp:RequireDerivedKeys/>
　　　　　　　　　<sp:RequireThumbprintReference/>
　　　　　　　　　<sp:WssX509V3Token10/>
　　　　　　　　</wsp:Policy>
　　　　　　　　</sp:X509Token>
　　　　　　　</wsp:Policy>
　　　　　　　</sp:ProtectionToken>
　　　　　　　<sp:AlgorithmSuite>
　　　　　　　<wsp:Policy>
　　　　　　　　<sp:Basic128Rsa15/>
　　　　　　　</wsp:Policy>
　　　　　　　</sp:AlgorithmSuite>
　　　　　　　<sp:Layout>
　　　　　　　<wsp:Policy>
　　　　　　　　<sp:Strict/>
　　　　　　　</wsp:Policy>
　　　　　　　</sp:Layout>
　　　　　　</wsp:Policy>
　　　　　　</sp:SymmetricBinding>
　　　　　　<sp:Wss11>
　　　　　　<wsp:Policy>
　　　　　　　<sp:MustSupportRefKeyIdentifier/>
　　　　　　　<sp:MustSupportRefThumbprint/>
　　　　　　　<sp:MustSupportRefEncryptedKey/>
　　　　　　</wsp:Policy>
　　　　　　</sp:Wss11>
　　　　　　<sp:EncryptedParts>
　　　　　　<sp:Body/>
　　　　　　</sp:EncryptedParts>
　　　　　</wsp:Policy>
　　　　　</sp:BootstrapPolicy>
　　　　</wsp:Policy>
　　　　</sp:SecureConversationToken>
　　　</wsp:Policy>
　　　</sp:ProtectionToken>
　　　<sp:AlgorithmSuite>
　　　<wsp:Policy>
　　　　<sp:Basic128Rsa15/>
　　　</wsp:Policy>
　　　</sp:AlgorithmSuite>
　　　<sp:Layout>
　　　<wsp:Policy>
　　　　<sp:Strict/>
　　　</wsp:Policy>
　　　</sp:Layout>
　　</wsp:Policy>
　　</sp:SymmetricBinding>
　　<sp:EncryptedParts>
　　<sp:Body/>
　　</sp:EncryptedParts>
　</wsp:All>
　</wsp:ExactlyOne>
</wsp:Policy>

除了使用客户端生成的使用 STS 进行消息交换的密钥，通过去除 <wsap:UsingAddressing> 断言， 清单 2 中的策略也与 “WS-SecureConversation 性能” 中所使用的不同。

理论上，这个策略可以处理任何的 WS-Security 和 WS-SecureConversation 实现。实践中，当我在三个主流开源 Java Web Service 工具尝试这个配置时遇到了一些问题。CXF 是唯一能够正常运行所编写的策略的工具。Axis2 完全不能运行，它在处理 STS 响应消息时会出现客户端异常错误。当我将辅助程序策略修改回不对称加密方式时，Axis2 能够运行，但是它在所有消息上使用 WS-Addressing。Metro 也会出错；在我重新添加 <wsap:UsingAddressing> 时，它能够处理客户端为 STS 消息传递的对称加密所生成的密钥。

性能比较

性能比较使用与之前文章相同的测试代码，即地震数据查询服务。这个服务使用了几年里全世界所发生的超过 93,000 次地震的数据库。发向服务的请求指定了一个时间范围和地理坐标范围，而这个服务将返回所指定范围的所有地震数据。请阅读 “WS-Security 的大开销” 了解更多关于这个测试应用和示例请求/响应消息对的详细信息。

在之前的文章中，性能测试使用了两组请求序列。第一组使用了 1,000 个请求，其中查询参数被调整为只匹配整个地震数据库的一小部分（1,000 个请求只返回 816 个匹配的地震）。第二组使用了 100 个请求，其中查询参数被调整为匹配更大范围的数据库（100 个请求只返回 176,745 个匹配的地震）。这两个请求序列侧重于 Web Services 协议的不同性能特征。第一个显示这些协议处理包含少量数据的请求的速度有多快，而第二个强调处理数据容量的速度。每一个请求序列都会以不同的安全性配置多次运行，而结果只保存每一种配置的最短时间。而这一次，我们只测试两个安全性配置：

使用 SymmetricBinding 加密所有的请求/响应消息体的 WS-Security （direct）

加密所有请求/响应消息体的 WS-SecureConversation（securconv）

securconv 配置本质上与 “WS-SecureConversation 性能” 中所使用的配置是相同的，唯一的区别是它在 Metro 和 CXF 的客户端和 STS 之间的消息交换中使用了 SymmetricBinding。因为所测试的 SymmetricBinding STS 策略不能在 Axis2 中运行，用于计时测试的 Axis2 配置与前一篇文章所使用的是相同的。在策略中使用 SymmetricBinding 的变化更多是出于演示的目标，而不会对性能带来重要影响，所以这个区别不会影响到结果。

这些测试是在运行 Mandriva 2009.1 32-bit Linux® 的笔记本电脑上的，它使用了 Turion X2 ZM-85 处理器，有 3GB 的 RAM，安装了 Sun (Oracle) Java 1.6.0_10 32-bit JVM。（注意，它与前面文章的性能测试所使用的系统不一样。）服务器代码运行在 Tomcat 6.0.20 上，它的配置使用 1024MB 的堆，其中客户端代码使用 512MB 的堆。所测试的 Web Services 工具版本如下：

Axis2 1.5.1 和 Rampart 1.5

Metro 2.0

CXF 2.1.8

如果您想要在您自己的主机和 JVM 上进行这些测试，您可以从这里 下载 代码。

性能测试结果

图 1 显示了在小响应测试中所测得的时间。正如 “WS-SecureConversation 性能” 所介绍的，在 WS-SecureConversation 计时中 Metro 比 CXF 稍微快一些（大约快 10%）。Metro 甚至比直接使用对称加密实现 WS-Security 还要快一些，大约快 30%。（在本文的两个图表中，较短的数据条表示更快一些的时间）。

图 1. 使用小响应的测试时间