本文介紹了如何對 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產品的應用場景。