向Web開放內部服務 SOA飾演勇敢者游戲

申請免費試用、咨詢電話：400-8352-114

Web服務通常被視為組織間共享數據的途徑：企業(yè)可以有選擇地向客戶、合作伙伴以及供應商開放內部系統，從而將原來需要人工處理的交易自動化。雖然迄今為止多數企業(yè)依然盡力避免走這條路，而將Web服務置于防火墻的保護之下，但是隨著服務導向架構(SOA)的發(fā)展和Web 2.0的出現，這一切都有可能改變。

向Web開放內部服務是否過于冒險?雖然SOA安全標準不成熟加劇了互操作性的負面影響，但這并不能成為決策依據。欲對有多個企業(yè)參與的大型Web服務網絡進行配置，以確保其安全，所有參與者必須就所采用的技術和安全策略達成共識。否則，就會出現不合理的局面：一方面，你要求自身的雇員使用生物測定技術或者身份標志來驗明正身，另一方面，合作伙伴的員工只需要通過弱口令認證就可以訪問你公司的系統，這樣的安全防護，毫無意義。

在采購任何SOA安全部件之前，需要先對SOA安全進行深入研究，因為市場始終在變。無論如何，眼下如火如荼的SOA運動對IT部門而言，終究是好事，因為這樣一來他們手中會有更多的選擇，需要打交道的廠商也少了。與此同時，采購決策的過程也變得更為簡單。

例如, 將Web服務暴露于互聯網，需要基于可擴展標記語言(XML)的防火墻，也稱為SOA安全網關。然而，隨著SOA技術的不斷整合，這一產品類型已開始銷聲匿跡。

現在，從管理平臺到核心交換機在內的所有產品都添加了XML防火墻功能。選用何種產品、到底是用硬件還是用軟件，取決于每個企業(yè)Web服務的規(guī)模、預期增長、以及現有的SOA基礎設施等因素。此外，虛擬化技術還進一步加大了系統選擇的難度。

加密和認證的決策更為艱難。因為那并非只取決于某一個組織，而是接觸Web服務的所有組織都必須使用同樣的技術。然而，現在這一領域存在著好幾個相互競爭的標準，加深了問題的復雜性。

這些標準之間最大的沖突在于身份管理。這個復雜過程的目的是確保登錄用戶已被授權使用該公司合作伙伴的系統。目前有兩個互不兼容但功能相近的標準。一個是安全性斷言標記語言 (SAML)，這一標準已經得到幾乎所有公司的支持，唯一的例外是微軟公司(Microsoft，下稱微軟);微軟更喜歡較新的WS-Federation標準。后者與其他Web服務標準的關系也更為密切。雖然二者都用XML，但是彼此并不兼容，因此那些推行公共Web服務的企業(yè)要么同時支持這兩種標準，要么需要確認其所有采用安全Web服務的商業(yè)合作伙伴選擇的是同一個標準。

看來，得有未卜先知的本事，才能在兩者間做出合理的決策。

各種相關信息

所有Web服務安全技術均建立在XML加密(XML Encryption)和XML簽名(XML Signature)的基礎之上，W3C標準用于在XML文檔和信息內嵌的加密數據和數字簽名。由于XML加密技術無需對全部信息進行加密，因此IT部門可自由選擇：可對信用卡號碼等個人數據進行加密，而敏感度不高的信息和SOA元數據無需加密即可傳送。也可給文檔的不同部分分配不同的密鑰，以使其只能被指定的接收者讀取。

但這也有不利的一面：由于參與者必須首先就加密數據的位置、加密元素和如何交換密鑰等問題達成一致，因此散布于XML信息中的加密數據會導致互操作問題。為解決上述問題，結構信息標準化促進組織 (OASIS)建立了WS-Security標準，以在Web服務中應用XML安全(XML Security)和XML加密。

WS-Security標準是WS-*系列標準中最成熟的一個，幾乎所有Web服務和SOA廠商都支持這一標準。其主要缺點是：與所有的WS-*系列標準一樣，也采用簡單對象訪問協議(SOAP)，因此凡業(yè)務依賴于REST Web服務的公司，都不適用此標準。 REST(Representational State Transfer)意為具象狀態(tài)傳輸，采用這種模式，可對不用SOAP的XML Web服務進行描述。

選擇REST而非SOAP的主要原因在于它的簡捷，多數REST用戶仍然使用SSL協議。這是由于REST采用HTTP協議，而且往往被用于點對點連接，故而SSL隧道通常已能滿足其需求。在應用了REST以后，企業(yè)如果希望對消息層進行加密，就需要建立其自己的協議和數據格式。

對于多數企業(yè)而言，將所有商業(yè)合作伙伴組織起來，并為REST設計定制的、安全的XML格式，實屬不易，WS-Security標準因此而成為采用SOAP的最強有力依據。盡管如此，亞馬遜公司(Amazon.com)和谷歌公司(Google)等大型Web服務提供商紛紛各顯神通，使用安全身份標識(Security Token)，成功地應用了REST模式。這樣做雖然有淪為專有技術的顧慮，但仍然受到了用戶的歡迎：亞馬遜也提供遵從WS-Security的SOAP接口，但發(fā)現客戶更青睞REST，使用二者的用戶比例為5:1，因為多數亞馬遜用戶僅僅是訪問亞馬遜服務，而不是用之建立完整的SOA，所以也就用不著SOAP的復雜功能。

統一身份

盡管WS-Security標準有助于SOAP信息的加密和簽名，但該標準并未涉及任何有關認證、授權和計費(AAA)或者安全策略的內容。這些問題由安全領域的其他標準解決，并且所有這些標準都以WS-Security為基礎。

雖然目前這些標準由于太新而無法對用戶產生足夠的影響，但是其中多數最終將得到企業(yè)服務總線(ESB)和Web服務管理領域所有廠商的支持。

唯一的例外是統一身份的問題，也恰是在這一領域，安全標準新秀WS-Federation和WS-Trust對OASIS組織發(fā)布的另一成熟標準SAML 2.0發(fā)起了挑戰(zhàn)。采用統一身份的目的在于：將認證與被訪問的資源分隔開來，以實現單點登錄。用戶登錄到某身份提供者的系統，后者為之提供憑證，該用戶即可使用此憑證訪問多個不同資源。憑證與數字證書近似，在SAML中稱之為“斷言”，在WS-Trust中喚作“標識”;一般用憑證來擔保用戶身份，并在認證時添加一些信息，例如用戶在何時以什么方式登錄。SAML作用于整個單點登錄過程，而對于WS-*來說，這一過程由兩個標準共同完成：WS-Trust負責處理內部認證和標識的發(fā)放，WS-Federation負責管理用這些標識訪問其他資源的操作。

實際上，二者的主要差別在于：SAML直接使用XML加密和XML簽名，這意味著它與REST兼容;而WS-Federation則采用SOAP。SAML擁有龐大的客戶群，但是這實際上意義不大，因為微軟一直在全力推進WS-Federation，并表示不會支持SAML。