聊聊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

本文來自網易實踐者社區，經做者邱晟受權發佈。