所有主要web服务栈都为WS-Security和相关web服务安全性标准提供一定程度的支持。我在本系列中介绍的3个开源栈—Apache Axis2、Sun/Oracle Metro和Apache CXF—都为这些标准提供相当高级别的支持。但是它们的支持在许多方面有极大的差别，包括安全性操作和使用运行时安全性参数配置栈的方法。

　　一个重要的不同之处就是安全性实现的完整性和正确性。WS-Security和WS-SecurityPolicy支持各种安全性配置，包括各种类型的密钥和证书、算法套件、安全性令牌、以及签名/加密规范。WS-Trust和WS-SecureConversation 进一步扩大选择数目。这么多的可行配置，没有web服务栈能将它们全部测试。即使测试每个孤立选项值都是相当困难的，多数栈不会去尝试。

　　在本文中，您将首先更多地了解web服务栈之间互操作性的安全问题。然后您将看到我根据自己对本系列近期10余篇文章进行的研究，从正确性和可用性几个方面比较Axis2、Metro和CXF之间的不同。

　　安全互操作性

　　安全性标准为综合测试提供很多选项组合。很多标准只提供少许这方面的示例，几乎没有什么测试套件，因此符合“标准”通常只是猜测，仁者见仁智者见智。结果声明支持特定标准的栈很少验证它们的支持。

　　对于每个栈而言，不要试着根据标准进行测试，而是使用一定数目的安全性配置对栈本身进行测试，以及使用更少数量的互操作性配置测试它与其他栈之间的互操作性。除此之外，每个栈的开发人员响应源自用户遇到的安全性配置或者互操作性问题的bug报告。复杂标准集的这个有限测试意味着，如果您尝试一些非主流问题，可能会经常遇到问题。尽管在本系列文章中，关于对安全性讨论和性能比较进行测试的安全性配置的数目较少，但我还是发现了这种类型的几个问题。

　　业界为提高 web 服务安全性代码质量做了很多努力，包括业内组织机构的工作和供应商驱动的互操作性测试。特别是后者，有助于在栈之间建立基本的兼容性，但是收效甚微，因为测试配置的数量很少。

　　WS-I Basic Security Profile

　　从一开始，SOAP web服务规范就为实施者和用户提供了很多选择。部分是有计划的。其他的是由于标准疏忽造成的：预期的行为规定的不够详细，因此实施者不得不猜测哪些工作是需要完成的。过多的选择带来的问题是实施者缺乏资源来完全测试可能的组合，因此，web服务栈能很好地支持部分选择，而对其他选择支持较弱，甚至根本不支持。这种情况造成严重的可互操作性问题，因为不能保证各种栈可以支持相同的选择。

　　在早年的SOAP中，选择过量就是这类问题，业内创建了一个行业级组专门限制可能的配置数量，方法是通过定义“最佳实践” 的方法。这个小组，Web Services Interoperability Organization (WS-I)，生成大量需要使用或者避免的特定选择的配置文件。通过这些配置文件，WS-I对形成当前第三代 web 服务栈有很大影响。

　　在配置文件中安全性是WS-I所涉及的领域之一。WS-I Basic Security Profile Version 1.1（被称为BSP 1.1）是安全领域目前主要的文档。该文档包含广泛的需求，但是与WSI的焦点保持一致，这些需求中大多数可以处理 web 服务栈实现，但不能处理终端用户安全性配置。BSP 1.1完全不能处理WS-SecurityPolicy中的WS-Security配置，但是其少量需求可以转换WS-SecurityPolicy条款。

　　当您使用数字签名时，BSP 1.1要求您遵守W3C Exclusive Canonicalization Recommendation—一个XML规范化算法，忽略注释和多余的上下文信息（见 参考资料）。在没有任何选择的情况下，该算法默认由WS-SecurityPolicy承担，因此，满足这类需求您所要做的是不要 指定一个不同的规范化算法（比如<sp:InclusiveC14N>）。

　　BSP 1.1也添加了一些其他需求用于签名和加密，约束WS-SecurityProfile中定义的算法套件值，但本质上只限制那些使用TripleDes、Aes128或Aes256加密和SHA1摘要（不包括WS-SecurityPolicy提供的Aes192加密和SHA256摘要）的选项。其他BPS建议限制各种安全令牌的引用和使用方法。

　　毋庸置疑，WS-I BSP对跨web服务安全性实现的互操作性做出了贡献，但是也有一些小问题，它未采取措施来减少安全配置选项的复杂性。BSP的一个更新版，更具体地说是面向WS-SecurityPolicy配置的更新版，对于使用现代基于策略的配置构建安全性架构的最佳实践很有帮助，但很遗憾，WS-I 对这类更新并不感兴趣。

