Java Web Services:不利用客户端证书的WS-Security
副标题#e#
很多 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。
#p#分页标题#e#
正如您在之前的文章中看到的，安详性处理惩罚的运行时参数（如密钥生存和暗码）必需回收与实现无关的方法举办界说。在这里，这些参数是很简朴的：客户端需要会见包括处事器证书的可信存储，而处事器端则需要会见包括证书中与公钥相匹配的私有密钥的密钥存储。请阅读这个 系列文章 相识参数在各个协议之间是如何通报的。
#p#副标题#e#
不利用客户端证书的 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>
#p#分页标题#e#
除了利用客户端生成的利用 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. 利用大响应的测试时间
#p#分页标题#e#
这些功效（除了 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，您必然不但愿错过这篇文章。
下载
| 描写 | 名字 | 巨细 | 下载要领 |
|---|---|---|---|
| 本文的示例代码 | j-jws17.zip | 5.29MB | HTTP |
