從基于傳送的安全轉(zhuǎn)移到基于信息的安全

　　當(dāng)我給出關(guān)于Web服務(wù)的介紹的時候，不可避免的就會有來自于聽眾的關(guān)于安全的問題。最常見的問題是:“你是如何保障Web服務(wù)的安全的”。通常會跟隨著懷疑的論斷:“Web服務(wù)不可能是安全的”。

　　但是，記住，今天的Web服務(wù)的主體是基于同樣的再Web之下的授權(quán)的技術(shù)，我們稱之為HTTP。從而，所有的常見的確保Web安全的應(yīng)用程序——基本的認(rèn)證和SSL是最常見的——同Web服務(wù)一起工作的很好。這些安全技術(shù)多年來對各種的在線商務(wù)事務(wù)處理發(fā)揮了巨大的作用。

　　盡管如此，但是組織所具有的關(guān)于基于Web的安全策略的主要問題是通常的解決方法例如SSL有一點稍顯笨拙，因為他們通常確保了整個線路傳輸?shù)膮f(xié)議的安全，而不是只針對在協(xié)議之上傳輸?shù)腟OAP消息的。此外，對許多基于信號的集成項目，在信息到達(dá)他們的目標(biāo)終點之前，一些中間步驟是必須的，同時傳送級別的安全策略讓這些信息在各個中間檢查點并不安全。

　　為了獲得更好的控制級別和防止中間的安全問題，各種組織所作的基于SOAP的信息集成通常想要的都是在信息層確保安全而不是在傳輸層。這所意味的是信號自身確保它的安全，而不依賴于傳送。當(dāng)安全只限于信息的時候一些事情變得很顯然。首先，通常為大多數(shù)Web 服務(wù)所提供的SSL能力會被我稱之為信號安全的東西替代，而信號安全也將成為為所有的客戶和服務(wù)方交互安全的信號的必須。第二，安全信息將會被信號自己攜帶。第三，除非中間或者最終節(jié)點擁有正確的安全基礎(chǔ)構(gòu)造同時是可信任的，否則信號會仍然保持安全并不可讀取，然后被往前轉(zhuǎn)遞到下一個節(jié)點。

Web 服務(wù)安全:WS-Security規(guī)范

　　你如何確保信號的安全，而不是傳輸?shù)陌踩?答案在于OASIS標(biāo)準(zhǔn).WS-Security，作為一個所有工業(yè)認(rèn)可的推薦在2004年4月發(fā)布。WS-Security所定義的是一個把三層安全策略加到SOAP信號中去的機制。

　　認(rèn)證標(biāo)志:WS-Security認(rèn)證標(biāo)志使得客戶可以以一種標(biāo)準(zhǔn)的方式發(fā)送包含在SOAP消息頭中的用戶名和密碼或用于認(rèn)證目的的X.509認(rèn)證。盡管SAML和Kerberos標(biāo)志普遍使用，但是關(guān)于這些標(biāo)志的WS-Security規(guī)范也還沒有發(fā)布。

　　XML加密:WS-Security被使用在W3C的 XML加密標(biāo)準(zhǔn)，從而使得SOAP信號體和它的組成部分被加密以確保機密性。通常的，不同的加密算法都被支持——在Oracle Application Server 10g Release 10.1.3中，被支持的算法是3DES, AES-128和AES-256。

　　XML數(shù)字簽名:WS-Security被使用在W3C's XML數(shù)字簽名標(biāo)準(zhǔn)中，從而使得SOAP消息可以被數(shù)字簽名確保消息的整體性。通常的，簽名時一個有消息本身的內(nèi)容計算產(chǎn)生的。如果消息在發(fā)送途中被更改，數(shù)字簽名就不可用了。Oracle Application Server支持DSA-SHA1, HMAC-SHA1, RSA-SHA1, 和 RSA-MD5算法。

　配置Web服務(wù)的服務(wù)端

　　通常的當(dāng)開發(fā)者看到WS-Security的三個組件，一些關(guān)于他們是如何在特定的應(yīng)用程序中協(xié)調(diào)處理認(rèn)證，加密，和數(shù)字簽名的步驟的疑問也就產(chǎn)生了。

