百度一下”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階段

一、匿名身份認證

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

        可以看到預設的就是匿名身份認證。這種情況下不需要任何的認證，我們就可以訪問伺服器上的內容。之所以能這麼方便的訪問伺服器的內容，是因為IIS在後臺幫我們做了很多事情。當我們安裝IIS時，安裝程式會自動創建 IUSR_ComputerName 帳戶（其中 ComputerName 是正在運行 IIS的電腦名稱），普通用戶使用瀏覽器訪問該站點時，就是直接使用這個賬號來操作伺服器。我們在開發過程中常常碰到讀寫伺服器某文件沒有許可權，這時百度一下，都會告訴你要修改IUSR_Computername用戶許可權，就是這個原因。

二、基本身份認證

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

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

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

        不過基本身份認證有個非常嚴重的安全問題，通過這種方式的用戶名和密碼都以明文形式在網路間進行發送，很容易被攔截獲取。而且要知道這個賬號可是伺服器的賬號！可以用SSL加密來解決這個問題。

三、摘要式身份認證

        摘要式身份驗證提供與基本身份驗證相同的功能，即當用戶訪問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