WS-Trust，WS-Fed和SAML 1.1 / 2.0協議之間的區別

Question

WS-Trust，WS-Fed和SAML 1.1 / 2.0協議之間有什么區別？

當SAML用作WS-Trust和WS-Fed協議中的安全性令牌時，我對這些協議的理解感到困惑。

有興趣了解這些協議在哪種情況下使用以及使它們與眾不同的原因。 如果未使用任何商業產品/技術參考，您的答案將很容易理解。

Answer 1

在較高級別，Microsoft傳統上使用WS- *協議。

SAML-P（用於協議的P）被開源運動以及Java所采用。

WS-Fed具有兩個配置文件-主動和被動。 主動式用於WCF（WS-Trust），被動式用於基於瀏覽器（WS-Fed通過登錄頁面）。

這兩個都使用SAML令牌。

在功能上，WS-Fed和SAML都做同樣的事情。 聯邦

如果將兩個ADFS（Microsoft IDP）聯合在一起，則使用WS-Fed。 如果您添加Sharepoint，它也會使用WS-Fed。 傳遞的令牌為SAML令牌格式。

如果您有使用Spring的Java應用程序，那么它將通過SAML-P掛接到ADFS。 傳遞的令牌為SAML令牌格式。

Answer 2

這個問題很舊，但是我很難在網上找到正確的答案。

許多在線帖子說，“被動/瀏覽器”客戶端使用WS-Fed，“主動/智能”客戶端使用WS-Trust。 這可能是因為活動用例默認情況下使用的網址為“ / ws-trust / 2005”或“ /ws-trust/v1.x/”。 這似乎不是100％准確的。 偉大而免費的書：《基於聲明的身份》，第二版幫助我解決了這一問題，終於找到了令人滿意的答案：

這些體系結構中的許多體系結構的目標是啟用與瀏覽器或智能客戶端的聯合。 與智能客戶端的聯合基於WS-Trust和WS-Federation Active Requestor Profile。

這些協議描述了智能客戶端（例如，基於Windows的應用程序）和服務（例如，WCF服務）之間的通信流程，以向發行者請求令牌，然后將該令牌傳遞給服務以進行授權。

與瀏覽器的聯合基於WS-Federation被動請求者概要文件，該概要描述了瀏覽器和Web應用程序之間的相同通信流。 它依靠瀏覽器重定向，HTTP GET和POST來請求和傳遞令牌。

SAMLP只是一種不同的協議，涉及諸如重定向URL之類的事物通信方式，但是差異並不相關（在大多數情況下），而僅取決於客戶端支持的內容（例如Java將使用SAML）。 在我看來，最大的不同是SAMLP允許身份提供商啟動用例（我認為這是最安全的用例），其中用戶從身份提供商（例如，ADFS服務器的Web代理，即= Claims Provider）中啟動。 MS條款），而不是從Web服務開始，然后重定向到服務提供者（= MS條款中的中繼方）。 同樣，當我們談論SAML時，我們通常指的是SAML 2.0，而WS-Fed使用SAML 1.x令牌（MS稱它們為Token，SAML稱它們為Assertion……它只是一個經過簽名且可能加密的XML，從理論上講，您可以在WS-Fed中使用其他令牌，然后在SAML中使用，但我從未聽說有人真正這樣做過）。