Java web 服务: web 服务安全性状态

了解在主要开源 Java web 服务栈中安全性处理的当前状态

WS-Security 和相关标准为 web 服务安全性提供了广泛的选择。由于范围很广,web 服务栈仅独立测试有限数量的安全性配置,甚至更少的互操作性配置。找出业界对于提升 web 服务栈之间的互操作性做了哪些努力,并阅读这 3 个主要开源 Java™ 栈处理安全性方式的一个概要比较。

Dennis Sosnoski, 咨询师, Sosnoski Software Associates Ltd

Author photoDennis Sosnoski 是一名咨询师和培训师,专长是基于 Java 的 XML 和 Web 服务。他有 30 多年的专业软件开发经验,最近 10 年一直致力于服务器端 XML 和 Java 技术方面的工作。Dennis 是开源 JiBX XML Data Binding 框架及相关的 JiBX/WS Web 服务框架的首席开发人员,也是 Apache Axis2 Web 服务框架的提交者。他还是 JAX-WS 2.0 和 JAXB 2.0 规范的专家组成员之一。



2011 年 4 月 06 日

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

关于本系列

Web Services 是企业计算中 Java 技术的重要组成部分。在本系列文章中,XML 和 Web 服务咨询师 Dennis Sosnoski 介绍了两个对于使用 Web Services 的 Java 开发人员来说非常重要的主流框架和技术。阅读本系列文章来了解这个领域的最新开发动态,并了解您可以如何使用它们来帮助您的编程项目。

一个重要的不同之处就是安全性实现的完整性和正确性。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,而不是一个性能问题,因为问题有不断发展的天性。

在任何时候只要使用安全性,操作就会逐步减慢(参见 “CXF 性能比较” 寻找原因 ),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 总结了我的排名:

表 1. Web 服务栈排名
Apache Axis2Sun/Oracle MetroApache CXF
正确性678
完整性677
性能487
可用性568
总计212830

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


总结

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

本系列的下一期文章将采取另一种方法,研究 WSDL 服务定义的结构,并开发一个工具来验证 WSDL 并将它们转换成推荐的最佳实践格式。

参考资料

学习

讨论

  • 加入 developerWorks 中文社区。查看开发人员推动的博客、论坛、组和维基,并与其他 developerWorks 用户交流。

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Java technology, SOA and web services, Open source
ArticleID=644925
ArticleTitle=Java web 服务: web 服务安全性状态
publish-date=04062011