WIF基本原理（2）基于聲明的標(biāo)識模型

基于聲明的標(biāo)識模型，簡單來講，就是將用戶信息作為聲明條件，向應(yīng)用程序來提供用戶標(biāo)識。一個聲明以是用戶名，也可能是電子郵件地址。現(xiàn)在的想法是配置外部標(biāo)識系統(tǒng)，為應(yīng)用程序提供了解用戶及其所做各個請求所需的所有信息，以及從可靠源接收的標(biāo)識數(shù)據(jù)的加密保證。

基于聲明的標(biāo)識模型，更容易實現(xiàn)單點登錄，并且應(yīng)用程序可以徹底擺脫以下操作：

1)??????? 對用戶進行身份驗證。

2)??????? 存儲用戶賬戶和密碼。

3)??????? 調(diào)用企業(yè)目錄以查看用戶標(biāo)識的詳細信息。

4)??????? 從其他平臺或公司與標(biāo)識系統(tǒng)集成。

在基于聲明的標(biāo)識模型中，應(yīng)用程序?qū)⒏鶕?jù)用戶所提供的聲明來做出與標(biāo)識相關(guān)的決策。這可以是任何內(nèi)容，從包含用戶名字的簡單應(yīng)用程序個性化設(shè)置，到授予用戶訪問應(yīng)用程序中高級功能和資源權(quán)限。

基本概念

下面簡單介紹基于聲明的標(biāo)識模型的基本術(shù)語。

（1）????? 標(biāo)識

“標(biāo)識”一詞通常是一個不明確的術(shù)語。但為了描述WIF中的編程模型，這里使用術(shù)語“標(biāo)識”來描述一組說明要保護的系統(tǒng)中用戶或其他一些實體的特性。比如一個常見的互聯(lián)網(wǎng)站點，對于一個普通用戶，其標(biāo)識可能是用戶名，可能是性別，也可能是愛好，總之是一個完整實體的特性。

（2）????? 聲明

將聲明視為一條標(biāo)識信息，如銷售角色中的姓名、電子郵件地址、年齡、成員身份。應(yīng)用程序接收的聲明越多，對用戶了解得就越多。你可能想知道為何將這些稱為“聲明”而不是通常描述企業(yè)目錄時用到的“特性”。原因就在于送達的方式。在此模型中，應(yīng)用程序并不在目錄中查詢用戶特性。相反，用戶向應(yīng)用程序傳達聲明，由應(yīng)用程序?qū)ζ溥M行檢查。各聲明均由頒發(fā)者發(fā)出，你對這些聲明的信任度與對頒發(fā)者的信任度一樣。例如，你對公司域控制器發(fā)出的聲明的信任度高于對用戶自己發(fā)出的聲明。WIF代表Claim類型的聲明，此類型聲明具有找出聲明頒發(fā)者的Issuer屬性。

（3）????? 安全令牌

用戶向應(yīng)用程序傳遞一組聲明和一個請求。 在Web服務(wù)中，這些聲明將在 SOAP封裝的安全標(biāo)頭中傳遞。在基于瀏覽器的Web應(yīng)用程序中，這些聲明將通過HTTP POST從用戶的瀏覽器中到達，并可能隨后緩存在 Cookie中（如果需要會話）。不論這些聲明如何到達，都必須對其進行序列化，這也是安全令牌所在之處。安全令牌是一組經(jīng)過頒發(fā)機構(gòu)數(shù)字簽名的序列化聲明。此簽名非常重要：它向你保證用戶并不只是生成大量聲明然后發(fā)送給你。在沒必要或不希望加密的安全性較低的情況下，可使用未簽名的令牌。

WIF的一個核心功能是，可以創(chuàng)建和讀取安全令牌。WIF和.NET Framework可以處理所有的加密工作，并為應(yīng)用程序提供一組可以讀取的聲明。

（4）????? 頒發(fā)機構(gòu)

