聊聊WS-Federation

本文來自網易雲社群

單點登入（Single Sign On），簡稱為 SSO，目前已經被大家所熟知。簡單的說, 就是在多個應用系統中，使用者只需要登入一次就可以訪問所有相互信任的應用系統。 舉例: 我們可以使用corp郵箱的賬號登入oa系統; 登入了網易通行證，就能夠輕鬆在郵箱，雲音樂等應用中來回切換，而不需要每次都輸入賬號/密碼。SSO的解決方案，有我們非常熟悉的OpenID，和本文準備介紹的WS-Federation，以及其他SAML，CAS等等。

WS-Federation（簡稱: WS-Fed）屬於Web Services Security(簡稱: WS-Security、WSS: 針對web-service安全性方面擴充套件的協議標準集合) 的一部分，是由OASIS（https://www.oasis-open.org）釋出的標準協議，其主要貢獻者是Microsoft 和 IBM。WS-Fed 1.1 版本釋出於2003年, 最新的1.2版本標準釋出於2009年。 所以這協議不是個新鮮玩意，而是個老傢伙（OpenID是在2005年才開發了第一個版本）。只不過該協議主要應用在企業服務，並且是在微軟自己的產品中主推，其他廠家的產品可能更願意選擇SAML。另外，該標準是基於SOAP的，整個協議雖然功能強大，細節考慮周全，但實現起來會比較重，只有為了能和微軟的服務整合，才會優先考慮該協議。

WS-Federation的基本目標就是為了能夠簡化聯合（所謂聯合: Federation，是指一組相互之間存在安全共享資源關係的領域集合）服務的開發。WS-Fed使用了原有的WS-Security框架，WS-Trust和WS-SecurityPolicy。WS-Security框架提供瞭如何基於安全令牌的SOAP訊息傳輸機制；WS-Trust定義了Security Token Service （STS）協議用於請求/釋出安全令牌；WS-SecurityPolicy允許具體的應用服務描述它們各自的安全需求。WS-Federation 擁有以下擴充套件特性:

Ø  Federation Metadata

當一個組織需要連線到一個已存在的聯合時，這些聯合的成員就需要把相關服務的配置資訊公佈出來並互相交換。從而使得聯合中的成員都能夠識別那些共用的服務（例如Identity服務），還有那些用來訪問服務的策略資訊。為此WS-Fed定義了後設資料模型和文件格式用於這些相關服務的發現和結合，以此產生的聯合後設資料文件(Federation Metadata Document)描述了服務是如何參與到聯合中，並如何被其他服務呼叫。

Ø  Authorization

WS-Fed中定義的授權模型不僅能夠滿足基本的聯合內不同服務間基本的通用授權需求。額外增加了2個擴充套件特性用於豐富授權功能:

a)         允許在發往STS的RST請求中可以附加一個關於當前令牌請求的環境資訊

b)         允許在處理不同的具體請求中宣告不同的具體要求。

Ø  Authentication Types

WS-Fed為常用的認證方式和保證級別定義了一套通用資源識別符號（URI），可以在RST和RSTR訊息的wst:AuthenticationType引數中直接使用，從而方便聯合內服務之間的互動。

Ø  Attribute Services

當請求者在訪問某些資源時，可能會被要求提供一些額外資訊用於完成訪問授權。但這些資訊又沒有包含在STS頒發的令牌中。因此，屬性服務就可以用於解決此類常見問題，它可以讓請求者在必要的時候來獲取到當前賬號的額外資訊，從而完成後繼的資源訪問授權。WS-Fed中定義了一個基於STS概念的屬性服務訪問模型

Ø  Pseudonym Services

通過筆名服務可以使得不同的聯合服務獲取到的是不同的筆名身份資訊，從而降低身份詐騙的安全風險。 WS-Fed描述了筆名服務如何透明地STS整合，從而自動地將筆名對映到所頒發的實際安全令牌。

Ø  Privacy

WS-Fed擴充套件了RST/RSTR語法，定義了請求者如何宣告其隱私要求 以及 STS在頒發安全令牌時如何宣告隱私機制已經被啟用。通過隱私機制，當請求者向具體服務發起請求時，就可以附帶上相關個人/組織的隱私要求。