　　互操作性测试

　　供应商驱动的跨栈互操作性测试成为提高web服务安全性实现的一个很重要的因素。Microsoft?已经成为这个领域的推动力，在大学校园里举办一系列 “互操作性接插集会（plug-fests）”，邀请其他web服务栈（包括商业的和开源的）的开发人员来参与测试他们代码和Microsoft实现之间的各种场景（见 参考资料）。安全性已经成为接插集会主要关注的焦点。

　　这个互操作性测试有助于在各个栈之间建立基本水平的兼容性，但是收效甚微，因为只有少量配置被测试。尽管通过Microsoft实现（而不是一个基于实际标准的测试套件）关注互操作性有一定的局限性，但是实际上，比起十几个栈之间的完全交叉兼容性测试，这是很容易处理的。

　　安全性问题和局限性

　　在这个系列专栏中，我在3个web栈中测试了各种安全性配置，对于每个栈都找到了几个问题。有限的互操作性测试（每个客户端使用一个栈，服务器使用另一个，只尝试WS-SecureConversation测试）会显示更多的问题。就拿栈Apache Axis2来说，我也发现了重大的性能问题。所有这些问题已经报告给各个栈的开发人员了，其中一些在新版本中已经得到修复了。在这一小节，我将从我为这些文章所作的测试方面，总结3个栈的目前状态。

　　Axis2问题

　　我在Axis2中发现的问题包括WS-SecureConversation策略处理，其中引导程序策略定义在运行过程中似乎被完全忽略了。这意味着Axis2为其WS-SecureConversation支持使用千篇一律的配置，它只与其他使用相同配置的栈可兼容。

　　就安全性运行时而言，Axis2一个主要问题是对称捆绑的客户端处理（正如在 “不使用客户端证书的WS-Security” 一文中所讨论的）。当发出更多的请求时，客户端运行逐渐减慢。我认为这是一个很难的bug，而不是一个性能问题，因为问题有不断发展的天性。

　　在任何时候只要使用安全性，操作就会逐步减慢，Axis2安全性处理也深受其苦。这个性能问题似乎源自Axis2所用的AXIOM对象模型和安全性代码所用的标准DOM的不兼容性，因此问题可能会延续，除非增强AXIOM来提供完整的DOM兼容性。

　　最后，在我看来，Axis2可能会遭遇核心web服务引擎（实际是Axis2代码）与安全性代码（Rampart和Rahas安全模块）的分离。早在我们（Axis2 提交者）决定将安全性代码从核心代码分离出来时，就允许这些组件各自增强和发布。不幸的是，这导致安全性代码被当作一个可选组件，而且Axis2版本并不与当时的Rampart版本一起使用。近来的Axis2 1.5.2版本就是一个例子：二进制发布版缺失一个安全性处理所必需的 JAR 文件，因此没有一种简单的方法能使它同Rampart一起工作。这在目前Axis2 1.5.3版本中更正了，但一个官方版本在不能运行安全性支持的情况下可以交付的事实就证明了它们的分离。

　　写这篇文章时，我所发现的重大Axis2问题在最新的Axis2和Rampart中都没有更正。

　　Metro问题

　　本系列本章的测试也发现了Metro中几个重要的问题。最大的问题是Metro对签署消息体的处理。如果策略包括一个 <sp:OnlySignEntireHeadersAndBody/> 断言，一切都很好，但是如果这个断言不能 使用，Metro将错误地签署正文内容，而不是body元素本身。处理正确签名的栈将拒绝Metro以这种方式签署的消息。

　　Metro也摒弃了 “ WS-Trust和WS-SecureConversation” 中使用的WS-SecureConversation策略。在这种情况下问题是，对于与Security Token Service (STS)的引导程序消息交换和与服务的实际会话，策略使用不同的算法套件。Metro忽略了这个，为它们俩只使用一个算法套件。这个问题不像签名问题那么严重，这是因为实践中很少有机会使用两个不同的算法套件，但它依旧是一个错误。

　　最后，Metro也有关于使用单向加密或者 “理解WS-Policy” 中报告的签名技术方面的问题。这些问题在最新 Metro 版本中还没有更正。

　　CXF问题

　　和其他栈一样，我在对这些文章进行测试时，也发现了一些CXF问题。在本文发布之前，几乎每一个案例中的问题都已经在最新CXF版本中更正了。惟一例外的是关于使用单向加密或 “理解WS-Policy” 中报告的签名技术方面的问题 — 这也在CXF 2.3.1中更正了。

