在 WebSphere AS 中使用 Web 服务安全性

　　 
　　引言
　　Web 服务是一些虚拟软件组件，可以通过各种协议和格式对它进行访问和调用。这些组件所处的环境各不相同且是分布式的。因此，需要一个安全通信基础架构来确保这些组件之间的消息（和内容）的安全性。
　　

　　Web 服务安全性（Web Services Security ，WS-Security 或 WSS） 十分灵活，可以将它设计成一个基础平台，可以在此平台上构建各种安全模型，包括公钥基础架构（PKI）、Kerberos 和安全套接字层（SSL）。特别是，WS-Security 支持多种安全性令牌、多种信任域、多种签名格式以及多种加密技术。
　　
　　这个规范提供了三种主要机制：
　　
　　安全性令牌传播
　　消息完整性
　　消息机密性。
　　
　　这些机制本身并不提供完整的安全性解决方案。相反，WS-Security 是一个构件，它可以与其他的 Web 服务扩展及更高层的特定于应用程序的协议一起使用，从而提供各种各样的安全性模型和加密技术。这些机制可以独立使用（例如，用于传递安全性令牌），也可以非常紧密地集成在一起（例如，签名和加密消息，以及提供与用于签名和加密的密钥相关联的安全性令牌层次）。
　　
　　本文假定您具有一定的 Web 服务、J2EE 技术及 WebSphere® Application Server V5.0.2 的基本知识。通过阅读本文，您将会理解如何在现有的基础架构上使用 WS-Security，同时也将了解一种声明性的编程模型，即 WebSphere Application Server V5.0.2 提供保护应用程序的通信基础架构。
　　
　　WebSphere Application Server V5.0.2 中的 WS-Security
　　WebSphere Application Server V5.0.2 通过一种声明性模型来使用 WS-Security。这种模型的创建和修改可以通过 WebSphere Studio Application Developer Version 5.1、WebSphere Application Server V5.0.2 中可用的应用服务器工具包（ASTK）或 WebSphere 管理控制台来完成。为了更深地理解这一技术，我们将在此描述一下手动过程。
　　
　　可以传播的安全性令牌是 Username 令牌、基于 X.509 的证书以及轻量级第三方验证（LTPA）；同时还有一个 API 来为用户定义的令牌提供插件。消息完整性是由基于 PKI 的数字签名提供的（目前还不支持对称密钥签名），而消息机密性是由 XML 加密法提供的。
　　
　　WebSphere 安全性处理程序通过读取已声明的部署扩展来获取配置和实施 WS-Security 基础架构，如图 1 所示。它们被实现为基于 WebSphere 运行时的 JAX-RPC 处理程序，并且对于应用程序开发人员是透明的。
　　
　　图 1. WebSphere Application Server V5.0.2 中的 WS-Security
　　　
　　
　　样本帐户服务
　　WebSphere Application Server V5.0.2 有一种方便而强大的方式来启用 WS-Security，从而为应用程序的通信链路提供 MLS。它可以让您获取现有的任何服务的 Web 服务描述语言（WSDL），并为您提供必要的 WS-Security 扩展和绑定来保护 Web 服务客户端和服务器之间的消息。
　　
　　本文假定已经有了一个要应用 WS-Security 必须启用的 Web 服务。这里使用的示例服务是 Aclearcase/" target="_blank" >ccountService，它是由一个假设的银行（SomeBank）提供的。
　　
　　AccountService 是一个简单的 Web 服务；出于演示的目的，它并没有执行真正的业务处理。它包含一个简单的操作 accountEnquiry，这一操作获取 AccountRequest 消息并返回 AccountResponse 消息。AccountRequest 消息包含有 AccountID 和 AccountType 信息。AccountResponse 包含有帐户信息传递之后的结算。accountEnquiry 操作并没有执行任何基于请求消息的处理，而是返回一个固定的结算值 12345.0。然而，这些消息是很重要的，因为我们将要使用 tcpmon（一个真正监听消息的实体）来监控它们在线路中传送的情况——首先看采用不安全的消息格式的情况，然后再看具有各种 WS-Security 配置的情况。
　　
　　为了演示的方便，我们在服务中将 accountEnquiry 操作作为四个独立的端口公开；配置 WS-Security 之后就会使用这些端口。然而，对于不安全的服务来说，所有的端口都是相类似的。在为 AccountService 配置 WS-Security 时会讨论这些端口。
　　
　　我们先来安装 AccountService 和它的客户端。
　　
　　安装和运行不安全的服务
　　要安全和测试不安全的 AccountService，您需要执行以下的操作：
　　
　　下载 WSS-Sample.zip 文件并将其解压到一个临时文件夹中。
　　使用 WebSphere 管理控制台来安装企业应用程序 AccountService（即 SomeBankService.ear 文件）。可在 code/service 目录下安装。请确保选择的是缺省的选项，并在安装后保存配置。
　　使用控制台来启动企业应用程序。
　　打开一个浏览器，访问 http：//localhost：9080/SomeBankService/services/SomeBankPort 来测试服务是否可用 。如果您得到消息“And now ... Some Services”，就表明您已经成功地配置了 SomeBank AccountService。
　　您还可以访问 http：//localhost：9080/SomeBankService/services/SomeBankPort?WSDL 来检查 AccountService WSDL 是否可用。该 WSDL 必须和附录所示的 WSDL 相类似。
　　
　　安装和运行不安全的客户端
　　要安装 AccountService 的客户端，您需要执行以下的操作：
　　
　　使用 WebSphere 管理控制台来安装 Web 应用程序（即 SomeBankClient.war 文件）。可在 code/client 目录下安装。在安装 WAR 文件时，请确保在 Web 模块中键入 Context Root。请选择缺省值，并在安装后保存配置。
　　使用控制台启动 Web 应用程序。
　　打开一个浏览器，访问 http：//localhost：9080/<context-root> 来测试一下客户端是否正确安装。
　　您将会看到图 2 所示的屏幕。
　　图 2. AccountService 客户端
　　　
　　客户端的缺省选择是可用的，可以用它们来测试刚刚安装的 AccountService。单击 Submit，您将会看到如图 3 所示的结果页面。
　　图 3. 客户端结果页面
　　　
　　现在我们已经成功地安装了服务和客户端，现在让我们回顾一下客户端的输入选项：
　　
　　Account ID and Account Type： 这些是虚构的输入，因为服务响应是固定的。但是它们也是重要的，因为在您使用 tcpmon 来监控消息时您将会看到它们。
　　Message Encryption： 在配置 WS-Security 之后打开线路中的消息的 XML 加密，从而提供消息的机密性。
　　Message Signing：在配置 WS-Security 之后打开线路中的消息的 XML 数字签名，从而提供消息的完整性。
　　Service Port：指向基于 HTTP 的端口，在这一端口中服务是可用的。您可以使用这一选项来指向一个 tcpmon 代理端口（将在下面讨论），以便观察 Web 服务请求和响应消息。
　　Transport Protocol：用于选择是否使用 SSL。如果选中 HTTPS，则客户端就会被局限于使用 WebSphere 内部 SSL 端口 9443。显然，如果这样选择的话，tcpmon 就不能够在线路中观察消息了。
　　
　　因此，同时使用 MLS 和 TLS 来配置安全性选项时会有八种组合，由以下选项构成：
　　
　　XML 加密 [启用/禁用]
　　数字签名 [启用/禁用]
　　SSL [启用/禁用]。
　　这使得客户端具有足够多的选择来观察 WS-Security 机制。
　　
　　使用 tcpmon 来观察消息
　　tcpmon 是 WebSphere Application Server V5.0.2 附带的一个实体。通过代理端口，tcpmon 可以用于查看和检查 SOAP 消息（请求和响应）。
　　
　　要配置 tcpmon 以便在不安全的场景中监控消息，您需要执行以下的操作：
　　
　　检查 <WAS_HOME>/bin 目录中是否有一个 tcpmon.bat 文件。如果有，则直接执行步骤 3。
　　将清单 1 复制和粘贴到一个文件中，从而创建 tcpmon.bat 文件。
　　清单 1. tcpmon.bat 的源代码
　　@REM Copyright IBM Corp. 2002 ，2003
　　@setlocal
　　@echo off
　　
　　SET CONSOLE_ENCODING=-Dws.output.encoding=console
　　
　　call "%~dp0setupCmdLine.bat"
　　"%JAVA_HOME%\bin\java" %CONSOLE_ENCODING% "-
　　Dws.ext.dirs=%WAS_EXT_DIRS%;%WAS_USER_DIRS%" -classpath
　　"%WAS_HOME%"\lib\webservices.jar;"%WAS_CLASSPATH%";"%CLASSPATH%"
　　com.ibm.ws.bootstrap.WSLauncher com.ibm.ws.webservices.engine.utils.tcpmon
　　
　　@endlocal
　　
　　运行 tcpmon.bat 程序，您将会看到图 4 所示的屏幕。
　　图 4. Tcpmon 管理窗口
　　　
　　在 Listen Port # 字段中键入可用的端口（例如，9999）。
　　在 Target Hostname 字段中键入 localhost。
　　在 Target Port # 字段中键入 9080。
　　单击 Add，这样就会显示一个面板，该面板监听端口 9999 并将请求转发给 localhost：9080。
　　现在，请切换到显示 AccountService 客户端的浏览器，在 Service Port 字段中键入端口 9999。单击 Submit。
　　Account Service 客户端具有如上所述的行为。在 tcpmon 面板中，请注意请求（上面板）和响应（下面板）消息，如图 5 所示。
　　图 5. Tcpmon 显示截获的消息
　　　
　　请仔细观察这些消息，特别是 SOAP 头部和主体。找出请求的 SOAP 主体，

原文转自：http://www.ltesting.net