WWS發展現況之剖析

包括SOAP和WSDL在內的各種豐富XML標準和通訊協定，可以讓XML的資料在不同的系統之間，透過Internet來互相交換，而不必考慮雙方系統之軟體的相容性問題。換句話說，Web服務是一個在Internet上真正實用的平台，它可以讓任何一段網上軟體和另一段軟體，在網路上以豐富及安全的方式來互通互動，並不用去管它們是用何種電腦語言所寫，也不用去管它們是在何種作業系統環境上運行。

這代表Web服務可以讓人們去打造那些以豐富通訊協定導向（Rich protocol oriented）的程式應用，而不用煩惱如何去建造底層的基礎，也不用去外面買特殊的佇列軟體或插入附加的軟體，因為在系統之中已提供了豐富的功能。

比爾蓋茨表示，Web服務各種標準和通訊協定的重要性，而且這一堆的豐富通訊協定已受到一個稱為「網路服務相容性組織（WS-I）」的監控和背書。

WS – Security是這些Web服務標準和通訊協定的核心元件，它讓使用Web服務通訊協定的訊息不會受到位址欺偽攻擊（Spoofing Attack），或是重送攻擊（Replay Attack）。但由於這個WS-Security 的標準使用到好幾層的通訊協定軟體，並不容易編寫，所以要將它放到執行時的Runtime中，使程式應用的程式設計師省去打造和安全相關的底層軟體的麻煩。

Web服務核心問題

筆者認為雖然比爾蓋茨的這一段演說中，有很多在技術上值得商榷的細節，但他的重點是在強調，Web服務是一個可以讓在Internet上實行電子商務的技術。而在Web服務技術的核心，則是Web服務網路安全問題，這是一個非常重要的重點。

2003年3月中，美國市埸調查公司嘉納集團（Gartner Group）公布了一項網路安全的分析和調查報告。它指出在企業資訊人員的觀點中，最受矚目的11項網路安全議題，名列第一位的就是Web服務安全問題。

在過去一年裡，很多和網路安全相關的研討會中，嘉納集團的這項報告被廣泛地引用，但也常被台下的觀眾詢問， Web服務的安全問題到底出在哪裏？為何它會成為最熱門的網路安全議題呢？

讓美夢成真的Web服務

首先，我們來看一看究竟什麼是讓電子商務美夢成真的Web服務呢？基本上，Web服務是一個有超強能力的新型電腦運算模式，它可以讓分散各地的系統以一種平台和電腦語言中性的方式，透過Internet用標準的通訊協定來交換資訊，進而達到系統和系統之間互通和互動的目標。

Web服務是一套以Internet及Intranet為基礎的完整模組化應用程式，它的運算方式是以XML的文件為重心，並透過XML的各種標準規範，來作為信息傳輸的格式。此外，也藉著XML文件在網上的傳輸，在複雜的系統間互動，並自動被一個或多個應用程式來啟動和呼叫，以完成一組特定的服務工作。

Web服務提供了一種簡單且順暢的機制，它採用XML和SOAP等標準的運算方式，讓網際網路上的程式邏輯模組可以被出版、發掘以及呼叫。這些模組在網路上相互運作，並用鬆散耦合的方式相互結合，讓應用程式與應用程式之間的溝通，不必經由人力的操作介入，就能夠自動做互動。

Web服務的掘起，讓企業的電腦運算進入了一個新紀元，也因為這個由包括IBM和微軟等眾多軟體巨頭們所一致支援的平台中性互通方法，讓企業可以打造並部署分散式應用程式，而不必考慮在網路上通信的雙方之硬體平台、作業系統、程式語言，以及網路拓樸等等因素。

在資訊的歷史上面，這是第一次可以將新開發系統和舊有系統，用一個共通的語言和一組共同的資料互換方法去整合起來。簡單地說，這次的資訊革命是讓微軟、非微軟、新和舊的軟體都可以互通。

更重要的一點是IBM和微軟等軟體公司都投下了鉅資，全力推展這一個可以讓微軟的.Net系統和非微軟所開發的Java系統在網路上互通互動。並且Web服務可以讓各個機關和企業的系統和應用程式，透過無遠弗屆的Internet來進行整合，不受各企業間防火牆的限制。

目前包括微軟、IBM以及昇陽在內的大大小小軟體公司都一致支持Web服務技術，並聯手創立一個名為WS – I的標準組織。WS-I專注於軟體廠商間Web服務的互通問題，讓各家公司推出的Web服務技術能彼此相容，所以這組織的重點在於提倡工具與平台的相容性，而不是在於新標準的制訂工作。