　　幸運的是，絕大多數(shù)供應(yīng)商例如Oracle正在實現(xiàn)WS-Security為一個發(fā)布的機制，從而可以把這個機制應(yīng)用于新的和現(xiàn)有的Web服務(wù)。　例如在Oracle JDeveloper 10g Release 10.1.3中，你只需要簡單的再Web服務(wù)節(jié)點上點擊，選擇安全Web服務(wù)，然后跟隨走完一個簡單的向?qū)АD一是Oracle JDeveloper.中的一個WS-Security的基本工具的運行時候的外觀的一個屏幕截圖。

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

　　為了提供一個簡單的在運轉(zhuǎn)的WS-Security的用況，我用圖一中所提供的認(rèn)證的屬性——用戶名，密碼認(rèn)證標(biāo)志——并使用getEmpSalary方法把他們應(yīng)用到HRService　Web服務(wù)。

　　注意到WS-Security運行時能力被元素使能。服務(wù)端對用戶名和密碼口令認(rèn)證的需要被元素定義。

　　一旦這些配置被布置在一個一般的Web服務(wù)Ear文件。在Oracle應(yīng)用程序服務(wù)器端運行時的管理配置文件wsmgmt .xml會被這個信息更新。我在上個月的Web服務(wù)管理專欄中用圖表的方式解釋了這個過程。在布置以后，這個Web服務(wù)也就可以用WS-Security的用戶名密碼標(biāo)志來測試了。

配置Web服務(wù)客戶端

　　下一步是決定如何從來自于Web服務(wù)客戶端獲得用戶名和密碼的WS-Security標(biāo)志放入SOAP信息中。通常的Web服務(wù)工具包提供一個API或者發(fā)布的機制去完成這個功能。

　　圖二 基于信號層安全的Web服務(wù)安全

　　為了配置這個信息，Oracle JDeveloper在Web服務(wù)的客戶端提供了一個如圖一所示的向?qū)У溺R像。這兩個向?qū)У闹饕獏^(qū)別是在于客戶端的向?qū)峁┝双@取用戶姓名和密碼口令的能力，而服務(wù)器端的向?qū)t沒有提供。列表二提供了所產(chǎn)生的客戶端配置。這只是可選的，因為很多開發(fā)者并不愿意把這些信息嵌入到配置文件中去(雖然這對測試是非常有用的)。Oracle應(yīng)用服務(wù)器提供了一種簡單的客戶API，用以設(shè)置客戶的Web服務(wù)的用戶名和密碼口令標(biāo)志。

　　當(dāng)我運行生成的客戶端，列表三種的信息就生成了，除去雇員的薪金請求，這些信號包含了信號頭中包含的用戶名和密碼口令標(biāo)志，還包含了支持了領(lǐng)先于標(biāo)準(zhǔn)的WS-Security wsse命名空間的標(biāo)準(zhǔn)模式的WS-Security參考。

結(jié)論

　　同很多其他的稱之為WS—*的標(biāo)準(zhǔn)，通常都有關(guān)于WS-Security在異構(gòu)環(huán)境下工作的協(xié)調(diào)性的擔(dān)憂。在我的例子當(dāng)中，我選擇了最簡單的可能性的情況，但是在具有更復(fù)雜的認(rèn)證標(biāo)志，加密和數(shù)字簽名的實際文件中，協(xié)調(diào)性立刻變得極為重要。

　　業(yè)界是非常清楚這個問題的，同時中立公司論壇例如Web服務(wù)協(xié)調(diào)性組織(WS-I)已經(jīng)開始工作，該組織由主要的廠商參與，其中包括Oracle，從而確保Oracle, IBM, Microsoft, Sun, 和BEA 所實現(xiàn)的WS-Security實現(xiàn)可以共同操作的。

　　這些努力能夠帶來一個名叫Basic Security Profile的如何使用WS-Security的輪廓或者說是一個推薦的最好實踐。它將會補充其他的由WS-I發(fā)布的關(guān)鍵的協(xié)調(diào)性藍(lán)本，Basic Profile 1.1。Basic Profile 1.1關(guān)注于SOAP, UDDI, 和 WSDL的最佳實踐。

保障Web服務(wù)的安全