摘要
通過本文你將瞭解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，實現自己的使用者和角色管理。