安全令牌服務(STS)是用於根據WS-Trust和WS-Federation協議構建、簽署和頒發安全令牌的服務組件。實施這些協議需要進行大量的工作，但WIF能為你完成所有這些工作，讓那些不精通協議的人不費吹灰之力即可啟動並運行STS。可以使用雲STS（如LiveID STS）、預先構建的STS（如ADFS 2.0），或者如果想要頒發自定義令牌或提供自定義身份驗證或授權，可以使用WIF構建自定義的STS。借助WIF即可輕松地構建自己的STS。
STS身份驗證支持多種方案：
q 從身份驗證機制中分離出應用程序和服務，從而使其能夠專注於授權相關聲明。
q 支持多種憑據類型，而不會使應用程序和服務的實現變復雜。
q 支持聯合方案，用戶可以通過在自身的域中進行身份驗證來獲得對另一個域中資源的訪問權限（通過建立不同域的STS之間的信任關系）。
q 簡化標識委派方案，經過身份驗證的用戶將獲得對下游服務的訪問權限。
q 簡化聲明轉換，使相關聲明能夠用於對應用程序和服務進行授權。
其中的任何方案都可以基於被動聯合（基於浏覽器）或主動聯合（基於Windows客戶端）。下面詳細介紹這些方案，同時說明如何使用Geneva框架在自定義STS中構建相關邏輯。
主動聯系與被動聯合
在深入探討STS的實現之前，先回顧一些基礎知識。在主動聯合中使用的STS是WS-Federation主動請求者配置文件和（主要）WS-Trust 規范的實現。
從較高層次看，WS-Trust使用四種服務操作來描述一個約定：頒發、驗證、續訂和取消。客戶端分別調用這些操作來請求安全令牌、驗證安全令牌、續訂已過期的安全令牌以及取消不應再繼續使用的安全令牌。根據WS-Trust 規范，每個操作都必須以“請求安全令牌”(RST) 的格式發送消息，並以“RST 響應”(RSTR) 的格式返回消息。在本節中，假定頒發的令牌是“安全聲明標記語言”SAML 1.1或SAML 2.0令牌。
圖15-4展示了主動令牌頒發時RST和RSTR的核心內容。
圖15-4 主動聯合方案的令牌頒發
如圖所示，RST消息包括請求安全令牌所需的必要信息，其中涉及待頒發令牌的類型（本書中是SAML）、將要被納入到頒發令牌中的“依賴方”(RP) 所請求的聲明、有關RP (AppliesTo) 的信息（包括URL和通常用於標識RP的證書），以及將被用於RSTR所返回的“證明密鑰”(proof key) 的可選（未顯示）密鑰材料。
如果令牌頒發成功，RSTR將包括頒發的SAML令牌和證明密鑰（假定STS決定使用哪個證明密鑰，因此必須在RSTR中返回它）。SAML令牌將包括已驗證方的相關聲明，它由STS簽名來保護令牌不被篡改，令牌中將包含用於 RP 加密的證明密鑰，並且它會為 RP 加密自身以確保只有目標接收節點才能處理該令牌。
客戶端使用證明密鑰來簽署發往RP的消息。RP必須能夠在 SAML 令牌中解密證明密鑰，否則拒收該消息。如果令牌中的證明密鑰與消息中的簽名匹配，則證明此次對 RP 的調用是由請求該令牌的調用方所發送的。
被動聯合方案基於WS-Federation 被動請求者配置文件，其中涉及基於浏覽器的通信。雖然底層消息傳遞仍基於WS-Trust，但RST卻在STSURL中被分解為查詢字符串參數，而RSTR通常會作為表單參數被發布到 RP。被動STS和RP使用聯合Web處理程序來截取這些參數。被動STS可以直接處理WS-Trust 請求，或者將其傳遞到底層WS-Trust實現。圖15-5說明了在被動聯合方案中對RST和RSTR 的處理方式。
圖15-5 被動聯合方案的令牌頒發
主動與被動聯合方案的一個本質差異在於頒發的SAML令牌的類型。主動聯合通常依靠使用“密鑰所有者”(holder-of-key) 類型主體確認的SAML令牌，這意味著前面所述，在實際當中存在著一個證明密鑰，它可以證明發出令牌進行驗證的客戶端是請求該令牌（也稱為ActAs行為）的主體。被動聯合方案通常涉及帶有“持有者”(bearer) 類型主體確認的SAML令牌（也稱為持有者令牌）。這種類型的令牌不包含證明密鑰，有時也稱為無密鑰令牌。它依靠傳輸來確保從STS獲得該令牌並將其傳遞給 RP。
簡單的主動聯合方案如圖15-6所示。
圖15-6 使用單一RP 和主動 IP-STS 的簡單聯合方案
如圖所示，通常存在以下參與者：
q RP，由客戶端調用的服務。
q 單獨的STS（也作為服務實現），支持WS-Trust 協議。此STS將對調用方進行身份驗證並頒發具有標識調用方聲明的安全令牌，也稱為標識提供者或 IP-STS。
q 客戶端，在本例中為基於Windows的應用程序，它依靠代理對STS進行身份驗證、檢索令牌頒發結果以及發送消息給 RP（它會提供用於身份驗證和授權的頒發令牌）。
圖15-7說明了在此實現中可以靈活設置的部分。
圖15-7 自定義主動STS和主動IP-STS的實現體系結構
圖中包括自定義SecurityTokenService 實現、使用 ServiceHost 擴展 (WSTrustServiceHost) 初始化用於聯合的運行時、使用 WSTrustContract 類型的派生配置一個或多個WS-Trust 端點以及用於標識模型運行時的其他相關配置設置。
聲明轉換
聲明轉換對於聯合的安全性至關重要：它可能在聯合過程中的任意時刻發生。在 IP-STS 和 RP 屬於同一域的簡單聯合方案中，IP-STS 負責將聲明從身份驗證期間用戶所提供的一組初始身份標識聲明轉換為 RP 能夠用以授權調用的聲明。用戶可以為 IP-STS 提供任何支持的憑據類型來進行身份驗證，其中每個都會評估一組代表該憑據的聲明。
IP-STS 將這些聲明轉換成一組標准的應用程序聲明，RP 可以通過這組聲明授權調用，它們可以是角色或更精細的聲明，如創建、讀取、更新或刪除等權限。圖15-8對這種方案進行了說明，其中Admin用戶登錄並被授予 Role 聲明和幾項 Action 聲明，其中包括創建、讀取、更新和刪除等。
查看本欄目
此外，有時還存在STS頒發的聲明不應與 RP 直接共享的情況。例如，可以不必通過頒發 Age 聲明來使 RP 了解用戶的年齡，RP 可以請求 IsOver13 聲明來確保調用方的年齡符合使用 RP 功能的條件。這樣可以確保 Age 聲明的實際值不會離開STS。當然，這也表明 ST 將提供既能避免共享個人詳細信息又可以包含 RP 所需數據的聲明。
當屬於一個域的用戶被授予對另一個域中RP 的訪問權限時，聯合方案中也會發生聲明轉換。在這種情況下會涉及兩個STS：用戶域的 IP-STS 和 RP 所屬域的 RP-STS。
同樣也是在這種情況下，IP-STS 會授予一些 RP-STS 能夠理解且達成一致的聲明；但這些聲明可能無法在 RP 應用程序中直接使用。相反，RP-STS 可能會負責將另一組可信聲明轉換為能夠被 RP 域所理解的聲明。
圖15-10說明了這種方案。
圖15-10 聯合方案中的聲明轉換
如圖所示，當 Joe 試圖在沒有令牌的情況下訪問 RP 時，他將登錄到自己所在域（域 B）的 IP-STS。該請求將申請 RP 能夠理解的聲明（在本例中為 RPClaim），以便 IP-STS 知道應該頒發 RP 能夠使用的令牌。當 RP-STS 接收到此令牌後，它將把該聲明轉換為 RP 專用的聲明。為了使此聯合方案能夠工作，必須在 RP-STS 和 IP-STS 之間建立信任關系，而且它們必須對 IP-STS 應該為其用戶頒發的將被授予對 RP 訪問權限的一組聲明達成一致。
對於那些熱衷於構建自定義STS而又不需要STS平台全部功能（如Geneva服務器）的用戶而言，WIF框架是非常實用的工具。但即便使用WIF框架，構建自定義STS也不是一項簡單的任務，建議盡量使用完整功能的STS以減少出現安全漏洞的風險。
-----------------------------注：本文部分內容改變自《.NET 安全揭秘》
作者：玄魂
出處：http://www.cnblogs.com/xuanhun/