不同類型的頒發(fā)機構(gòu)有很多，從頒發(fā) Kerberos票證的域控制器到頒發(fā)X.509證書的證書頒發(fā)機構(gòu)。這里討論的頒發(fā)機構(gòu)是可頒發(fā)包含聲明的安全令牌的機構(gòu)。此頒發(fā)機構(gòu)是了解如何頒發(fā)安全令牌的 Web應(yīng)用程序或 Web服務(wù)。它必須發(fā)出正確的聲明，提供給目標(biāo)信賴方和提出請求的用戶，并且負責(zé)查看聲明并對用戶本身進行身份驗證。

不論選擇哪個頒發(fā)機構(gòu)，它在標(biāo)識解決方案中的作用都十分重要。在通過信任聲明將身份驗證的因素從應(yīng)用程序中排除時，你會將責(zé)任轉(zhuǎn)交給該機構(gòu)并要求其以你的名義對用戶進行身份驗證。

（5）????? 標(biāo)準(zhǔn)

為使所有這些操作能夠交互，使用了多個WS-*標(biāo)準(zhǔn)。使用WS-MetadataExchange檢索策略，并根據(jù)WS-Policy規(guī)范對策略本身進行結(jié)構(gòu)化。STS（安全令牌服務(wù)）公開了實施WS-Trust規(guī)范的終結(jié)點，此規(guī)范描述了如何請求和接收安全令牌。如今，大多數(shù) STS可頒發(fā)安全聲明標(biāo)記語言(SAML)格式的令牌。SAML是行業(yè)認可的XML詞匯，可用于以交互方式表示聲明。或者，在多平臺情況下，這使你可以與完全不同的平臺上的 STS進行通信，并在所有應(yīng)用程序中實現(xiàn)單點登錄。

（6）????? 基于瀏覽器的應(yīng)用程序

基于瀏覽器的應(yīng)用程序也可以使用標(biāo)識模型。

首先，用戶將瀏覽器指向Web應(yīng)用程序（信賴方應(yīng)用程序）。Web應(yīng)用程序?qū)⒋藶g覽器重定向到STS以便可以對用戶進行身份驗證。在可以讀取傳入請求的簡單 Web應(yīng)用程序中托管 STS，使用標(biāo)準(zhǔn)HTTP機制對用戶進行身份驗證，然后創(chuàng)建SAML令牌并通過一段JavaScript代碼給予回復(fù)，此代碼將使瀏覽器發(fā)起可將SAML令牌發(fā)送回RP的HTTP POST。 此POST的正文包含RP請求的聲明。此時，RP通常會將聲明打包到Cookie以便不必為各個請求重定向用戶。

（7）????? CardSpace和標(biāo)識選擇器

WIF為CardSpace序列化提供API，此API可用于構(gòu)建托管的信息卡頒發(fā)以及在應(yīng)用程序中啟用信息卡登錄。

標(biāo)識選擇器提供以下功能：

q? 幫助用戶管理 Web的多個標(biāo)識。

q? 幫助用戶為指定信賴方選擇適當(dāng)標(biāo)識。

q? 幫助保護用戶隱私。

基本實現(xiàn)

在具體了解基于聲明的標(biāo)識模型的實現(xiàn)機制之前，先來了解或者說回顧傳統(tǒng)的驗證模式。當(dāng)然，本書高級擴展的部分會推薦基于聲明的標(biāo)識模型，不代表傳統(tǒng)的方式做得不好，事實上，實踐驗證它們足夠優(yōu)秀。討論基于聲明的標(biāo)識模型，給你一個全新的選擇，或者在適合的場景下使用它。

（1）?????? Iprincipal接口

管理標(biāo)識和訪問控制，需要得到當(dāng)前應(yīng)用環(huán)境的用戶信息，從而根據(jù)用戶信息識別其標(biāo)識，并根據(jù)標(biāo)識來判斷權(quán)限。

在.NET應(yīng)用程序中，當(dāng)前上下文中的用戶信息由IIdentity接口來表示。該接口的定義如代碼清單15-1所示。

代碼清單15-1? IIdentity接口定義

???public?interface?IIdentity

????{

????????//?Properties

????????string?AuthenticationType?{?get;?}

????????bool?IsAuthenticated?{?get;?}

????????string?Name?{?get;?}

????}

