從基于傳送的安全轉移到基于信息的安全
當我給出關于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服務
在我點擊了安全向導上的OK之后，列表一中的Oracle-specific 描述符文件就產生了(用最小的命名空間表示)。注意到WS-Security運行時能力被元素使能。服務端對用戶名和密碼口令認證的需要被元素定義。
代碼列表一：oracle-webservices.xml.中的WS-Security服務器配置
<oracle-webservices> |
一旦這些配置被布置在一個一般的Web服務Ear文件。在Oracle應用程序服務器端運行時的管理配置文件wsmgmt .xml會被這個信息更新。我在上個月的Web服務管理專欄中用圖表的方式解釋了這個過程。在布置以后，這個Web服務也就可以用WS-Security的用戶名密碼標志來測試了。
配置Web服務客戶端
下一步是決定如何從來自于Web服務客戶端獲得用戶名和密碼的WS-Security標志放入SOAP信息中。通常的Web服務工具包提供一個API或者發布的機制去完成這個功能。
圖二 基于信號層安全的Web服務安全
由于Oracle應用服務器所提供的WS-Security實現的對外公布的特點，在服務器一端存在一個定義了WS-Security屬性的配置文件，在客戶一端要求存在一個該配置文件的鏡像，我們要意識到這一點是很重要的。從而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的最佳實踐。
(責任編輯：銘銘)
