使用WIF實現單點登入Part II —— Windows Identity Foundation基本原理

在上一篇文章中，我們已經使用WIF構建了一個基於MVC4的簡單的身分識別驗證程式，在這篇文章裡，我們將探討一下到底什麼是WIF，以及它的工作原理。然後在下一篇文章開始，我們將實際操作，實現單點登入功能。

身份標識的挑戰

在上一篇文章也提及到了，大部分的開發人員並不是安全方面的專家，很多人對於身分識別驗證，授權以及使用者體驗個人化等工作感覺非常的不爽。傳統的電腦技術的課程裡通常也不會教這些課題，因此這些東西經常在軟體開發週期的後半部分才會凸顯出來。當今，一個公司裡有數十上百個Web應用程式和服務已不是什麼新鮮事兒，很多公司都有自己的一套使用者標識，而且大部分公司都不會去用特定的驗證方法。開發人員都知道要為每一個程式都支援身份標識是多麼乏味的事情，而且IT專家也知道要管理這些程式的結果集是多麼昂貴。解決此問題的很有用的一步就是將使用者帳號集中到企業目錄中去。通常只有IT專家才知道查詢目錄的最有效方法，但如今這項工作通常都交給了開發人員。而且面對合并，收購和夥伴關係的時候，開發人員可能要訪問多個目錄，使用多個API。在微軟
 .NET  Framework 裡，有很多在程式裡支援身份標識的不同方法，而且每一個通訊架構對身份標識都有不同的處理，它們採用了不同的物件模型，不同的儲存模型,等等。甚至在ASP.NET裡，開發人員對於上哪找身份標識也會感到困惑：應該用  HttpContext.User  屬性？還是 Thread.CurrentPrincipal？對密碼的使用不當導致了網路釣魚的猖狂。而這麼多程式都自己幹自己的事兒，對公司來說就很難升級到強大的身分識別驗證技術。

更好的解決方案

一個解決這些問題的方法是別再在每個新的程式裡建造自訂的身份標識管道和使用者賬戶資料庫。但即使是依賴企業目錄的開發人員仍然對合并，收購和夥伴感到痛苦，甚至還有可能由於其它程式的低效查詢拖累了目錄而被責難為效能低下。本文所要講的基於聲明的解決方案不需要開發人員為了查詢使用者身份標識的細節而連到任何特定的企業目錄。相反，使用者請求帶著程式需要幹活兒的標識資訊一同到達。帶著這些聲明的使用者請求到達的時候，使用者就已經是驗證通過了，應用程式無需擔心管理或者尋找使用者賬戶的事兒，只需專註於業務即可。在應用程式之外處理身分識別驗證可以為開發人員，IT專家和使用者帶來很多好處。簡單地說，需要每個人來管理的使用者賬戶少了，身分識別驗證的集中化使其隨著其發展更容易升級到強壯的驗證方法，即使與其它平台和組織進行聯合身份標識也是如此。本文將幫你，作為一個開發人員，去理解宣告式身分識別模型以及通過使用微軟的新架構Windows
Identity Foundation(WIF)來利用它。

什麼是Windows Identity Foundation？

Windows  Identity  Foundation  (WIF) 是一組  .NET  Framework  類。它是為了在程式裡實現宣告式身分識別的架構。通過使用它，將更簡單地感受到本文所說的宣告式身分識別模型的好處。 Windows Identity Foundation可以用於任何基於.Net
Framework 3.5 SP1以上版本的Web應用程式或者Web服務。WIF只是微軟標識和訪問平台（Identity and Access Platform）軟體家族的一部分，這個家族實現了可互操作的標識原系統（Identity MetaSystem）這麼一個共用的產業願景。包括活動目錄聯合服務 (ADFS)  2.0  (之前被稱為
“Geneva”  Server)， Windows  CardSpace  2.0，以及 Windows  Identity Foundation (之前稱為 “Geneva” Framework)，來自於微軟新的基於聲明存取原則的核心部分。可以參考Identity
Management in Active Directory 來擷取更多關於ADFS和CardSpace組件的資訊。

宣告式身分識別模型

當建立聲明感知（claims-aware）的應用程式時，使用者向程式出示他的身份標識，標識以一組聲明來表示（見圖1）。一個聲明可能是使用者名稱，另一個聲明可能是電子郵件地址。此處的想法是一個外部的標識系統被配置來對於使用者發起的每一個請求，都為程式提供它所需要知道的使用者資訊，以及接收到的標識資料都經過受信任來源的加密保護。

圖1  使用者出示聲明

基於此模型，單點登入更容易了，而且應用程式也不用再幹這些事兒了：

