ASP.NET Identity入門系列教程（一）初識Identity

時間 2019-11-07

標籤 asp.net asp identity 入門系列教程欄目 ASP 简体版

原文原文鏈接

摘要

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

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

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

一直以來，這都是比較熱門的話題。不幸的是，目前尚未一種萬能方法，來保證您的WEB應用是絕對安全的。不論是系統自己的漏洞，仍是其餘外來的攻擊，咱們天天都飽受着安全問題的煎熬。安全

其實，咱們也無需沮喪和糾結。既然，咱們不能阻止攻擊，可是能夠提早預防，儘可能將損失減到最小，不是嗎？服務器

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

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

驗證（Authentication）架構

驗證就是鑑定應用程序訪問者身份的過程。驗證回答瞭如下問題：當前訪問的用戶是誰？這個用戶是否有效？在平常生活中，身份驗證並不罕見。好比，經過檢查對方的證件，咱們通常能夠確信對方的身份。框架

受權（Authorization）數據庫設計

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

下面咱們簡單的描述驗證和受權的過程。

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 修復更好的進行迭代，更加敏捷的進行發佈給開發人員。