　　栈的比较

　　任何根据安全性支持对web服务栈的排序都是非常主观的。因为每个栈都有自己的优势和劣势。为了进行一个公允的评估，我将从4个方面进行排名，并为每个栈分配一个1（最坏）到10（最好）的数值分：

• 　　正确性：多少实现错误已知，这些错误的严重程度？
• 　　完整性：安全实现的完整程度？
• 　　性能：安全性处理会增加多少开销？
• 　　可用性：配置安全性代码有多容易？

　　正确性

　　Axis2有很多重大的问题，核心代码和Rampart安全性模块的分离是最为关注的一个问题，不过总的来说是比较可靠的。得分：Axis2—6。

　　Metro有一些重大问题，特别是当在没有<sp:OnlySignEntireHeadersAndBody/>的情况下使用时，不能正确处理签名。尽管和Axis2一样，Metro通常是比较可靠的，但是将安全性代码集成到主要版本，比起使用Axis2发生故障的几率小一点。得分：Metro—7。

　　CXF只有相对较少的已知问题，对问题的快速反应以及较短的发布周期意味着，问题一旦发现则会得到及时更正。得分：CXF—8。

　　公平地说在这一点上，我只考虑在这些文章中直接遇到的问题。查看栈的bug跟踪系统将展示其他（可能更重要的）问题。看到这些时—报告的一些问题可能由用户错误引起—您必须小心的使用，但是如果您考虑标准化一个特定栈，这也是有价值的。参见 参考资料 获取更多关于这3个栈的bug跟踪系统的信息 。

　　完整性

　　这3个栈都对所有主要安全性标准提供支持。然而，Axis2至少在2个方面是有限制的。对于WS-Policy，Axis2代码生成只适用于2004年的旧版本，而不适用2007年发布的标准W3C版本。对于WS-SecureConversation， Axis2执行一个 “千篇一律” 的配置，忽略了您提供的任何策略配置。得分：Axis2—6；Metro—7；CXF—7。

　　性能

　　谈到安全性能排名时，Axis2无疑是失败者。就每个消息级别安全性处理而言，它比Metro或CXF需要更多的处理开销。Metro整体上比CXF快一些，因此，对于这一因素，我的分值是：Axis2—4；Metro—8；CXF—7。

　　可用性

　　Axis2的安全配置是有点令人不快。在客户端，它需要您将运行时参数嵌入服务WSDL，或者直接在您的客户端代码中进行配置。不管哪种方法，实际上您必须在您的客户端代码中激活安全性处理。在服务器端，您必须修改生成的services.xml文件来包含运行时参数或者激活安全性处理。Axis2常常也会无声无息地忽略在策略配置中它所不能理解的。得分：Axis2—5。

　　使用Metro可能比Axis2更容易一点，但它总是需要您将您的运行时参数添加到服务WSDL中（或者至少在客户端引用一个定义参数的独立文档）。我认为这是不合适的，因为WSDL应该表示公布的服务合约。Metro也提供少量关于配置和使用NetBeans/Glassfish包之外的安全性特性的文档。最后，以我的经验，当有一个配置问题时，您捕获的错误消息往往是模糊不清的，而追踪原因也很困难。得分：Metro—6。

　　CXF有最整洁的配置方法，对于运行时安全性参数，客户端和服务器端通常使用独立的文件。您也可以选择直接使用Spring，或者在您的代码中进行任何配置。除了这些基本的配置问题之外。CXF也在WSDL中支持外部策略引用，对于那些想跨平台标准化安全性策略的组织，这是一个重要的特性。最后，对于不支持的策略组件，CXF似乎有最佳的处理，生成警告消息让您知道策略不能完全支持。得分：CXF — 8。

　　表 1 总结了我的排名：

　　这些排名并不是权威的，因此，如果您要使用它们创建您自己的栈，务必要检查我的理由，并做出自己的判断。此外，这个排名只适用于基础的开源项目；基于开源版本的商业栈应该使用它们自己的安全性代码和其他扩展。您需要查看商业代码和开源代码库之间的不同，看看哪部分排名可以应用。

　　总结

　　本系列中介绍的这3个开源web服务栈到目前为止都为安全特性提供较好的支持。在安全性方面每个栈都有自己的优势和劣势，在本文中，根据我在最近的十几篇文章中使用这3个栈的经验，为您概括介绍了它们之间的区别。