首页 > 学院 > 开发设计 > 正文

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

2019-11-18 12:42:56
字体:
来源:转载
供稿:网友

  引言
  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 AS 中使用 Web 服务安全性(图一)

  
  样本帐户服务
  WebSphere Application Server V5.0.2 有一种方便而强大的方式来启用 WS-Security,从而为应用程序的通信链路提供 MLS。它可以让您获取现有的任何服务的 Web 服务描述语言(WSDL),并为您提供必要的 WS-Security 扩展和绑定来保护 Web 服务客户端和服务器之间的消息。
  
  本文假定已经有了一个要应用 WS-Security 必须启用的 Web 服务。这里使用的示例服务是 AccountService,它是由一个假设的银行(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 客户端

  
 在 WebSphere AS 中使用 Web 服务安全性(图二)

  客户端的缺省选择是可用的,可以用它们来测试刚刚安装的 AccountService。单击 Submit,您将会看到如图 3 所示的结果页面。
  
图 3. 客户端结果页面

  
 在 WebSphere AS 中使用 Web 服务安全性(图三)

  现在我们已经成功地安装了服务和客户端,现在让我们回顾一下客户端的输入选项:
  
  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 治理窗口

  
 在 WebSphere AS 中使用 Web 服务安全性(图四)

  在 Listen Port # 字段中键入可用的端口(例如,9999)。
  在 Target Hostname 字段中键入 localhost。
  在 Target Port # 字段中键入 9080。
  单击 Add,这样就会显示一个面板,该面板监听端口 9999 并将请求转发给 localhost:9080。
  现在,请切换到显示 AccountService 客户端的浏览器,在 Service Port 字段中键入端口 9999。单击 Submit。
  Account Service 客户端具有如上所述的行为。在 tcpmon 面板中,请注重请求(上面板)和响应(下面板)消息,如图 5 所示。
  
图 5. Tcpmon 显示截获的消息

  
 在 WebSphere AS 中使用 Web 服务安全性(图五)

  请仔细观察这些消息,非凡是 SOAP 头部和主体。找出请求的 SOAP 主体,

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表