本文介绍了如何对 WebSphere Information Integrator Content Edition 的 SOAP 消息机制进行改进，以提供消息完整性和保密性。本文还解释了如何把 WebSphere IICE 现有的安全机制整合到 Web Services 安全实现中来。同时，本文也是实现 Web Services 安全机制的一次非常好的实践。
安全已经被公认为是电子商务市场成功与否的关键因素之一，尤其是在分布式系统中的Web Services应用。WebSphere Information Integrator Content Edition(以下简称为WebSphere IICE)作为企业信息集成领域的领导者，提供了若干基于SOAP消息的服务。
本文介绍了如何对WebSphere IICE SOAP消息机制进行改进，以提供消息完整性和保密性。这种机制包括使用XML 数字签名对消息进行签名来达到消息完整性，和使用XML加密对消息进行加密/解密来达到消息的保密性。本文还解释了如何把WebSphere IICE现有的安全机制整合到Web Services安全实现中来。同时，本文也是实现Web Services安全机制的一次非常好的实践。它不仅能便捷的实现安全模型、安全算法的随意扩展而且本文的实现原理能方便的移植到IBM所有需要实现Web Services安全的产品中。
1. 背景介绍和动机
WebSphere IICE作为企业信息集成的领导者，其基于J2EE框架的结构通过扩展SOAP消息接口实现了对Web Services的支持。它主要提供了三种SOAP服务，并把它们命名为WebSphere IICE Web Services。这些服务-Web Services 接口、SOAP 客户端代理和SOAP CONNECTOR代理-使得WEBSPHERE IICE能容易的部署在因特网中，并能被因特网中的其他服务访问。正是WebSphere IICE的这些特性不仅使得其各个分布式部件能异步的交互，而且还能使得WebSphere IICE各个分布式部件能无状态的交互，从而省略了会话状态管理，同时可以不必考虑实现服务的协议和服务的位置。
不幸的是，这种结构松散、协议开放的环境很容易被潜在的安全威胁所攻击。一个Web Services消息在到达目的地之前要在很多个中间介质中传递，这样拥有一个成熟的消息层面的安全机制就变得格外重要。
现在的WebSphere IICE提供的解决SOAP消息在现实电子商务网络环境中传输安全问题的技术方案还存在一些不足，譬如安全算法简单，加密结构灵活性有限等。
SOAP规范使得任何安全机制(数字签名、信息完整性保护、加密/解密等)能方便的应用到任何的基于Web Services的应用程序中。
IBM已经提供了一个完整的技术策略-WS-Security。这样整个行业就能各自实现此基于标准的结构来满足现实商业中复杂的、灵活的Web Services安全需求。通过提升Web Service核心模块的可扩展性，我们可以获得基于诸如SOAP、WSDL、XML数字签名、XML加密/解密和SSL/TLS等核心技术的解决方案。这样使得Web Services的提供者和需求者能根据各自的应用程序安全需求来开发解决方案。这些解决方案和标准使得我们能够方便的把Web Services安全解决方案和WebSphere IICE Web Services部件整合在一起。
2. 实现原理
2.1 WebSphere IICE Web Servives概述
现在WebSphere IICE提供两个层次的Web Services部件，一个是SOAP客户端代理、SOAP connector代理和Web Services API，我们把这部分叫做WebSphere IICE Web Services客户端:另外一部分是作为WebSphere IICE Web模块发布的服务器端SOAP实现。此Web模块把IICE接口作为Web Services发布出去并把这些接口和其他模块整合在一起。从技术角度来讲，WebSphere IICE Web Services部件利用了Apache Axis工具包。我们可以简单的把WebSphere IICE的两部分理解为Axis客户端和Axis服务器端。下面讲述了WebSphere IICE Web Services部件的细节。
SOAP客户代理层(如图1部件1)应用SOAP作为WebSphere IICE标准API和ACCESSSERVICES部件交互协议。
SOAP connector代理层(如图1部件2)应用SOAP作为ACCESSSERVICE EJB组件和已经部署的CONNECTOR EJB部件的交互协议。此实现机制和SOAP客户代理层的实现机制非常相象。
图1:WebSphere IICE Web Services部件
Web Services调用接口(如图1部件3)通过SOAP接口提供了WebSphere IICE整合接口的绝大部分内容。它包括一个WSDL文件，此文件定义了调用接口并且提供了一种语言无关的方式来访问 Internet 中非结构化的数据。
2.2 WebSphere IICE密文登录原理
WebSphere IICE加密机制是对BLOWFISH算法的一种实现。一旦安装成功，WebSphere IICE会使用此算法产生一个密钥文件同时要保证此文件在客户端和CONNECTOR端的CLASSPATH中。如下是应用BLOWFISH进行加/解密的一个过程示例。
列表1:应用blowfish进行加、解密过程
客户端的加密过程：
//Create and encrypt an AuthBundle. AuthBundle aB = new AuthBundle(user, password); try { //Encrypt the auth bundle (new BlowfishSealer()).seal(aB); } catch(KeyNotFoundException knfe) { ... } 服务器端的解密过程：...use the sealed bundle to logon to a chosen repository. .. // Unseal the auth bundle if sealed. if(authBundle.isSealed()) { // Instantiate an unsealer proxy. UnsealerProxy uP = new UnsealerProxy(); try { // Attempt to unseal the bundle. // The UnsealerProxy will delegate unsealing// to a new instance of "my.magic.Unsealer" uP.unseal(authBundle); } catch(UnsealerNotFoundException unfe) { throw new LogonException("Unable … unsealer.", unfe); } catch(KeyNotFoundException knfe) { throw new LogonException("Unable ….", knfe); } catch(InvalidKeyClassException ikce) { throw new LogonException("Invalid decryption...", ikce); } catch(EncryptionException ee) { throw new LogonException("An error ….", ee); } } ... 2.3 WebSphere IICE Web Services SOAP消息安全概述
由于WebSphere IICE使用Axis作为SOAP引擎，我们首先需要了解一下Axis的机制。可以说，Axis的任务就是处理消息。当Axis的核心处理逻辑启动时，一系列的句柄会被顺序的调用。调用的顺序是由两个因素来决定的--部署文件和此引擎为客户端还是服务器端。
WebSphere IICE Web Services会被一系列的客户端和服务器端Axis/JAX-RPC句柄处理。为了能使此安全解决方案正常工作，这些句柄必须被安装并且要保证安装顺序正确。本文提供了两套句柄分别实现消息的加密/解密和消息完整性验证功能，同时要保证这四个句柄被正确的安装在客户端和服务器端的WSDD配置文件中，这样才能保证对于每一个从客户端发出的消息都被客户端的证书加密和签名，同时才能保证服务器端接受到的每一个消息都是被验证的而且每一个消息都经过了解密。这样我们就实现了SOAP消息的完整性和机密性。
同时，用户可以选择是否使用此安全机制。如果用户倾向于非安全机制，他所需要做的就是注释客户端和服务器端的WSDD配置文件。
本文来源：https://www.2haoxitong.net/k/doc/5ed840d6360cba1aa811daa8.html
文档为doc格式