軟件測試之面向服務架構：勇敢者的游戲

關鍵字：架構 勇敢者 游戲

　　向業務合作伙伴開放公司的服務導向架構(SOA)，是否值得冒險一試?

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

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

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

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

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

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

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

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

　　各種相關信息

　　所有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)，因此凡業務依賴于REST Web服務的公司，都不適用此標準。 REST(Representational State Transfer)意為具象狀態傳輸，采用這種模式，可對不用SOAP的XML Web服務進行描述。

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

原文轉自：http://www.anti-gravitydesign.com