• 驗證使用者身份
• 儲存使用者賬戶和密碼
• 調用企業目錄來查詢使用者標識明細
• 從其它平台或其它公司整合標識系統

基於此模型，應用程式通過使用者提供的聲明來處理所有有關標識的事情，從簡單的使用者姓名到授權使用者訪問進階特性和資源。基於聲明的身份標識介紹

上面說了這麼多，可能已經出現了很多陌生的名詞，接下來我們以一個實際生活中的例子來解釋一下這些名詞吧。

假設你要去電影院看一部紀錄片，要考慮以下因素：

1、該紀錄片含有不適合未成年人觀看的情節，因此電影院的員工需要你出示身份證明來驗證你是否適合觀看。你掏出錢包，卻發現你的身份證丟了，而駕照也已經到期了。

2、你決定不看首映，先到附近的DOL(Department of Licensing，牌照部）領取一個新的駕照。

3、工作人員先看你是否和記錄裡的照片長得一致，或許還會讓你去視力表那測一下。當他確信了你確實是你之後，就會給你發新的駕照。

4、你回到電影院出示了新駕照，工作人員確認了你確實夠年齡觀看影片了，就會給你下一場電影的門票。

示範了這個例子的過程。

上面這個例子應該說是很常見的了。那麼接下來我們把它抽象到我們的身分識別驗證裡去看看：

假設我們的系統包括了一個使用者（主體，subject）和他要訪問的程式。在上面的例子裡，這個使用者就是要去看電影的人；通常，subject可以是任何東西，無論是真實的使用者還是無人值守的程式標識。應用程式可以是一個網站，Web服務，或者通常的任何需要身分識別驗證和授權使用者的軟體。用標識裡的行話來講，就是叫做依賴方（relying party,RP）。在上面的例子裡，RP就是電影院及其工作人員。系統裡可能包括一個到多個識別提供者（identity
provider,IP）。IP是認識subject的一個實體。它知道該如何去驗證subject，就像上面的例子，DOL知道如何根據檔案庫裡的照片和顧客本人的臉去做做比較；它知道顧客的事兒，就像DOL知道它地區裡每個司機的出生日期。IP是一個抽象的角色，但它需要具體的組件：目錄，使用者系統資訊庫，以及身分識別驗證系統，這些都是IP用來履行其職責的部分例子。我們假設subject有都多種標準途徑來用IP進行身分識別驗證以及接收返回的必要使用者資訊（如上例的出生日期）。我們就將這些使用者資訊稱為聲明（claims）。

聲明這個詞終於千呼萬喚始出來了。聲明是一個實體對subject的陳述。這個陳述可以是與subject關聯的任何東西，無論是諸如出生日期這樣的屬性還是這個subject屬於某個特定的安全性群組。聲明和簡單的屬性不一樣的地方是聲明通常是和發行它的實體相關聯的。這是一個很重要的區別：它提供了一個標準，讓你自己決定是否去信任這個subject。回想一下上面的例子，印在駕照上的日期與隨便在某張邊條紙上寫得很潦草的日期，電影院員工信任的是前者而不是後者。

描述了抽象後的過程，接下來對這個過程詳細解釋一下：

1、主體（subject）想要通過某種途徑（瀏覽器，富用戶端等等）去訪問RP應用程式。主體先去瞭解RP的策略。得知RP信任哪個標識，需要哪種聲明，以及要用哪個安全性通訊協定。

2、主體選擇其中一個RP信任的IP，並檢測其策略，得知要用什麼安全性通訊協定。然後發送請求到IP並發行一個能匹配RP需求的令牌。這個過程和去DOL請求一個含有出生日期的檔案是一樣的。主體需要提供一些證明來讓IP進行辨識。要使用的協議詳情在IP的策略裡進行描述。

3、IP 處理該請求；如果請求合乎要求，它去擷取需要的聲明值，以安全性權杖的形式發送回給主體。

4、主體從IP那接收到安全性權杖，並將它連同最開始的請求一起發送給RP程式。

5、 RP
程式檢查傳入的令牌並驗證它是否符合所有的要求（是否從受信任的IP來的，格式是否正確，是否被篡改過，是否包含正確的聲明集，等等）。如果所有東西都合乎要求，RP就准許主體進行訪問。

好，瞭解了基於聲明的身份標識基本流程之後，我們再來看看WIF是如何工作的。

示範了WIF為ASP.NET程式處理身分識別驗證的簡要過程。

1、WIF 坐鎮應用程式的前端，位於ASP.NET管線中，當未驗證通過的使用者請求頁面時，WIF將瀏覽器跳轉到標識提供（IP）頁面。

2、這裡IP對使用者進行身分識別驗證，不管用什麼方法（可能顯示一個使用者民和密碼的頁面，可能用Kerberos，或者其它方法）。然後產生一個令牌，與所需的聲明一起發送回去。

3、瀏覽器將從IP那裡得到的令牌post給應用程式，WIF再次截獲該請求。

4、如果令牌滿足應用程式的要求（也就是，來自於正確的IP，包含正確的聲明，等等），使用者就被認為是驗證通過了。WIF然後放置一個cookie，並建立起一個會話。

5、傳入的令牌裡的聲明在程式裡用代碼就可以對其進行使用了，此時控制權將交給應用程式。

只要會話cookie有效，隨後的請求就不需要再走一遍這個流程，因為使用者已經被認為是通過了身分識別驗證了。

WIF用到的協議時WS-Federation協議，主要有兩個HTTP模組來處理這些事情：WSFederationAuthenticationModule(WSFAM)和 SessionAuthenticationModule 。

在應用程式中使用WIF歸結為以下三點：

1、配置應用程式以使WIF的HTTP模組坐鎮ASP.NET管線的前端。

2、配置WIF模組以使它們引用目標IP，使用正確的協議，保護應用程式的計劃資源，以及執行所需的應用程式策略。

3、在需要應用程式邏輯的時候，從應用程式裡訪問聲明的值，在需要使用者識別屬性的場合對其進行處理。

IClaimsIdentity  和 IClaimsPrincipal

WIF 提供了兩個IIdentity和IPricipal的擴充：分別是 IClaimsIdentity 和 IClaimsPrincipal ，它們是用來在WIF管線裡處理聲明的。它們的執行個體存在於ASP.NET程式裡的HttpContext.Current.User屬性中。你可以像平常的IIdentity和IPrincipal編程模型那樣來使用它們，或者把它們轉換成正確的執行個體並利用其新的功能。

IClaimsIdentity定義如下：

public interface IClaimsPrincipal : IPrincipal  {     // ...      // Properties     ClaimsIdentityCollection Identities { get; }  }

由於IClaimsPrincipal是IPrincipal的一個擴充，所有的通常功能（如IsInRole）都是支援的。

唯一值得注意的地方是Identities集合，實際上是一組IClaimsIdentity的值。來看看IClaimsIdentity的定義：

public interface IClaimsIdentity : IIdentity {     // ...       ClaimCollection Claims { get; }  }

這裡我省去了這個介面的大部分成員，只留了這個最重要的，也就是與目前使用者相關的一組聲明。那麼聲明是長什麼樣的呢：

public class Claim  {     // ...     // Properties     public virtual string ClaimType { get; }     public virtual string Issuer { get; }      public virtual IClaimsIdentity Subject { get; }      public virtual string Value { get; } }

我這裡再次省去了其它成員。列出來的這些屬性基本看名字就知道是幹什麼用的了：

■  ClaimType   表示聲明的類型：出生日期，角色，和群組成員資格，這些都是很好的例子。WIF帶有很多代表宣告類型名稱的常量；然而，如果需要的話，你可以很容易地定義自己的類型。典型的宣告類型是以URI來表示。
■  Value  很明顯了，就是指定聲明的值。雖然可以用其它CLR類型來表示，但通常都是一個字串。（比如出生日期）

■  Issuer   指示發行當前聲明的IP名稱。

■  Subject  表示當前的Claim屬於哪個 IClaimsIdentity，表示聲明引用的是哪個主體的標識。

我們來舉一個很簡單的例子。假如你的程式已經配置好了WIF來使用基於聲明的身份標識。身分識別驗證在會話的剛一開始就發生了，所以在執行過程中你都可以假設使用者已經通過了身分識別驗證。在你代碼裡的某個特定點上，你需要向你的使用者發送一封e-mail。因此你需要擷取她的e-mail地址。在WIF裡就可以這麼寫：

IClaimsIdentity identity = Thread.CurrentPrincipal.Identity as IClaimsIdentity; string Email = (from c in identity.Claims               where c.ClaimType == System.IdentityModel.Claims.ClaimTypes.Email               select c.Value).SingleOrDefault();

第一行代碼從當前線程裡擷取當前的IClaimsIdentity，第二行代碼用LINQ從當前聲明集合裡擷取e-mail地址。查詢條件很直觀：查詢所有的聲明，看看哪個類型是Email宣告類型，並返回第一個找到的結果。上面示範的代碼沒有指示驗證使用者用的是哪種協議或者認證類型。這就意味著你可以隨便在驗證身份的代碼裡做任何修改，而這裡的代碼不需要做任何改變。

總結

我們這次講了基於聲明的身份標識以及WIF的基本工作原理，在接下來的文章中，我們將利用WIF的這些美妙特性，來構建我們的單點登入實現。