如圖一所示，左端是傳統的網頁，而右端則是Web服務的網上應用程式模組、分散式部署和鬆散耦合的協同合作。使用大家都同意的標準運算方式，最適合將各種傳統的系統整合起來，並創造出新的網上應用程式，充分發揮網路上數位應用的功能，讓電子商務能夠在Internet上進行的美夢成真。

《圖一　傳統網頁和Web服務》

美夢成真的最大障礙

讓電子商務美夢成真最大的障礙，是在於Web服務的網路安全問題。不論是大型或是中小企業，都因為Web服務的興起，而計劃利用它來進入電子商務的領域之中，以實現當年網路泡沫化之前，未完成的電子商務夢想。

但網路的安全問題是影響電子商務成敗的最重要問題之一，即沒有安全的網路，就不會有成功的電子商務；沒有安全的Web服務就不會有起飛的電子商務；沒有整體的Web服務安全解決方案，就不會有實現電子商務夢想的可能。然而，網路安全問並不是一蹴可及的，它有一定的技術難度，所以Web服務技術的核心是Web服務網路安全問題。

Web服務這種的運算方式是以XML文件為重心，藉著XML文件在網上的傳輸，啟動複雜的系統間互動，讓不同的系統得以在網路上整合起來。在這種情況之下，一個XML的信息可能會繞送經過好幾個節點，而不只是傳統的網路一對一或點對點的通信方式。

當企業欲採用Web服務這種新的分散式技術時，也期望這個技術能和傳統的分散式應用程式一樣，有一個強而有力的安全基礎。也就是說，用Web服務將不同的系統來整合新興數位應用，再經過了多重節點時，要有一個完整端點到端點的安全解決方案，才不會讓網路上橫行的駭客有機可乘。

從網路安全的角度來看，這種經過多重節點的Web服務，顛覆了傳統以連接導向（Connection Oriented）的點對點安全機制。在Web服務的環境之中，需要一個新的端點到端點安全機制，不論一個XML的信息繞送過多少個節點，都要能在其SOAP的信息之中，確保其安全。

像是原先在Internet上最為廣泛應用的SSL安全機制，由於過於簡單，以至於不能在這種Web服務的新環境下，獨挑大樑來擔任完全的安全防禦任務了。以(圖二)的例子來看，左端的傳統網頁可以用SSL來保障安全，但是右端還有一大串連接是在SSL的保障之外。

因此，Web服務不被採用的最大障礙在於缺乏安全；假如有了安全，相信Web服務的市埸馬上就能夠成長加倍；反之如果沒有安全，就不可能達到市場成長的目標。

Web服務的安全標準 – WSS

比爾蓋茨在2004 RSA網路安全會議中表示，微軟對於Web服務的網路安全問題的答案就是WS – Security，其實這個說詞有些值得商榷的地方。首先，WS – Security只是一個標準規範，並不是一個切實的安全解決方案；其次，WS – Security的本身並不能解決像是扮豬吃老虎般的位址欺偽攻擊，或是狸貓換太子般的重送攻擊。

WS-Security規範的本身，是經過了好幾次的具體化。2001年十月時，微軟單獨推出WS – Security規範的第一個版本；到了2002年四月，IBM和微軟聯合發表Web服務世界之安全文件，在其中界定了一個Web服務的安全架構，並又和Verisign公司聯手推出了新版本的WS – Security草案。

2002年六月，WS – Security被正式呈送到標準組織OASIS。由於OASIS同時也掌管了好幾個和Web服務安全相關的標準，諸如XKMS、SAML、XACML，及XML生物辨識用途的XCBF等，因此被業界公認是WS – Security非常理想的歸宿。

OASIS特別成立了一個Web服務安全技術委員會（WSS – TC），來主持Web服務網路安全標準的開發工作，並且研議和Web服務安全相關之各項議題，目前筆者也是該委員會擁有投票表決權的正式委員之一。

在Web服務的網路安全標準規範方面，WSS-TC早已將原來由IBM和微軟領軍的WS – Security草案，改名為OASIS的Web Services Security（WSS）。在經過近兩年的努力後，WSS標準和原先的WS – Security已有很大的區別。WSS – TC本身並不希望別人將它所制訂的新WSS標準和原先微軟的WS – Security標準混淆，但包括比爾蓋茨在內，一般人還是將這兩個標準畫上一個等號。