Ø  Indicating Specific Policy and Metadata

現實中請求者在訪問具體服務時，其中的某個請求可能會被要求額外的安全保證。為此WS-Fed定義了該機制，能夠通過請求者某個請求需要附加額外的安全語義，並且能夠讓請求者在碰到類似情況時可以自動重建請求，附加上安全語義後，再次嘗試和指定服務通訊。

Ø  Federated Sign-Out

WS-Fed定義了聯合登出的機制。基於該機制，當某個賬號宣告登出時，聯合中所有參與的服務都能夠識別到這個登出動作，從而清理所有相關的登入狀態或者安全令牌，進一步提高安全性。

Ø  Web (passive) Requestors

由於WS-Trust模型要求應用完全基於SOAP，這個顯然會限制使用場景。 WS-Federation為了解決這個問題，擴充套件了該模型，可以採用HTTP中最基礎的機制（GET，POST，重定向，cookie）來封裝WS-Trust協議。從而，擺脫了對SOAP的強制依賴。 所有支援HTTP 1.1標準的瀏覽器 或者 web應用都可以使用上WS-Fed。WS-Fed中稱呼該模式為: “WS-Federation Passive Requestor Profile” (相應的, 基於SOAP的就是Active requestor profile)。 該流程也是目前我們最常用的方式，來看一下流程示例:

流程說明:

1.         Browser向 SP 發起請求獲取資源A

2.         SP請求Browser提供認證憑證

3.         Browser向IP請求認證憑證

4.         Browser 和 IP 進行認證，例如: IP彈出個可供輸入賬號/密碼的視窗，使用者輸入後上傳給IP

5.         IP鑑定身份，釋出認證憑證 （即，對應第3步的應答）

6.         Browser將IP給的憑證傳送給SP （即，對應第2步的應答）

7.         SP判斷憑證合法後，返回資源給Browser （即，對應第1步的應答）

對比一下OpenID的認證流程:

很明顯的差異在於: OpenID在認證流程中，RP和OP之間是需要互相通訊的；而WS-Fed中SP和IP之間沒有直接的通訊，全部通過Browser轉發完成。因此OpenID認證流程必須保證OP能夠和所有依賴該OP的應用服務(RP)直接通訊，並且在執行效能上會依賴RP和OP之間的通訊狀況。而WS-Fed對IP的保護會更好，只需要保證使用者能夠和IP通訊即可，認證效能上也能有更好的保證。此外，WS-Fed協議本身就支援授權機制，並且更多地考慮了企業的應用場景需求；而OpenID只支援認證功能。所以，簡單來講: WS-Fed 更適合企業使用者；而OpenID更適合個人使用者。

 WS-Fed的開源實現比較少，基於Java的就更少。目前能找到實現該協議的有Apache CXF Fediz 和 auth10-java。 前者是一套比較完整的Web Security框架包含應用端和認證伺服器端的實現; 後者僅僅是一個可以使用WS-Fed協議進行SSO的應用端模板。

最後，提一下OAuth。OAuth的設計目的是為了解決授權（Authorization）問題，它並不涉及到認證（Authentication）邏輯，與WS-Fed，OpenID有本質的差別。前者的著重點在於“你能做什麼”，後者的著重點在於“你是誰”。將OAuth應用於”認證”場景的，本質上都是偽認證，前提是我們假設授權服務只會把資源的許可權授予給該資源的擁有者。 目前OpenID已經發展到了OpenID Connect，實質上可以視為Authentication+OAuth2，從而一攬子解決認證和授權問題，並且得到了很多大公司的支援，相信以後會逐步替代單獨的OpenID服務。

參考資料

Ø  https://msdn.microsoft.com/en-us/library/bb498017.aspx

Ø  http://docs.oasis-open.org/ws-sx/ws-trust/200512

Ø  https://www.oasis-open.org/standards#wsfedv1.2

Ø  https://msdn.microsoft.com/en-us/library/ff423674.aspx

Ø  http://cxf.apache.org/fediz.html

Ø  https://github.com/auth10/auth10-java

原文： 聊聊WS-Federation

網易雲新使用者大禮包：https://www.163yun.com/gift

本文來自網易實踐者社群，經作者邱晟授權釋出。