保障Web服務的安全

餘二五發表於2017-11-14
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，如需轉載請自行聯絡原作者


相關文章