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

核心提示：在简单 Web 服务环境中，客户机直接连接到服务器，Java Web 服务: WS-Security 的细粒度使用，而服务器直接对请求执行所有必需的处理，正如本系列 上一篇文章 所述， getBooksByType 需要授权（因此要使用 UsernameToken），addBook 操作需要一个审计跟踪，使用 SSL

在简单 Web 服务环境中，客户机直接连接到服务器，而服务器直接对请求执行所有必需的处理。正如本系列 上一篇文章 所述，使用 SSL 提供保护的连接可以为这类环境中的大部分应用提供出色的安全性。但是，更加复杂的环境变得越来越普遍，其中涉及到使用多层服务器处理请求。在许多企业环境中日益流行的服务编排的完整理念就是以这种方法为基础的，这与面向服务架构（SOA）的概念相同。在这些类型的环境中，必须实现更强大的 WS-Security 替代方案。

正如上一期文章所述，WS-Security 带来了沉重的性能代价。降低成本的方法之一就是针对由服务定义的各个操作甚至是消息设置合适的 WS-SecurityPolicy，而不是将单个 WS-Security 策略应用到整个服务。WS-Security 的细粒度使用要求考虑更多的内容，而不是使用一成不变的方法，但是如果得到正确应用的话，那么就可以减少常用操作的性能开销，同时不会减弱需要 WS-Security 的操作的安全性。

定义策略

本文使用的样例策略与 “Axis2 WS-Security 基础” 和 “Axis2 WS-Security 签名和加密” 中的策略相同 — 一个简单的库管理服务。这个服务定义了三种操作：

getBook，检索由 International Standard Book Number (ISBN) 标识的特定图书的细节。

getBooksByType，检索某一类型的所有图书的细节。

addBook，向库中添加一本新书。

为了向安全用例中添加一些有趣的变化，本文作出以下假设：

getBook 操作可以安全地公开给任何人（未应用安全性）。

getBooksByType 需要授权（因此要使用 UsernameToken）。

addBook 操作需要一个审计跟踪，以跟踪是谁添加了图书（通过对请求消息进行签名实现）。