运用Web Services安全机制对SOAP消息加密

作者: 赵雪山, 　出处:developerWorks中国 ,　责任编辑: 叶江,　2006-04-20 13:56
　
　本文介绍了如何对 WebSphere Information Integrator Content Edition 的 SOAP
消息机制进行改进，以提供消息完整性和保密性。本文还解释了如何把 WebSphere IICE 现有的安全机制整合到 Web Services
安全实现中来。同时，本文也是实现 Web Services 安全机制的一次非常好的实践。

document.write('');

　　本文介绍了如何对 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配置文件。
2.4 WEBSPHERE IICE WEB SERVICE SOAP消息安全实现细节

　　A. 配置

　　WebSphere IICE Web Services安全机制的配置工作是由客户端和服务器端两部分组成的。就如下面的配置文件实例说描述的一样，SOAP消息会在它被发送到目标服务器之前分别被不同的句柄签名和加密。相对应的，它也会在服务器端被验证和解密。

　　列表2:AXIS客户端配置文件示例

<globalConfiguration> <requestFlow> <handler type="java:com.venetica.vbr.webservices.handler.X509SignHandler"/> <handler type="java:com.venetica.vbr.webservices.handler.EncryptHandler"/> </requestFlow> <responseFlow> <handler type="java:com.venetica.vbr.webservices.handler.X509SignHandler"/> <handler type="java:com.venetica.vbr.webservices.handler.DecryptHandler"/> </responseFlow> </globalConfiguration>

　　服务器端的配置文件和客户端的配置文件非常相像。

　　B. 签名和加密/解密过程:

　　SOAP消息的签名和加密/解密过程如图2所示:



　　图2:SOAP消息的签名和加密/解密过程

　　列表3: XML签名示例代码

public Message signSOAPEnvelope(SOAPEnvelope unsignedEnvelope) throws Exception { // WSSignEnvelope signs a SOAP envelope according to the // WS Specification (X509 profile) and adds the signature data // to the envelope. WSSignEnvelope signer = new WSSignEnvelope(); String alias = "username"; String password = "password"; signer.setUserInfo(alias, password); Document doc = unsignedEnvelope.getAsDocument(); Document signedDoc = signer.build(doc, crypto); // Convert the signed document into a SOAP message. Message signedSOAPMsg = (org.apache.axis.Message)AxisUtil.toSOAPMessage(signedDoc); return signedSOAPMsg; }

　　列表3显示了XML签名的过程:首先得到SOAP信封，接下来是获得用户证书信息、产生签名对象，然后是用此签名对象对信封进行签名，最后是从被签名的信封中产生新的SOAP消息。

　　列表4:XML加密示例代码

public Message encryptSOAPEnvelope(
SOAPEnvelope unsignedEnvelope, Message axisMessage)
throws Exception
{
WSEncryptBody encrypt = new WSEncryptBody();
// build the encrypted SOAP part
Document doc = unsignedEnvelope.getAsDocument();
Document encryptedDoc = encrypt.build(doc, crypto);
// Convert the document into a SOAP message
Message encryptedMsg =
(Message)AxisUtil.toSOAPMessage(encryptedDoc);
// Retrieve the desired SOAP part
String soapPart = encryptedMsg.getSOAPPartAsString();
((SOAPPart)axisMessage.getSOAPPart()). setCurrentMessage(soapPart, SOAPPart.FORM_STRING);
encryptedDoc =axisMessage.getSOAPEnvelope().getAsDocument();
// Convert the document into a SOAP message
Message encryptedSOAPMsg = Message)AxisUtil.toSOAPMessage(encryptedDoc);
return encryptedSOAPMsg;
}
　　列表4显示了加密过程:首先获得加密前的SOAP信封，接下来获得用户的证书信息并以此产生加密对象，然后是应用此加密对象对获得的SOAP信封进行加密，最后为根据被加密之后的SOAP消息产生新的SOAP消息并向下传递。

　　C. 消息对比:

　　图3和图4分别显示了签名消息和加密消息的对比情况。



　　图3:应用数字签名前后SOAP消息对比



　　图4:应用安全加密前后SOAP消息对比

　　3. 益处

　　A 本实践不仅有效的提高了WebSphere IICE Web Services SOAP消息的安全性，而且满足了对用户具有很大意义的新需求。

　　B 本实践提供了一个实现当前最新的、炙手可热的Web Services安全标准并把它应用于IBM产品的示例。

　　C 本实践提供了怎样把当前较新的技术和IBM已有的解决方案整合在一起来满足用户新的需求的示例。

　　D 本实践很好的显示了怎样在使用Web Services技术的IBM产品中应用Web Services安全。

　　E WebSphere IICE安全实现机制拥有良好可扩展性。

　　4. 结论

　　本实践对WebSphere IICE的Web Services SOAP消息安全机制进行了改良。同时提供了一个把最新技术标准应用于IBM产品的示例。这样不仅满足了用户新的需求而且很好的扩展了IBM产品的应用场景。