訊息的調解者XML Security Gateway

XML Security Gateway能在服務請求端與提供端之間扮演訊息互通的中介橋樑。

鬆散耦合(loosely coupled)世界當中的安全挑戰之一，便是我們必須在服務請求端和服務提供端之間的對談中，拿捏於何處以及該如何去提供身分驗證、授權和稽核這三種服務。也因此，XML security gateway問世之後，就被當成是服務與安全政策間，互通訊息的中介橋樑。再者，它也允許企業透過訊
息層級(message-level)的安全方式，像是WSSecurity與SAML等開放標準，去代表XML訊息當中的安全權杖(token)（見下圖）。所以，我們能了解，XML security gateway可以在SOA 的架構之下，傳遞部份有用的安全服務：

認證／授權 (Authentication/Authorization)
身分認證和授權服務請求和回應，會採用開放標準，像是WS-Security和SAML等。不過，有趣的是，許多的SOA標準卻允許該架構，可以為不同的token參照不同的namespace，比方說，一個token可以作為訊息繞送(message routing)用，而另一個拿來當成資料存取的目的。那麼，這實際上所代表的意義，會是一個保護用戶資料的token來自於日本東京，而另一個保護routing資訊的token，則可能位於美國達拉斯。

稽核(Audit)
提供一個方便的站點，為企業所保護的服務，去佈署稽核登錄的安全服務。
輸入驗證(Input Validation) 這些安全服務仍具有遭到注入式攻擊－像是SQL或者是LDAP注入的弱點。此外，安全服務也必須要去處理SOA架構上的攻擊行為，比方像是針對XML parser。再者，XML security gateway還會提供一個管道，以執行所設定之白名單 ／黑名單的輸入驗證法則。

XML阻斷服務保護 (XML Denial of Service Protection)
針對使用XML服務，目前可透過幾種已知的方式執行阻斷服務攻擊。手法包含送出遞迴元素（一遍又一遍的重覆建立相同的物件）和jumbo payloads
（在鬆散耦合的世界裡，沒有任何東西可以阻擋的了攻擊者發送1GB大小的檔案給服務系統）。

安全性token和身分對應 (Security token and identity mapping)
因為SOA可以跨越多種技術，所以一項單一的請求是可以很輕易的在大型主機、Java伺服主機和Windows機器上傳來傳去。傳統作法上，這些具身分特性的token必須要跟本地端作一個格式對應，所以，大型主機很可能會要求用戶名稱和密碼，而Java系統則可能使用LDAP，另外，Windows系統也許
是使用Kerberos協定。結論是，XML security gateways 會為token的驗證提供一個強迫站點，並透過token 對應作訊息的轉換。
事實上，許多的服務都可以被佈署在XML security gateway之中，而每樣工具都有自身的強項和弱點存在。因此，OWASP XML Security Gateway
Evaluation Criteria Project便提出一個開放標準，讓各界為XML security gateway解決方案提供一個通透、 且具等級評判的準則，以訂定出自身解決方案的關
鍵價值主張。