ASP.NET Identity 初識Identity

摘要

通過本文你將瞭解ASP.NET身份驗證機制，表單認證的基本流程，ASP.NET Membership的一些弊端以及ASP.NET Identity的主要優勢。

目錄

• 身份驗證（Authentication）和授權（Authorization）
• ASP.NET身份驗證方式
• 理解表單驗證流程
• 認識ASP.NET Membership
• 擁抱ASP.NET Identity
• ASP.NET Identity主要組成部分
• 總結

身份驗證（Authentication）和授權（Authorization）

我們先來思考一個問題：如何構建安全的WEB應用？

一直以來，這都是比較熱門的話題。不幸的是，目前還沒有一種萬能方法，來保證您的WEB應用是絕對安全的。不管是系統本身的漏洞，還是其他外來的攻擊，我們每天都飽受着安全問題的煎熬。

其實，我們也無需沮喪和糾結。既然，我們不能阻止攻擊，但是可以提前預防，儘量將損失減到最小，不是嗎？

目前，有許多適用於ASP.NET應用的安全原則，比如深度防禦、不信任任何輸入數據、關閉不必要的功能等等。但是，最基本的、最重要的原則還是身份驗證（Authentication）和授權（Authorization）。

初次看到這兩個概念，也許大家很容易犯迷糊。因爲，Authentication和Authorization確實長得很像。其實，它們僅僅外表很像而已，內在卻大不相同。

驗證（Authentication）

驗證就是鑑定應用程序訪問者身份的過程。驗證回答了以下問題：當前訪問的用戶是誰？這個用戶是否有效？在日常生活中，身份驗證並不罕見。比如，通過檢查對方的證件，我們一般可以確信對方的身份。

授權（Authorization）

授權是決定驗證通過的用戶應該擁有何種級別的訪問安全資源的權限。資源可以是IIS上的頁面文件、媒體文件（.jpeg）、壓縮文件（.zip）等等。

下面我們簡單的描述驗證和授權的過程。

ASP.NET身份驗證方式

安全問題一直是ASP.NET的關注點。其中，Windows驗證和表單驗證（Forms Authentication）就是ASP.NET兩種主要的安全機制。

Windows驗證：一般用於局域網應用。使用Windows驗證時，用戶的Windows安全令牌在用戶訪問整個網站期間使用HTTP請求，進行消息發送。應用程序會使用這個令牌在本地（或者域）裏驗證用戶賬號的有效性，也會評估用戶所在角色所具備的權限。當用戶驗證失敗或者未授權時，瀏覽器就會定向到特定的頁面讓用戶輸入自己的安全憑證（用戶名和密碼）。

Forms驗證：Windows驗證的侷限性非常明顯，一旦用戶有超出本地域控制器範圍的外網用戶訪問網站，就會出現問題。ASP.NET表單驗證（Forms Authentication）很好的彌補了這一缺陷。使用表單驗證，ASP.NET需要驗證加密的HTTP cookie或者查詢字符串來識別用戶的所有請求。cookie與ASP.NET會話機制（session）的關係密切，在會話超時或者用戶關閉瀏覽器之後，會話和cookie就會失效，用戶需要重新登錄網站建立新的會話。

理解表單認證流程

第一步 在頁面登錄框輸入賬號和密碼。

第二步 檢查用戶是否有效。可以從配置文件、SQL Server數據庫或者其他外部數據源中查找。

第三步 如果用戶有效，則在客戶端生成一個cookie文件。cookie文件標識用戶已經驗證通過，當你訪問網站其他資源時，不需要重新驗證。

認識ASP.NET Membership

使用表單認證能解決基本的身份驗證問題。但是，大部分應用程序還包含角色和用戶管理以及權限信息的存儲問題。因此，我們不得不做下面這些事情：

• 創建用戶和角色表。
• 編寫訪問數據表的代碼。
• 提供用戶和密碼驗證的方法。

幾乎每一個應用程序，我們都重複着做上面類似的事情。當微軟發現這一問題後，在ASP.NET 2.0引入了Membership的重磅級技術方案。ASP.NET Membership很好的解決了WEB應用程序在成員資格方面的常見需求，這些需求包括表單身份驗證，存儲用戶名、密碼和用戶資料信息 （profile）等。

