使用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 IdentityFoundation (之前稱為 “Geneva” Framework)，來自于微軟新的基于聲明訪問策略的核心部分。可以參考Identity Management in Active Directory來獲取更多關于ADFS和CardSpace組件的信息。

基于聲明的標識模型

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