目前WSS主要的規範是SOAP信息的安全規範、 X.509數位憑證和用戶名稱的安全令牌（Username Token）。這三本規範的現在已由技術委員會的表決通過，正式呈交OASIS的發展會員表決。如果沒有意外，預計在2004年四月初就成為OASIS正式的1.0版本。WSS成為OASIS正式標準，將會是Web服務界的一件大事，因為一般都認為這是繼SOAP、WSDL和UDDI之後，讓各界最期待的Web服務標準。

安全標準大集合

在XML和Web服務的安全標準中，WSS並不是一項創舉，例如掌控XML文件安全的XML資料加密（XML Encryption）、XML數位簽章（XML Digital Signature）、管理擷取權限的XACML標準（OASIS Extensible Access Control Markup Language）、從XML文件安全再進階到XML資訊安全的金鑰管理所用的XKMS（XML Key Management Specification，XML金鑰管理規範），以及提供單一簽入認證與授權的SAML（Security Assertion Markup Language）等標準和技術，都是早已存在的一些和Web服務安全相關的技術和標準。

不過WSS這個標準和上面的這些標準不同，它主要是集合上述標準之大成，並專注在如何保障SOAP信息的安全上面。

在概念上，Web服務所使用的SOAP信息，就好像一個裝有XML文件的信封。信封內裝的可以是XML的主文，也可以是一個或多個附件。在信封上除了有收件人和寄件人的位址資料之外，還有各種處理內文的相關指示。

WSS是用來定義信件內的各種資料加密及電子簽章的記號，以及如何使用XML之規範來處理信息內文件的加解密和簽章和驗證簽章的各項事宜。同時，它也規範了如何驗證送件人的身份等SOAP標頭。

如圖二所示，WSS集合了底層訊息傳輸的SOAP、私密性和完整性的SSL、XML資料加密、XML數位簽章、身分驗証令牌用的X.509、SAML，Kerberos、授權及存取控制用的XrML和XACML，公開金鑰的憑証，以及XKMS等。WSS集合了各種在XML上的安全標準，而成為Web服務信息安全上的大統帥。

《圖二　Web Services Security》

WSS規範之內容

WSS規範組合了各種標準和技術，讓採用不同安全技術的公司，可以用SOAP通訊協定安全地在網上互通訊息。例如一個公司主要是以用戶名稱及密碼來做上網時身分驗證的證件，而另外一個公司則是要以X.509數位憑證來做上網時的證件。雖然這兩家公司所使用的身分驗證技術不同，但是可以把它們提升到同一個層次，因為都是要做身分驗證的工作。

這種組合的基本機制，不但可以在SOAP的信息中，包含現存的各種安全技術，對於將來新發展出來的Web服務安全技術也能適用，進而打造出更為安全的Web服務基本建設架構。這些基本機制的功能不外乎是要提供SOAP信息的完整性、私密性和單一信息的身分驗證等工作。

WSS信息使用用戶名稱及密碼安全令牌和的實例，在框中是身分驗證相關的編碼


＜?xml version="1.0" encoding="utf-8" ?＞ 
＜soap:Envelope 
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema"＞
 ＜soap:Header＞
  ＜wsse:Security soap:mustUnderstand="1" 
    xmlns:wsse="http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"＞
  ＜wsse:UsernameToken＞
    ＜wsse:Username＞SteveTsai＜/wsse:Username＞ 
    ＜wsse:Password 
       Type="wsse:PasswordText"＞securance＜/wsse:Password＞  
  ＜/wsse:UsernameToken＞
  ＜/wsse:Security＞
 ＜/soap:Header＞
 ＜soap:Body＞
  ＜Ping xmlns="http://xmlsoap.org/Ping"＞
   ＜text＞NetSecurance＜/text＞ 
  ＜/Ping＞
 ＜/soap:Body＞
＜/soap:Envelope＞?

信息的私密性係利用現有W3C的XML資料加密標準，再加上安全令牌來確保信息在傳輸的過程之中，沒有被洩露出去。這種資料加密的機制可以支援多種加密處理過程，並且可由多點來執行處理工作。

相對地，信息的完整性係利用現有W3C的數位簽章標準，並且也加上了安全令牌，以確保信息在傳輸之中，沒有被人竄改。這種數位簽章的機制可以支援一個信息的多層數位簽章，也支援在多點上進行簽字的工作。

加密又簽字的WSS信息實例，在框中分別是SOAP信息的Body部分之數位簽章和資料加密相關編碼