IIdentity接口的主要作用是用來驗證，這一點從它的屬性中也能看出來。提到驗證肯定會想到授權(quán)。

（2）?????? Iidentity接口

在授權(quán)環(huán)節(jié)用到的最主要的接口是Iprinicipal，定義如代碼清單15-2。

代碼清單15-2? Iprinicipal定義

????public?interface?IPrinicipal

????{

????????//?Methods

????????bool?IsInRole(string?role);

????????//?Properties

????????IIdentity?Identity?{?get;?}

????}

在Iprinicipal接口中，用來做授權(quán)驗證的前提是它的Identity屬性。在.NET程序中，總能從上下文中獲取Iprinicipal示例，比如在ASP.NET程序中，可以通過HttpContext.Current.User屬性獲取該值，在一般程序中可以通過Thread.CurrentPrincipal來獲取該實例。本書前面章節(jié)介紹過.NET對Iprinicipal的不同實現(xiàn)，比如WindowsPrincipal、GenericPrincipal或者自定義的實現(xiàn)。當(dāng)然，這只是傳統(tǒng)的.NET認證和授權(quán)內(nèi)容的冰山一角，不過本書中已經(jīng)用了足夠的篇幅來討論它們，而且也是目前.NET安全框架的核心。

當(dāng)使用VS創(chuàng)建一個ASP.NET的Web站點，默認驗證模式是Windows，這意味著，應(yīng)用程序期望IIS來負責(zé)驗證用戶。然而，當(dāng)檢查此應(yīng)用場景下的Iprinicipal會發(fā)現(xiàn)，大部分屬性都是空值，這是因為默認情況下Web站點啟用了匿名驗證。此時需要使用IIS或者修改Web.config來禁用匿名訪問，啟用Windows驗證。

當(dāng)調(diào)整完之后，你應(yīng)該知道，這樣的驗證方式只適合當(dāng)前的局域網(wǎng)絡(luò)，如果換個環(huán)境將無法訪問。如果在代碼中使用IsInRole類似的方法來做角色判斷，那么當(dāng)站點進行遷移之后，將完全失效。比如換服務(wù)器，業(yè)務(wù)轉(zhuǎn)移到云中。

面對互聯(lián)網(wǎng)環(huán)境，或者為了使應(yīng)用更具靈活性，選擇Form身份驗證方式，不可避免地需要構(gòu)建數(shù)據(jù)庫來存儲用戶信息。Form身份驗證方式帶來了很大的靈活性，但是仍然無法兼容異構(gòu)系統(tǒng)的統(tǒng)一驗證，甚至在一個WCF和ASP.NET互相協(xié)助的系統(tǒng)中，也無法統(tǒng)一Form認證和WCF身份認證。

將身份驗證交給Windows或者交給ASP.NET，都是不錯的做法，因為在一定程度上將這樣的工作交給“第三方”。但是仍然無法真正地從設(shè)計角度將用戶標(biāo)識和訪問限制同業(yè)務(wù)應(yīng)用分離出來。

（3）?????? 分離應(yīng)用和標(biāo)識驗證

曾幾何時，開發(fā)人員被迫在程序中直接處理硬件。如果想打印文檔，需要知道如何在程序中調(diào)用打印模塊，使用各種中斷，而且硬件不同，調(diào)用方式也會不同。

幸運的是，那些日子已經(jīng)一去不復(fù)返了。今天，我們可以間接地調(diào)度硬件通過驅(qū)動程序。所有的驅(qū)動程序都公開簡單的調(diào)用接口給上層的應(yīng)用程序，我們將接口層稱作邏輯層，它下面是核心驅(qū)動，核心驅(qū)動下面才是硬件層。

現(xiàn)在，作為.NET開發(fā)人員，只需要調(diào)用一個PrintDocument方法就可以解決問題。

直接在程序中處理認證和授權(quán)與直接在程序中處理打印模塊相比，二者很相似：需要處理太多復(fù)雜的情況，要應(yīng)對各種各樣的變化。硬件調(diào)用的問題被驅(qū)動程序解決，那么是否有理由相信，可以用類似的方法來解決訪問控制問題呢？

