WIF基本原理（2）基于声明的标识模型
WIF基本原理（2）基于聲明的標識模型
基于聲明的標識模型，簡單來講，就是將用戶信息作為聲明條件，向應用程序來提供用戶標識。一個聲明以是用戶名，也可能是電子郵件地址。現在的想法是配置外部標識系統，為應用程序提供了解用戶及其所做各個請求所需的所有信息，以及從可靠源接收的標識數據的加密保證。
基于聲明的標識模型，更容易實現單點登錄，并且應用程序可以徹底擺脫以下操作：
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是該系統的驗證流程。
圖15-3? 驗證流程
現在對圖15-3做簡要的梳理：
1)??????? 用戶（Subject）想要訪問應用（RP），在本例中假設他通過瀏覽器發送請求。這一步用戶被告知需要填寫什么信息、RP支持哪一種IP、什么樣的安全通信協議會被使用。
2)??????? 客戶選擇一種合適的IP，請求令牌。在這個過程中，客戶需要提供能被IP識別的憑據信息，這些信息被保存在Policy中。
3)??????? IP接到并開始處理請求。如果IP認為請求合乎規范，它接收聲明信息，然后發送一個安全令牌到客戶端。
4)??????? RP接收并檢查客戶端傳遞過來的安全令牌，如果通過，RP對客戶進行授權。
雖然這個簡單系統和傳統的驗證模型有很多不同，但是需要從類似的或者更復雜的場景中抽象出一個簡單易用的模型。WIF提供了這樣的模型，其他細節可參考《.NET安全揭秘》一書中的相關章節。
-------------------------注：本文部分內容改編自《.NET 安全揭秘》
總結
以上是生活随笔為你收集整理的WIF基本原理（2）基于声明的标识模型的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 修改Linux字体出现乱码
- 下一篇： C中out型参数的使用介绍