Java Web 服务: WS-Security 的细粒度使用

核心提示： 在 清单 5 中，可以看到一个 Rampart 模块引用和一个服务器配置策略的副本被添加到使用 WS-Security 的两个操作的定义中，Java Web 服务: WS-Security 的细粒度使用(7)，这两个操作分别为 getBooksByType 和 addBook，这些修改将服务配置

在 清单 5 中，可以看到一个 Rampart 模块引用和一个服务器配置策略的副本被添加到使用 WS-Security 的两个操作的定义中，这两个操作分别为 getBooksByType 和 addBook。这些修改将服务配置为只针对这两个操作使用 Rampart，并对 Rampart 的键和证书访问使用提供的设置。

如果构建生成的 AAR 文件并部署到一个 Axis2 服务器安装中，可以在 Administration/Available Services 页面中看到这些操作的结果，在这个页面中，将列出由服务定义的每个操作使用的模块。如果运行客户机代码并监视消息交换（使用 TCPMon 之类的工具，像 “Axis2 WS-Security 基础” 中描述的那样），您会看到安全处理将按照我们的期望运行：

getBook 消息中不存在 WS-Security 头部

getBooksByType 请求消息中有一个包含 UsernameToken 的 WS-Security 头部

addBook 请求（而不是响应）消息中有一个包含签名的 WS-Security 头部

Axis2/Rampart 限制

Axis2 和 Rampart 目前（也就是说，使用最新的 Axis2 1.5 发行版和一个 Rampart 夜间构建版）能够处理 WSDL 中内嵌的基本 WS-SecurityPolicy 配置，包括在操作或消息级别定义的粒度策略。然而，本文尝试的一些配置无法用于 Axis2/Rampart。例如，尝试为 addBook 操作设置 UsernameToken 策略（除了对输入消息使用签名策略外），结果将导致一个明显与 Rampart 代码加密有关的错误（即使没有使用任何加密）。从这些经验以及一些问题报告中可以判断出，Axis2/Rampart WS-SecurityPolicy 处理适合用于可以反映常见用例的简单配置，但是当应用到不常见的组合时，却容易出现错误。

另一个问题是，在服务器上使用 Rampart 产生的开销始终会出现在请求和响应处理中，即使您只对其中一条消息应用 WS-Security（像 “WS-Security 的大开销” 所讨论的那样）。在客户端，情况更糟糕 — 因为在客户机上使用 Rampart 目前是一种全有或全无的主张，如果在任何 操作上使用 WS-Security，那么不得不忍受每个 操作中产生的 Rampart 开销。

最后，目前的 Axis2/Rampart WS-Policy 处理并不支持策略替代方案。替代选择是 WS-Policy 设计的一个主要特点，使客户机在访问服务时可以从两个或多个可行配置中选择要使用的配置。Axis2/Rampart 策略实现并不支持这个特性，而是忽略除第一种替代选择以外的所有选择。

结束语

通过本文和前三篇文章， Java Web 服务 系列文章介绍了 Axis2/Rampart 中的 WS-Security 和 WS-SecurityPolicy 处理的所有主要方面，包括性能问题。在未来几期文章中，您将了解其他 Java Web 服务框架如何使用 WS-Security 和 WS-SecurityPolicy，但是首先需要查看 Axis2 的其他两个方面。

对于许多组织而言，一个重要的问题就是支持 Java Architecture for XML Binding (JAXB) 2.X。JAXB 2.X 是面向 XML 数据绑定的官方 Java 标准，尽管开源替代方案提供了自己独特的优势，一些组织仍然坚持使用该标准。在下一期文章中，您将看到如何结合使用 JAXB 2.X 数据绑定和 Axis2，并将它与其他受 Axis2 支持的数据绑定选择进行比较。

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