運用Web Services安全機制對SOAP訊息加密

作者: 趙雪山, 　出處:developerWorks中國 ,　責任編輯: 葉江,　2006-04-20 13:56　
　本文介紹了如何對 WebSphere Information Integrator Content Edition 的 SOAP
訊息機制進行改進，以提供訊息完整性和保密性。本文還解釋了如何把 WebSphere IICE 現有的安全機制整合到 Web Services
安全實現中來。同時，本文也是實現 Web Services 安全機制的一次非常好的實踐。

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