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

在較高層次上，傳統上使用WS- *協議。

SAML-P（P for protocol）被開源運動使用，因此被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 Passive Requestor Profile的瀏覽器聯合，它描述了瀏覽器和Web應用程序之間的相同通信流。它依靠瀏覽器重定向，HTTP GET和POST請求並傳遞令牌。

SAMLP只是一個不同的協議，當涉及到事物如何通信時，如重定向URL等，但差異不相關（在大多數情況下）並且僅取決於客戶端支持的內容（例如，Java將使用SAML）。最大的區別在於，我認爲SAMLP允許身份提供者啓動使用案例（這是我認爲最安全的使用案例），其中用戶在身份提供商處啓動（例如您的ADFS服務器的Web代理，=聲明提供者MS條款），而不是從Web服務開始，然後重定向到服務提供商（= MS中繼方）。另外，當我們談論SAML時，我們通常指的是SAML 2.0，而WS-Fed使用SAML 1.x令牌（並且MS將其稱爲令牌，SAML將它們稱爲斷言...它只是一個簽名並且可能是加密的XML，我認爲理論上你可以在WS-Fed中使用其他Tokens，然後SAML，但我從來沒有聽說過任何人這樣做）。