在很長的一段時間內，Membership極大地簡化了應用程序的編寫。然而，我們的需求越來越多，ASP.NET Membership自身設計的缺陷，難以適應這種變化。

• 數據庫架構受限於SQL Server。對其他數據庫很難兼容。

• 生硬的表存儲結構。如果需要添加額外的用戶資料信息，需要存儲在其他表，使得這些信息難以訪問（除非通過 Profile Provider API）。

• 系統僅依據關係數據庫設計。當然，你也可以寫一個面向非關係型數據庫的Provider（例如 Windows Azure 存儲表），但是不得不寫大量的代碼，來解決兼容問題。

• 不能使用OWIN。由於登錄、註銷功能基於表單認證，第三方賬號的接入顯得比較困難。

OWIN （Open Web Interface for .NET）:

OWIN 是一種定義 Web 服務器和應用程序組件之間的交互的規範 。這一規範的目的是發展一個廣闊且充滿活力的、基於 Microsoft .NET Framework 的 Web 服務器和應用程序組件生態系統。

Katana 是開源的的OWIN框架，主要用於微軟.NET應用程序。Katana 2.0 將隨 Visual Studio 2013 一起發佈。 新版本有兩個值得關注的方面：

• 爲自託管提供核心基礎結構組件。
• 提供了一套豐富的驗證中間件（包括 Facebook、Google、Twitter 和 Microsoft Account 這樣的社交提供商）以及適用於 Windows Azure Active Directory、cookie 和聯合身份驗證的提供程序。

更多信息參考 http://owin.org/

擁抱ASP.NET Identity

鑑於ASP.NET Membership的弊端，微軟又開發一套新的安全框架ASP.NET Identity。ASP.NET Identity具有以下優勢：

圖 ASP.NET Identity基本功能

統一的框架

可以輕鬆地整合到 ASP.NET 各種框架以及程序上。例如，ASP.NET MVC, Web Forms, Web Pages, Web API 和 SignalR等。

自定義用戶信息

可以很方便的擴展用戶信息。比如，添加用戶的生日，年齡等。

靈活的角色管理
ASP.NET Identity 中的角色提供程序讓你可以基於角色來限制對應用程序某個部分的訪問。你可以很容易地創建諸如 “Admin” 之類的角色，並將用戶加入其中。

數據持久性以及兼容性

默認情況下，ASP.NET Identity 系統將所有的數據存儲在SQL Server數據庫中，並且使用 Entity Framework Code First 實現數據庫的管理。

當然，對其他存儲介質也有很好的支持。例如 SharePoint, Windows Azure 存儲表服務, NoSQL 數據庫等等。

單元測試能力

ASP.NET Identity 使得 Web 應用程序能夠更好地進行單元測試。

OWIN 集成

ASP.NET 驗證（Authentication）基於 OWIN 中間件，可以在任何 OWIN 的宿主上使用。ASP.NET Identity 不依賴於System.Web，完全兼容 OWIN 框架，可以被用在任何由OWIN 承載的應用程序。

NuGet 包

ASP.NET Identity 作爲一個 NuGet 包進行發佈，並且在 Visual Studio 2013 中作爲 ASP.NET MVC, Web Forms 和 Web API 項目模板的一部分提供。你也可以從 NuGet 庫中下載到該 NuGet 包。
這種發佈方式使得 ASP.NET 團隊能夠爲了添加新功能或者進行 BUG 修復更好的進行迭代，更加敏捷的進行發佈給開發人員。

ASP.NET Identity主要組成部分

圖 ASP.NET Identity基本組成部分

ASP.NET Identity主要包括核心功能模塊、EntityFramework模塊以及OWIN模塊。具體如下：

Microsoft.AspNet.Identity.Core

　　核心庫，包含Identity的主要功能。

Microsoft.AspNet.Identity.EntityFramework
　　主要包括ASP.NET Identity 的EF 部分的實現。

Microsoft.AspNet.Identity.OWIN
　　ASP.NET Identity對OWIN 的支持。

總結

本文首先介紹了一些安全機制，然後引申到ASP.NET Membership，最後強調了ASP.NET Identity的優勢。相信本文讓大家對ASP.NET Identity有一個基本的瞭解，後續我將介紹如何擴展ASP.NET Identity，實現自己的用戶和角色管理。