標(biāo)識和訪問控制的統(tǒng)一面臨著巨大的挑戰(zhàn)，比如，目前驗證和授權(quán)的技術(shù)和協(xié)議屬于不同的廠商；不同的架構(gòu)，不同的業(yè)務(wù)使用的數(shù)據(jù)存儲格式不同；驗證點也各不相同。不過也不用太悲觀，在Web 2.0時代，為了不同應(yīng)用的交換，甚至在安全領(lǐng)域，出現(xiàn)了很多標(biāo)準(zhǔn)化協(xié)議，比如SOAP、WS-Security、WS-Trust、 WS-Federation、SAML（Security Assertion Markup Language），以及最近出現(xiàn)的OpenID、OAuth和其他開發(fā)協(xié)議。如果沒聽說過這些協(xié)議，或者不理解其細節(jié)也沒關(guān)系，暫時將注意力集中在這些開放的協(xié)議給我們帶來了什么。這里不打算去探討每個協(xié)議的功能和細節(jié)，我們從具體的場景中來認識基于協(xié)議的安全框架帶來的好處。

圖15-2是一個簡單的驗證系統(tǒng)，它包含基于聲明的標(biāo)識模型中幾個主要實體。

圖15-2? 基于聲明的標(biāo)識模型實體

在這個簡單的系統(tǒng)中，包括一個用戶和一個用戶要訪問的應(yīng)用。對于應(yīng)用而言，它也許不需要關(guān)心這個用戶的每一個屬性，用戶在正式訪問應(yīng)用之前，要經(jīng)過一個用戶到標(biāo)識的轉(zhuǎn)化過程。在本應(yīng)用場景中將用戶虛擬為一個影迷。

應(yīng)用程序可能是一個網(wǎng)站，可能是一個Web服務(wù)，也可能是一個桌面應(yīng)用，總之，它需要對用戶驗證和授權(quán)。在標(biāo)識模型中，將這樣的應(yīng)用稱為信賴方（Relying Party，RP），將應(yīng)用虛擬為售票員和電影院。

這個系統(tǒng)會包含多個IP（Identity Providers）。每一個IP針對某一類型的用戶而存在。每一標(biāo)識提供程序是一個抽象的角色，在具體應(yīng)用時它會被實例化。

假設(shè)每一個用戶都具有基本的信息，用于系統(tǒng)實施驗證，這些基本信息就是聲明。從另一個角度講，聲明是對在當(dāng)前上下文中對用戶的一個描述。它是IP的創(chuàng)建者，是RP的消費者。

圖15-3是該系統(tǒng)的驗證流程。

圖15-3? 驗證流程

現(xiàn)在對圖15-3做簡要的梳理：

1)??????? 用戶（Subject）想要訪問應(yīng)用（RP），在本例中假設(shè)他通過瀏覽器發(fā)送請求。這一步用戶被告知需要填寫什么信息、RP支持哪一種IP、什么樣的安全通信協(xié)議會被使用。

2)??????? 客戶選擇一種合適的IP，請求令牌。在這個過程中，客戶需要提供能被IP識別的憑據(jù)信息，這些信息被保存在Policy中。

3)??????? IP接到并開始處理請求。如果IP認為請求合乎規(guī)范，它接收聲明信息，然后發(fā)送一個安全令牌到客戶端。

4)??????? RP接收并檢查客戶端傳遞過來的安全令牌，如果通過，RP對客戶進行授權(quán)。

雖然這個簡單系統(tǒng)和傳統(tǒng)的驗證模型有很多不同，但是需要從類似的或者更復(fù)雜的場景中抽象出一個簡單易用的模型。WIF提供了這樣的模型，其他細節(jié)可參考《.NET安全揭秘》一書中的相關(guān)章節(jié)。

-------------------------注：本文部分內(nèi)容改編自《.NET 安全揭秘》

總結(jié)

以上是生活随笔為你收集整理的WIF基本原理（2）基于声明的标识模型的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。