＜?xml version="1.0" encoding="utf-8" ?＞
＜soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema"＞
 ＜soap:Header＞ 
  ＜wsse:Security soap:mustUnderstand="1" 
   xmlns:wsse="http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"＞
   ＜xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"＞
    ＜xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" /＞
    ＜KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"＞
     ＜wsse:SecurityTokenReference＞
      ＜wsse:KeyIdentifier ValueType="wsse:X509v3"＞B39R...mY=＜/wsse:KeyIdentifier＞
     ＜/wsse:SecurityTokenReference＞
    ＜/KeyInfo＞
    ＜xenc:CipherData＞
     ＜xenc:CipherValue＞dNYS...fQ=＜/xenc:CipherValue＞
    ＜/xenc:CipherData＞
    ＜xenc:ReferenceList＞
     ＜xenc:DataReference URI="#enc" /＞
    ＜/xenc:ReferenceList＞
   ＜/xenc:EncryptedKey＞
   ＜wsse:BinarySecurityToken ValueType="wsse:X509v3" 
    EncodingType="wsse:Base64Binary" 
    xmlns:wsu="http://schemas.xmlsoap.org/ws/2003/06/utility"
    wsu:Id="myCert"＞MII...hk＜/wsse:BinarySecurityToken＞
   ＜Signature xmlns="http://www.w3.org/2000/09/xmldsig#"＞
    ＜SignedInfo＞
     ＜CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /＞
     ＜SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/＞
     ＜Reference URI="#body"＞
      ＜Transforms＞
       ＜Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/＞
      ＜/Transforms＞
      ＜DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/＞
      ＜DigestValue＞QTV...dw=＜/DigestValue＞
     ＜/Reference＞
    ＜/SignedInfo＞
    ＜SignatureValue＞H+x0...gUw=＜/SignatureValue＞
    ＜KeyInfo＞
     ＜wsse:SecurityTokenReference＞
      ＜wsse:Reference URI="#myCert" /＞
     ＜/wsse:SecurityTokenReference＞
    ＜/KeyInfo＞
   ＜/Signature＞
  ＜/wsse:Security＞
 ＜/soap:Header＞
 ＜soap:Body wsu:Id="body" xmlns:wsu="http://schemas.xmlsoap.org/ws/2003/06/utility"＞
  ＜xenc:EncryptedData wsu:Id="enc" Type="http://www.w3.org/2001/04/xmlenc#Content"
   xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"＞
   ＜xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" /＞
   ＜xenc:CipherData＞
    ＜xenc:CipherValue＞AYb...Y8=＜/xenc:CipherValue＞
   ＜/xenc:CipherData＞
  ＜/xenc:EncryptedData＞
 ＜/soap:Body＞
＜/soap:Envelope＞

在身分驗證方面，WSS提供了多種身分驗證的機制，從簡單的用戶名稱的安全令牌、X.509數位憑證、Kerberos、提供單一簽入認證與授權的SAML（Security Assertion Markup Language），一直到用生物辨識（Biometric）技術，都有不同的附帶標準在研議之中。除前兩項馬上成為正式的標準外，其他各項附帶的安全認證規範都將會陸續地審議完成，並正式推出成為標準。

WSS並非刀槍不入

雖然，主管Web服務安全的WSS正式推出成為標準，但是這並不代表Web服務的安全就有了萬靈丹，可以從此就高枕無憂、刀槍不入了。因為WSS只是一個安全的標準，而不是安全的解決方案。

在WSS的規範之中就明白地指出，單獨的WSS並無法確保Web服務的安全，它也無法獨力來提供一個完全的安全解決方案。WSS只是打造整個解決方案時候的一個建築元件，必須要結合其他在Web服務之中和應用程式專屬的通訊協定，以便提供多種不同的安全模式與資料加密的技術。

結語

事實上，在IBM和微軟等廠商聯手推出WS – Security標準後不久，他們又公佈了整個WS – Security的藍圖，並用WS – Security做基礎，發展出和安全相關的各項標準。只是這些標準目前大都還在各別廠商相互討論和試驗階段，IBM和微軟等大廠並無意將這些標準送到像是OASIS或是W3C之類的標準組織中去研議。

實現WS – Security並不代表Web服務應用不會被駭客入侵，也不代表網路安全不會被破解。WS – Security是打造安全的Web服務時之重要一員，但是其它各種網路安全的機制還是不可或缺。

＜作者為本刊的資深專欄作家，目前在美國矽谷高科技公司任職，是OASIS之Web服務安全技術委員會（WSS-TC）的委員之一；作者網站：http://home.earthlink.net/~symonchang/webservices.htm＞