.NET Web的身份認證

    百度一下」asp.net身份認證「，你會獲得不少相關的資料，這些資料一般上來就會介紹諸如」Form認證「」Windows認證「等內容，而沒有給出一個完整的流程。初學者對此每每一頭霧水，我也曾經被坑過不少回，因而寫下此文，算是複習。

    現代的Windows Server系統都是基於嚴格的用戶機制的，當你想操做服務器時確定須要帳號密碼驗證的。當咱們把開發好的Web應用程序部署在服務器後，用戶經過瀏覽器訪問該站點，實際上就是該用戶經過HTTP操做這臺服務器的過程，本質上也是用戶操做服務器（至少是讀）的過程。這就產生了一個被大多數人忽略的問題：網絡用戶根本不知道服務器的帳號密碼，怎麼會有讀寫服務器的權限？答案能夠用下面一個簡單的圖給出：

              

   

         用戶發起一個請求後，受權主要經歷IIS階段和ASP.NET階段。通過IIS時會獲得系統帳號相關權限標識（或票據），使用該標識進入站點，這時asp.net運行時會把該標識轉化成.NET的一個用戶實體對象，咱們就能夠在本身的代碼中對該實體進行處理。經過一個具體的實例來認識一下，首先咱們新建一個【不進行身份認證】的MVC項目（WebForm項目亦可），爲了方便描述，就叫WebAuth吧！

        項目默認有HomeController和三個Action：Index/About/Contact。編譯生成，並把它部署到iis上，爲了方便我直接部署成http://localhost。就從這裏開始身份認證之旅吧！

IIS階段

1、匿名身份認證

        通常公司或我的開發ASP.NET的網站用的都是這種方式。好比剛剛部署的Web，咱們在IIS的功能視圖中打開身份驗證：

        能夠看到默認的就是匿名身份認證。這種狀況下不須要任何的認證，咱們就能夠訪問服務器上的內容。之因此能這麼方便的訪問服務器的內容，是由於IIS在後臺幫咱們作了不少事情。當咱們安裝IIS時，安裝程序會自動建立 IUSR_ComputerName 賬戶（其中 ComputerName 是正在運行 IIS的電腦名稱），普通用戶使用瀏覽器訪問該站點時，就是直接使用這個帳號來操做服務器。咱們在開發過程當中經常碰到讀寫服務器某文件沒有權限，這時百度一下，都會告訴你要修改IUSR_Computername用戶權限，就是這個緣由。

2、基自己份認證

        不修改任何代碼。咱們在IIS中禁用」匿名身份認證「，啓用」基自己份認證「，這時咱們再訪問項目的項目中的時，瀏覽器會彈出一個對話框要求用戶輸入本身的用戶名和密碼,以下圖：

        這個帳號必須是服務器系統的帳號，且擁有對站點根目錄讀（寫）的權限。能夠在目錄的文件夾屬性->安全性上設置。我專門添加了個帳號test，以下：

        返回瀏覽器，輸入用戶名test和設置的密碼便可訪問項目的全部頁面。在不須要複雜用戶邏輯的項目中使用該方法，能夠不用修改任何代碼實現認證。

        不過基自己份認證有個很是嚴重的安全問題，經過這種方式的用戶名和密碼都以明文形式在網絡間進行發送，很容易被攔截獲取。並且要知道這個帳號但是服務器的帳號！能夠用SSL加密來解決這個問題。

3、摘要式身份認證

        摘要式身份驗證提供與基自己份驗證相同的功能，即當用戶訪問http://localhost 時一樣彈出輸入帳號和密碼的對話框。可是這種認證方式在經過網絡發送用戶憑據方面提升了安全性。具體流程以下：

1. 客戶從運行 IIS 的服務器請求文件。
2. IIS 拒絕請求，告訴給客戶端正在使用摘要式身份驗證，併發送領域名稱。
3. Internet Explorer 提示用戶輸入憑據（用戶名和密碼）。而後，Internet Explorer 合併這些憑據和領域名稱以建立一個 MD5 哈希，並從運行 IIS 的服務器從新提交文件請求，此時發送的是 MD5 哈希。
4. 運行 IIS 的服務器接收哈希，並將客戶端的哈希發送到域控制器以進行驗證。
5. 域控制器向運行 IIS 的服務器通知驗證結果。
6. 若是客戶端已通過身份驗證，則 IIS 將請求的文檔或數據發送到客戶端。

這裏特別注意一下：什麼是Active Directory？它就是一個普通的Windows服務，經過數據庫把系統的網絡對象信息存儲起來，好比系統的帳號，用戶組，共享資源等。能夠方便使用者方便的查找和使用這些信息。

四 Windows身份認證

        同上，這種認證方式對於客戶端用戶來講和基本認證並無什麼區別，但實際上它比基本認證要複雜的多。這種方式在經過網絡發送用戶名和密碼以前，先將它們進行哈希計算。當啓用集成 Windows 身份驗證時，用戶的瀏覽器經過與 Web 服務器進行密碼交換（包括哈希）來證實其知曉密碼。集成 Windows 身份驗證是 Windows Server 2003 家族成員中使用的默認驗證方法。

        Windows 身份認證主要有兩種方式：NTLM 方式和Kerberos V5。若是在 Windows 2000 或更高版本域控制器上安裝了 Active Directory 服務，而且用戶的瀏覽器支持 Kerberos v5 驗證協議，則使用 Kerberos v5 驗證，不然使用 NTLM 驗證。這兩種方式的詳細講解可參考A大的這篇文章：http://www.cnblogs.com/artech/archive/2011/01/24/kerberos.html

asp.net階段

       上面四種是IIS服務器提供的驗證方式，當用戶經過IIS的用戶驗證後，就能夠獲得一個Windows的身份，這個身份將會被傳到咱們本身的項目WebAuth中。打開工程的Web.config文件，有一項authentication配置：

<authenticationmode="Windows"/>

        這裏的Windows和IIS裏的Windows身份認證不一樣。這裏指將IIS獲取的Windows用戶直接傳到網站中使用，能夠在index.cshtml中添加如下代碼訪問：

當前登陸狀態:@Request.IsAuthenticated<br/>
當前登陸用戶:@User.Identity.Name

        IIS使用匿名認證之外的任何帶輸入框的認證，效果以下：

        一般狀況這種方式並沒什麼卵用，絕大多數狀況咱們的IIS都只用「匿名身份認證」方式。而後在本身的站點裏開發本身的用戶邏輯，將authentication的mode設置爲forms，即咱們耳熟能詳的Form認證。

        Form認證的核心原理很簡單，用戶在請求信息中攜帶本身的身份證實（用戶名&密碼），站點驗證經過後，向用戶頒發一張證實身份的票據，客戶端經過Cookie的方式來存儲這個票據，在之後的請求中，經過在請求中附帶票據來證實身份。園子裏有位大神經過以系列的實例講的很是清楚：http://www.cnblogs.com/fish-li/archive/2012/04/15/2450571.html，微軟官方爲Form認證提供了全方位的支持與擴展----Membership及Identity！關於這兩種方式，騰飛兄在他的博客裏面講解的也很是詳細：http://www.cnblogs.com/jesse2013/p/membership.html 及 http://www.cnblogs.com/jesse2013/p/aspnet-identity-claims-based-authentication-and-owin.html