许多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”                    >   <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”         >  <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. 使用小响应的测试时间

  　Axis2的测试结果没有包含在 图 1 中，因为测试过程中出现了一个问题。Axis2一开始的运行速度是可接受的，然后随着循环次数的增加，速度明显变慢。使用Axis2运行这个测试的总时间最后超过Metro的40倍。这种类型的变慢通常表示出现了问题，如由代码所存储值的线性查找，这里错误出现在Axis2对于对称加密的安全性处理中（可能是在处理客户端生成的密钥时，因为每一个请求都会生成一个新的保密密钥）。

　　图 2 显示了大响应测试所测得的时间。这里Metro又一次是运行最快的，但是CXF的速度很接近 — 两者的区别只有10%。Axis2比其他两种工具速度慢很多，这和之前文章中所介绍的WS-Security和WS-SecureConversation测试是一样的。

图 2. 使用大响应的测试时间 

　　这些结果（除了Axis2）是与您根据正在进行的安全性处理得到的预期是一样的。通过这两种安全性配置，客户端和服务之间的消息交换使用了对称加密。这两者最大的不同是WS-Security对称加密配置使用了客户端为每一个请求/响应消息对生成的一个新的保密密钥。这个保密密钥需要使用服务器的公钥进行不对称加密，然后它会作为请求消息的一部分发送，这样WS-SecureConversation就可以在许多消息对中重用一个保密密钥。这意味着WS-Security配置为每个请求带来严重的过载，这主要显示在 图 1 的时间中。

　　这些工具并不支持使用WS-Security对称加密来只 加密一条消息，而是同时还要求使用签名才能完成。这使得我们很难作直接的性能比较，但是您可以通过将这些图表与“WS-SecureConversation性能” 中的图表进行比较来了解它们之间的区别。前一篇文章显示WS-SecureConversation对称加密显然比WS-Security不对称加密具有更好的性能，特别是在加密消息时。这些结果表明使用客户端生成的密钥进行WS-Security对称加密几乎和WS-SecureConversation一样快，特别是对于较大的消息。

　　结束语

　　您已经从本文中了解了对称加密是如何在不需要客户端证书的情况下使用客户端生成的保密密钥来保证消息交换的安全。当消息相对较大时，这个方法在实现消息交换时有很好的性能 — 几乎与WS-SecureConversation一样好。如果只有少量的消息在客户端和服务器之间交换，客户端生成的保密密钥可以实现WS-SecureConversation保密密钥更好的性能（因为WS-SecureConversation要求在客户端和STS之间使用额外的消息交换）。

　　客户端生成的保密密钥也可用于消息签名。虽然本文没有介绍，但是保密密钥的使用方法本质上与 “WS-SecureConversation性能” 中讨论的WS-SecureConversation签名例子是一样的。使用保密密钥进行签名本身比使用私有密钥进行签名的真实性保证较弱一些，但是它对于保证消息在传输中不会被篡改还是很有用的。

　　本系列的上几篇文章讨论了在Web Services中使用的几种形式的WS-Security和WS-SecureConversation安全性技术，包括三种主流Java Web Services工具的性能比较。我将在将来的文章中介绍具体的WS-Security特性，但是现在是时候对安全性性能进行总结了。本系列的下一篇文章将总结这三种主流Java Web Services工具的性能和互操作性问题，同时提供在这些工具中使用Web Services安全性的最佳使用方法的指南。如果您想要在您的组织中使用安全的Web Services，您一定不希望错过这篇文章。