Java Web 服务: WS-Security 的大开销

核心提示： 再次回到在线购物系统示例，付款指令上的客户机签名将允许该指令由银行系统保存，Java Web 服务: WS-Security 的大开销(10)，并在以后就该事务出现任何争辩时提供该签名，这样，因此，在转向其他话题之前，银行系统便可以证明 付款已经得到了客户的授权，从而让自己免除任何责任

再次回到在线购物系统示例，付款指令上的客户机签名将允许该指令由银行系统保存，并在以后就该事务出现任何争辩时提供该签名。这样，银行系统便可以证明 付款已经得到了客户的授权，从而让自己免除任何责任。

其他特性

除了基本的机密性、完整性和真实性之外，WS-Security 还针对特定的安全性需求提供了许多其他特性。举例来说，UsernameToken 就是一个简单的特性，它提供了与服务传递基本用户授权的标准方法。其他 WS-Security 特性还允许 Security Assertion Markup Language (SAML) 授权令牌和其他形式的与安全性相关的信息，用于添加到 SOAP 消息交换中。如果需要在 Web 服务中使用此类型的安全性信息，可以使用 WS-Security 支持来传递信息，因为它定义了一些标准的格式和过程，可能会比您自己实现的功能更加可靠。

降低 WS-Security 的成本

如果您要使用 WS-Security，可以从本文的测试结果中看出性能是一个问题。但是，在顾虑其开销之前，请考虑一下您服务的数据量。使用 WS-Security 进行加密和签名之后，服务的性能会大打折扣 — 但是，如果您的服务每小时只交换少量消息，则硬件需求方面的差异是可以忽略不计的。

对于性能无法折衷的场景，您可以通过合理地安全性选项来帮助最大限度地减小性能影响。某些 Web 服务框架倾向于生成 “所有上述” 安全性配置，它们使用 WS-Security 实现全面的消息签名和加密，并 通过 SSL 连接发送它们。如果您确实希望提供最高级别的保护，而对性能毫不关心，那么这种方式没有问题。但是，在大多数情况下，更有意义的方法是使用 SSL（如果只关心为在客户机和单一服务器之间传输的信息提供保护）或者 WS-Security 加密（如果需要跨多个服务器传递数据，同时在它们经过中间系统时保护机密信息的安全。

对于客户机和服务器之间需要长时间交换消息的情况工（甚至通过中间系统访问其一），您还可以使用 WS-SecureConversation 提供相对于使用证书的 WS-Security 更好的性能。WS-SecureConversation 特别适合相对较小的消息之间的交换，其中，证书和非对称加密方面增加的开销与消息主体的实际（对称）加密相比是相当可观的。

降低 WS-Security 性能成本的另一种方法是将安全性处理转嫁给专门的硬件来完成。一些 XML 网关工具提供了对 WS-Security 加密和签名的加速处理。您可以使用这些工具来处理大开销的 WS-Security，同时处理应用程序中的纯 SOAP。显然，您需要确保在向服务器添加工具时不会打开任何潜在的安全性漏洞。并且，您应该在购买之前测试工具所带来的性能提升。但是，至少从理论上来说，这种模式确实能实现一些性能提升。

结束语

WS-Security 的性能成本是可观的，并且简单的 SSL 点对点加密有时是更好的解决方案。但是，对许多应用程序而言，SSL 是远远不够的。在这些情况中，就必须使用 WS-Security（或者它的后代 WS-SecureConversation），而且性能成本也成为必要的开销。在本文中，您已经了解了 WS-Security 的成本，并学习了一些可帮助您确定 WS-Security 是否适用于自己应用程序的指导方针。

在本系列的下一篇文章中，我们将从另一个视角来解读 WS-Security，将演示如何使用 WS-SecurityPolicy 实现对 Web 服务中各操作所使用的 WS-Security 特性的粒度化控制。在操作层面控制 WS-Security 也是一个能够（至少可能）降低 WS-Security 开销的技巧，因此，在转向其他话题之前，这是对本文的最好的沿续。

本文示例源代码或素材下载