保障Web服務的安全

從基于傳送的安全轉移到基于資訊的安全

　　當我給出關于Web服務的介紹的時候，不可避免的就會有來自于聽衆的關于安全的問題。最常見的問題是:“你是如何保障Web服務的安全的”。通常會跟随着懷疑的論斷:“Web服務不可能是安全的”。

　　但是，記住，今天的Web服務的主體是基于同樣的再Web之下的授權的技術，我們稱之為HTTP。進而，所有的常見的確定Web安全的應用程式——基本的認證和SSL是最常見的——同Web服務一起工作的很好。這些安全技術多年來對各種的線上商務事務處理發揮了巨大的作用。

　　盡管如此，但是組織所具有的關于基于Web的安全政策的主要問題是通常的解決方法例如SSL有一點稍顯笨拙，因為他們通常確定了整個線路傳輸的協定的安全，而不是隻針對在協定之上傳輸的SOAP消息的。此外，對許多基于信号的內建項目，在資訊到達他們的目标終點之前，一些中間步驟是必須的，同時傳送級别的安全政策讓這些資訊在各個中間檢查點并不安全。

　　為了獲得更好的控制級别和防止中間的安全問題，各種組織所作的基于SOAP的資訊內建通常想要的都是在資訊層確定安全而不是在傳輸層。這所意味的是信号自身確定它的安全，而不依賴于傳送。當安全隻限于資訊的時候一些事情變得很顯然。首先，通常為大多數Web 服務所提供的SSL能力會被我稱之為信号安全的東西替代，而信号安全也将成為為所有的客戶和服務方互動安全的信号的必須。第二，安全資訊将會被信号自己攜帶。第三，除非中間或者最終節點擁有正确的安全基礎構造同時是可信任的，否則信号會仍然保持安全并不可讀取，然後被往前轉遞到下一個節點。

　　Web 服務安全:WS-Security規範

　　你如何確定信号的安全，而不是傳輸的安全?答案在于OASIS标準.WS-Security，作為一個所有工業認可的推薦在2004年4月釋出。WS-Security所定義的是一個把三層安全政策加到SOAP信号中去的機制。

　　認證标志:WS-Security認證标志使得客戶可以以一種标準的方式發送包含在SOAP消息頭中的使用者名和密碼或用于認證目的的X.509認證。盡管SAML和Kerberos标志普遍使用，但是關于這些标志的WS-Security規範也還沒有釋出。

　　XML加密:WS-Security被使用在W3C的 XML加密标準，進而使得SOAP信号體和它的組成部分被加密以確定機密性。通常的，不同的加密算法都被支援——在Oracle Application Server 10g Release 10.1.3中，被支援的算法是3DES, AES-128和AES-256。

　　XML數字簽名:WS-Security被使用在W3C's XML數字簽名标準中，進而使得SOAP消息可以被數字簽名確定消息的整體性。通常的，簽名時一個有消息本身的内容計算産生的。如果消息在發送途中被更改，數字簽名就不可用了。Oracle Application Server支援DSA-SHA1, HMAC-SHA1, RSA-SHA1, 和 RSA-MD5算法。

　　配置Web服務的服務端

　　通常的當開發者看到WS-Security的三個元件，一些關于他們是如何在特定的應用程式中協調處理認證，加密，和數字簽名的步驟的疑問也就産生了。

　　幸運的是，絕大多數供應商例如Oracle正在實作WS-Security為一個釋出的機制，進而可以把這個機制應用于新的和現有的Web服務。　例如在Oracle JDeveloper 10g Release 10.1.3中，你隻需要簡單的再Web服務節點上點選，選擇安全Web服務，然後跟随走完一個簡單的向導。圖一是Oracle JDeveloper.中的一個WS-Security的基本工具的運作時候的外觀的一個螢幕截圖。

　　圖一　用Oracle JDeveloper 10g Release 10.1.3保護Web服務的安全

　　為了提供一個簡單的在運轉的WS-Security的用況，我用圖一中所提供的認證的屬性——使用者名，密碼認證标志——并使用getEmpSalary方法把他們應用到HRService　Web服務。

　　注意到WS-Security運作時能力被元素使能。服務端對使用者名和密碼密碼認證的需要被元素定義。

　　一旦這些配置被布置在一個一般的Web服務Ear檔案。在Oracle應用程式伺服器端運作時的管理配置檔案wsmgmt .xml會被這個資訊更新。我在上個月的Web服務管理專欄中用圖表的方式解釋了這個過程。在布置以後，這個Web服務也就可以用WS-Security的使用者名密碼标志來測試了。

　　配置Web服務用戶端

　　下一步是決定如何從來自于Web服務用戶端獲得使用者名和密碼的WS-Security标志放入SOAP資訊中。通常的Web服務工具包提供一個API或者釋出的機制去完成這個功能。

　　圖二 基于信号層安全的Web服務安全

　　為了配置這個資訊，Oracle JDeveloper在Web服務的用戶端提供了一個如圖一所示的向導的鏡像。這兩個向導的主要差別是在于用戶端的向導提供了擷取使用者姓名和密碼密碼的能力，而伺服器端的向導則沒有提供。清單二提供了所産生的用戶端配置。這隻是可選的，因為很多開發者并不願意把這些資訊嵌入到配置檔案中去(雖然這對測試是非常有用的)。Oracle應用伺服器提供了一種簡單的客戶API，用以設定客戶的Web服務的使用者名和密碼密碼标志。

　　當我運作生成的用戶端，清單三種的資訊就生成了，除去雇員的薪金請求，這些信号包含了信号頭中包含的使用者名和密碼密碼标志，還包含了支援了領先于标準的WS-Security wsse命名空間的标準模式的WS-Security參考。

　　結論

　　同很多其他的稱之為WS—*的标準，通常都有關于WS-Security在異構環境下工作的協調性的擔憂。在我的例子當中，我選擇了最簡單的可能性的情況，但是在具有更複雜的認證标志，加密和數字簽名的實際檔案中，協調性立刻變得極為重要。

　　業界是非常清楚這個問題的，同時中立公司論壇例如Web服務協調性組織(WS-I)已經開始工作，該組織由主要的廠商參與，其中包括Oracle，進而確定Oracle, IBM, Microsoft, Sun, 和BEA 所實作的WS-Security實作可以共同操作的。

　　這些努力能夠帶來一個名叫Basic Security Profile的如何使用WS-Security的輪廓或者說是一個推薦的最好實踐。它将會補充其他的由WS-I釋出的關鍵的協調性藍本，Basic Profile 1.1。Basic Profile 1.1關注于SOAP, UDDI, 和 WSDL的最佳實踐。

本文轉自 牛海彬 51CTO部落格，原文連結：http://blog.51cto.com/newhappy/77268，如需轉載請自行聯系原作者