對于多數企業而言，將所有商業合作伙伴組織起來，并為REST設計定制的、安全的XML格式，實屬不易，WS-Security標準因此而成為采用SOAP的最強有力依據。盡管如此，亞馬遜公司(Amazon.com)和谷歌公司(Google)等大型Web服務提供商紛紛各顯神通，使用安全身份標識(Security Token)，成功地應用了REST模式。這樣做雖然有淪為專有技術的顧慮，但仍然受到了用戶的歡迎：亞馬遜也提供遵從WS-Security的SOAP 接口，但發現客戶更青睞REST，使用二者的用戶比例為5:1，因為多數亞馬遜用戶僅僅是訪問亞馬遜服務，而不是用之建立完整的SOA，所以也就用不著 SOAP的復雜功能。
統一身份
盡管WS-Security標準有助于SOAP信息的加密和簽名，但該標準并未涉及任何有關認證、授權和計費(AAA)或者安全策略的內容。這些問題由安全領域的其他標準解決，并且所有這些標準都以WS-Security為基礎。
雖然目前這些標準由于太新而無法對用戶產生足夠的影響，但是其中多數最終將得到企業服務總線(ESB)和Web服務管理領域所有廠商的支持。
唯一的例外是統一身份的問題，也恰是在這一領域，安全標準新秀WS-Federation和WS-Trust對OASIS組織發布的另一成熟標準 SAML 2.0發起了挑戰。采用統一身份的目的在于：將認證與被訪問的資源分隔開來，以實現單點登錄。用戶登錄到某身份提供者的系統，后者為之提供憑證，該用戶即可使用此憑證訪問多個不同資源。憑證與數字證書近似，在SAML中稱之為“斷言”，在WS-Trust中喚作“標識”; 一般用憑證來擔保用戶身份，并在認證時添加一些信息，例如用戶在何時以什么方式登錄。SAML作用于整個單點登錄過程，而對于WS-*來說，這一過程由兩個標準共同完成：WS-Trust 負責處理內部認證和標識的發放，WS-Federation負責管理用這些標識訪問其他資源的操作。
實際上，二者的主要差別在于：SAML直接使用XML加密和XML簽名，這意味著它與REST兼容; 而WS-Federation則采用SOAP。SAML擁有龐大的客戶群，但是這實際上意義不大，因為微軟一直在全力推進WS-Federation，并表示不會支持SAML。
與其他的標準之爭不同，在這一案例中，并非是微軟與其他所有公司的簡單對抗。
一方面，微軟與國際商業機器公司(IBM)共同開發了WS-Federation標準，而后者同時也是SAML的擁躉; 另一方面，SAML陣營中其他所有廠商均已承諾，如果WS-Federation存在市場需求，他們都會支持這一標準。從長遠來看，二者將會并存：微軟和SOAP環境會選擇WS- Federation，而REST Web服務則是SAML的天下。
防火墻置于何處
在互聯網的發展過程中，防火墻是最早推動Web服務普及的因素。雖然不同的組織采取不同的安全策略，但是幾乎所有組織都需要開放80端口(編者注：Web服務端口)，所以廠商和標準組織紛紛傾向于采用運行在HTTP之上、基于文本的協議。
當然，攻擊者和惡意軟件也持同樣的態度。
因此，在互聯網上發布Web服務的公司傳統上往往使用應用安全網關，這些設備可以讀取并理解應用層文檔，從而能過濾潛在的攻擊。雖然好產品的功能不僅限于XML領域，通常仍稱這類設備為“XML防火墻”。盡管基于瀏覽器的富互聯網應用(RIA)開發人員往往認為XML過于龐雜，而喜歡用 JavaScript 對象表示法(JSON)或純文本格式，但REST Web服務仍可在HTTP或URL中對某些信息進行編碼。
安全網關不僅僅是防火墻，它具備SOA管理套件的所有功能，可以處理認證、授權和計費。當Web服務作為企業SOA的一個接口存在時，安全網關通常需要在Java信息服務(JMS)和HTTP之間進行轉換，原因在于多數SOA在其內部并不使用真正的Web服務。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
