基於聲明的標識模型，簡單來講，就是將用戶信息作為聲明條件，向應用程序來提供用戶標識。一個聲明以是用戶名，也可能是電子郵件地址。現在的想法是配置外部標識系統，為應用程序提供了解用戶及其所做各個請求所需的所有信息，以及從可靠源接收的標識數據的加密保證。
基於聲明的標識模型，更容易實現單點登錄，並且應用程序可以徹底擺脫以下操作：
1) 對用戶進行身份驗證。
2) 存儲用戶賬戶和密碼。
3) 調用企業目錄以查看用戶標識的詳細信息。
4) 從其他平台或公司與標識系統集成。
在基於聲明的標識模型中，應用程序將根據用戶所提供的聲明來做出與標識相關的決策。這可以是任何內容，從包含用戶名字的簡單應用程序個性化設置，到授予用戶訪問應用程序中高級功能和資源權限。
基本概念
下面簡單介紹基於聲明的標識模型的基本術語。
（1） 標識
“標識”一詞通常是一個不明確的術語。但為了描述WIF中的編程模型，這裡使用術語“標識”來描述一組說明要保護的系統中用戶或其他一些實體的特性。比如一個常見的互聯網站點，對於一個普通用戶，其標識可能是用戶名，可能是性別，也可能是愛好，總之是一個完整實體的特性。
（2） 聲明
將聲明視為一條標識信息，如銷售角色中的姓名、電子郵件地址、年齡、成員身份。應用程序接收的聲明越多，對用戶了解得就越多。你可能想知道為何將這些稱為“聲明”而不是通常描述企業目錄時用到的“特性”。原因就在於送達的方式。在此模型中，應用程序並不在目錄中查詢用戶特性。相反，用戶向應用程序傳達聲明，由應用程序對其進行檢查。各聲明均由頒發者發出，你對這些聲明的信任度與對頒發者的信任度一樣。例如，你對公司域控制器發出的聲明的信任度高於對用戶自己發出的聲明。WIF代表Claim類型的聲明，此類型聲明具有找出聲明頒發者的Issuer屬性。
（3） 安全令牌
用戶向應用程序傳遞一組聲明和一個請求。 在Web服務中，這些聲明將在 SOAP封裝的安全標頭中傳遞。在基於浏覽器的Web應用程序中，這些聲明將通過HTTP POST從用戶的浏覽器中到達，並可能隨後緩存在 Cookie中（如果需要會話）。不論這些聲明如何到達，都必須對其進行序列化，這也是安全令牌所在之處。安全令牌是一組經過頒發機構數字簽名的序列化聲明。此簽名非常重要：它向你保證用戶並不只是生成大量聲明然後發送給你。在沒必要或不希望加密的安全性較低的情況下，可使用未簽名的令牌。
WIF的一個核心功能是，可以創建和讀取安全令牌。WIF和.NET Framework可以處理所有的加密工作，並為應用程序提供一組可以讀取的聲明。
（4） 頒發機構
不同類型的頒發機構有很多，從頒發 Kerberos票證的域控制器到頒發X.509證書的證書頒發機構。這裡討論的頒發機構是可頒發包含聲明的安全令牌的機構。此頒發機構是了解如何頒發安全令牌的 Web應用程序或 Web服務。它必須發出正確的聲明，提供給目標信賴方和提出請求的用戶，並且負責查看聲明並對用戶本身進行身份驗證。
不論選擇哪個頒發機構，它在標識解決方案中的作用都十分重要。在通過信任聲明將身份驗證的因素從應用程序中排除時，你會將責任轉交給該機構並要求其以你的名義對用戶進行身份驗證。
（5） 標准
為使所有這些操作能夠交互，使用了多個WS-*標准。使用WS-MetadataExchange檢索策略，並根據WS-Policy規范對策略本身進行結構化。STS（安全令牌服務）公開了實施WS-Trust規范的終結點，此規范描述了如何請求和接收安全令牌。如今，大多數 STS可頒發安全聲明標記語言(SAML)格式的令牌。SAML是行業認可的XML詞匯，可用於以交互方式表示聲明。或者，在多平台情況下，這使你可以與完全不同的平台上的 STS進行通信，並在所有應用程序中實現單點登錄。
（6） 基於浏覽器的應用程序
基於浏覽器的應用程序也可以使用標識模型。
首先，用戶將浏覽器指向Web應用程序（信賴方應用程序）。Web應用程序將此浏覽器重定向到STS以便可以對用戶進行身份驗證。在可以讀取傳入請求的簡單 Web應用程序中托管 STS，使用標准HTTP機制對用戶進行身份驗證，然後創建SAML令牌並通過一段JavaScript代碼給予回復，此代碼將使浏覽器發起可將SAML令牌發送回RP的HTTP POST。 此POST的正文包含RP請求的聲明。此時，RP通常會將聲明打包到Cookie以便不必為各個請求重定向用戶。
（7） CardSpace和標識選擇器
WIF為CardSpace序列化提供API，此API可用於構建托管的信息卡頒發以及在應用程序中啟用信息卡登錄。
標識選擇器提供以下功能：
q 幫助用戶管理 Web的多個標識。
q 幫助用戶為指定信賴方選擇適當標識。
q 幫助保護用戶隱私。
基本實現
在具體了解基於聲明的標識模型的實現機制之前，先來了解或者說回顧傳統的驗證模式。當然，本書高級擴展的部分會推薦基於聲明的標識模型，不代表傳統的方式做得不好，事實上，實踐驗證它們足夠優秀。討論基於聲明的標識模型，給你一個全新的選擇，或者在適合的場景下使用它。
（1） Iprincipal接口
管理標識和訪問控制，需要得到當前應用環境的用戶信息，從而根據用戶信息識別其標識，並根據標識來判斷權限。
在.NET應用程序中，當前上下文中的用戶信息由IIdentity接口來表示。該接口的定義如代碼清單15-1所示。
代碼清單15-1 IIdentity接口定義
public interface IIdentity
{
// Properties
string AuthenticationType { get; }
bool IsAuthenticated { get; }
string Name { get; }
}
IIdentity接口的主要作用是用來驗證，這一點從它的屬性中也能看出來。提到驗證肯定會想到授權。
（2） Iidentity接口
在授權環節用到的最主要的接口是Iprinicipal，定義如代碼清單15-2。
代碼清單15-2 Iprinicipal定義
public interface IPrinicipal
{
// Methods
bool IsInRole(string role);
// Properties
IIdentity Identity { get; }
}
在Iprinicipal接口中，用來做授權驗證的前提是它的Identity屬性。在.NET程序中，總能從上下文中獲取Iprinicipal示例，比如在ASP.NET程序中，可以通過HttpContext.Current.User屬性獲取該值，在一般程序中可以通過Thread.CurrentPrincipal來獲取該實例。本書前面章節介紹過.NET對Iprinicipal的不同實現，比如WindowsPrincipal、GenericPrincipal或者自定義的實現。當然，這只是傳統的.NET認證和授權內容的冰山一角，不過本書中已經用了足夠的篇幅來討論它們，而且也是目前.NET安全框架的核心。
當使用VS創建一個ASP.NET的Web站點，默認驗證模式是Windows，這意味著，應用程序期望IIS來負責驗證用戶。然而，當檢查此應用場景下的Iprinicipal會發現，大部分屬性都是空值，這是因為默認情況下Web站點啟用了匿名驗證。此時需要使用IIS或者修改Web.config來禁用匿名訪問，啟用Windows驗證。
當調整完之後，你應該知道，這樣的驗證方式只適合當前的局域網絡，如果換個環境將無法訪問。如果在代碼中使用IsInRole類似的方法來做角色判斷，那麼當站點進行遷移之後，將完全失效。比如換服務器，業務轉移到雲中。
面對互聯網環境，或者為了使應用更具靈活性，選擇Form身份驗證方式，不可避免地需要構建數據庫來存儲用戶信息。Form身份驗證方式帶來了很大的靈活性，但是仍然無法兼容異構系統的統一驗證，甚至在一個WCF和ASP.NET互相協助的系統中，也無法統一Form認證和WCF身份認證。
將身份驗證交給Windows或者交給ASP.NET，都是不錯的做法，因為在一定程度上將這樣的工作交給“第三方”。但是仍然無法真正地從設計角度將用戶標識和訪問限制同業務應用分離出來。
（3） 分離應用和標識驗證
曾幾何時，開發人員被迫在程序中直接處理硬件。如果想打印文檔，需要知道如何在程序中調用打印模塊，使用各種中斷，而且硬件不同，調用方式也會不同。
幸運的是，那些日子已經一去不復返了。今天，我們可以間接地調度硬件通過驅動程序。所有的驅動程序都公開簡單的調用接口給上層的應用程序，我們將接口層稱作邏輯層，它下面是核心驅動，核心驅動下面才是硬件層。
現在，作為.NET開發人員，只需要調用一個PrintDocument方法就可以解決問題。
直接在程序中處理認證和授權與直接在程序中處理打印模塊相比，二者很相似：需要處理太多復雜的情況，要應對各種各樣的變化。硬件調用的問題被驅動程序解決，那麼是否有理由相信，可以用類似的方法來解決訪問控制問題呢？
標識和訪問控制的統一面臨著巨大的挑戰，比如，目前驗證和授權的技術和協議屬於不同的廠商；不同的架構，不同的業務使用的數據存儲格式不同；驗證點也各不相同。不過也不用太悲觀，在Web 2.0時代，為了不同應用的交換，甚至在安全領域，出現了很多標准化協議，比如SOAP、WS-Security、WS-Trust、WS-Federation、SAML（Security Assertion Markup Language），以及最近出現的OpenID、OAuth和其他開發協議。如果沒聽說過這些協議，或者不理解其細節也沒關系，暫時將注意力集中在這些開放的協議給我們帶來了什麼。這裡不打算去探討每個協議的功能和細節，我們從具體的場景中來認識基於協議的安全框架帶來的好處。
圖15-2是一個簡單的驗證系統，它包含基於聲明的標識模型中幾個主要實體。
圖15-2 基於聲明的標識模型實體
在這個簡單的系統中，包括一個用戶和一個用戶要訪問的應用。對於應用而言，它也許不需要關心這個用戶的每一個屬性，用戶在正式訪問應用之前，要經過一個用戶到標識的轉化過程。在本應用場景中將用戶虛擬為一個影迷。
應用程序可能是一個網站，可能是一個Web服務，也可能是一個桌面應用，總之，它需要對用戶驗證和授權。在標識模型中，將這樣的應用稱為信賴方（Relying Party，RP），將應用虛擬為售票員和電影院。
這個系統會包含多個IP（Identity Providers）。每一個IP針對某一類型的用戶而存在。每一標識提供程序是一個抽象的角色，在具體應用時它會被實例化。
假設每一個用戶都具有基本的信息，用於系統實施驗證，這些基本信息就是聲明。從另一個角度講，聲明是對在當前上下文中對用戶的一個描述。它是IP的創建者，是RP的消費者。
圖15-3是該系統的驗證流程。
查看本欄目
