WS-Security 的细粒度使用
在简单 Web 服务环境中，客户机直接连接到服务器，而服务器直接对请求执行所有必需的处理。正如本系列 上一篇文章 所述，使用 SSL 提供保护的连接可以为这类环境中的大部分应用提供出色的安全性。但是，更加复杂的环境变得越来越普遍，其中涉及到使用多层服务器处理请求。在许多企业环境中日益流行的服务编排的完整理念就是以这种方法为基础的，这与面向服务架构（SOA）的概念相同。在这些类型的环境中，必须实现更强大的 WS-Security 替代方案。
关于本系列Web 服务构成了 Java? 技术在企业计算应用中的关键部分。在 本系列文章 中，XML 和 Web 服务顾问 Dennis Sosnoski 介绍了对于使用 Web 服务的 Java 开发人员来说比较重要的主要框架和技术。通过跟随本系列的学习，您将了解到该领域的最新进展，并且知道如何使用它们来为您的编程项目提供帮助。
正如上一期文章所述，WS-Security 带来了沉重的性能代价。降低成本的方法之一就是针对由服务定义的各个操作甚至是消息设置合适的 WS-SecurityPolicy，而不是将单个 WS-Security 策略应用到整个服务。WS-Security 的细粒度使用要求考虑更多的内容，而不是使用一成不变的方法，但是如果得到正确应用的话，那么就可以减少常用操作的性能开销，同时不会减弱需要 WS-Security 的操作的安全性。
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"> <wsp:ExactlyOne> <wsp:All> <sp:AsymmetricBinding xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"> <wsp:Policy> <sp:InitiatorToken> <wsp:Policy> <sp:X509Token sp:IncludeToken=".../IncludeToken/AlwaysToRecipient"/> </wsp:Policy> </sp:InitiatorToken> ... </wsp:Policy> </sp:AsymmetricBinding> <sp:SignedParts xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"> <sp:Body/> </sp:SignedParts> </wsp:All> </wsp:ExactlyOne> </wsp:Policy> <!-- Policy for UsernameToken with plaintext password, sent from client to server only --> "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"> <wsp:ExactlyOne> <wsp:All> <sp:SupportingTokens xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"> <wsp:Policy> <sp:UsernameToken sp:IncludeToken=".../IncludeToken/AlwaysToRecipient"/> </wsp:Policy> </sp:SupportingTokens> </wsp:All> </wsp:ExactlyOne> </wsp:Policy> ... <wsdl:binding name="LibrarySoapBinding" type="wns:Library"> <wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="getBook"> <wsdlsoap:operation soapAction="urn:getBook"/> <wsdl:input name="getBookRequest"> <wsdlsoap:body use="literal"/> </wsdl:input> <wsdl:output name="getBookResponse"> <wsdlsoap:body use="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="getBooksByType">
?
清单 2 中的代码根据 ServiceClient 选项设置用户名和密码，意味着这些是针对使用该服务的所有操作定义的，即使它们只用于单个操作。与将 Rampart 模块用于所有操作不同的是，以这种方式设置用户名和密码是无害的 — 这些值只有在 Rampart 需要用之构建 UsernameToken 时使用，其他情况下将会忽略。
清单 3 展示了包含有 Rampart 配置的策略文档。这里使用了与 “Axis2 WS-Security 签名和加密” 相同的策略，现在被提取到一个独立的策略文档中。
清单 3. Rampart 客户机配置策略
?
将策略添加到 services.xml“Axis2 WS-Security 基础” 引入了一种工具，可以将模块引用和策略添加到生成的 services.xml 中，从而避免了在每次重新生成服务端代码时手动编辑文件的需要。本文使用了经过改进的工具，允许在服务配置的操作级别执行添加操作，并通过执行一次工具完成多个添加操作。改进后的版本为 com.sosnoski.ws.PolicyTool；源代码和二进制版本位于代码 下载 中的 policytool 目录。参考该目录下的 readme.txt 文件获得指导说明。
在 清单 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 头部 ?
原文：http://www.ibm.com/developerworks/cn/java/j-jws7.html