大致分為如下幾種：

1.活動目錄的客戶端證書（這個很可能是收費的），不常用，不細說。

2.ASP.NET模擬（MSDN：如果要在 ASP.NET 應用程序的非默認安全上下文中運行 ASP.NET 應用程序，請使用 ASP.NET 模擬。），機器人說的我聽不懂。

3.Form身份驗證：這個用的很多，后面會細說。

4.windows身份驗證：基于windows操作系統的用戶或者域用戶的身份驗證。

5.基本身份驗證：其實也是基于windows操作系統的賬戶驗證的。

6.匿名身份驗證：誰都可以訪問，其內部也是通過指定一個特定的windows系統的user賬戶來訪問的。

7.摘要身份驗證：使用 Windows 域控制器對請求訪問 Web 服務器內容的用戶進行身份驗證。

再來看看經典的 IIS 6的截圖：

 注：.NET Passport 可以理解為微軟對“單點登錄”的一種實現方案，這里不細說。在“Open API”  "SOA"  “云計算”大行其道的今天，作為一個web程序員，如果你還沒聽說過“單點登錄”，請自行購買開往福州方向的動車票。

先在IIS 7上測試一下基本身份驗證：

首先把其他的身份驗證方式全部禁用掉，然后僅僅啟用“基本身份驗證”。有圖有真相：

然后打開IE、FireFox、chrome等瀏覽器，敲入localhost，等待打開IIS上的默認網站。你會發現，瀏覽器端都會彈出提示框信息，而且在不同瀏覽器上彈出框的樣式和表現形式也有所差異。（長期不用IE，發現360這個老流氓把哥的首頁給改了，還號稱”安全上網“，這明顯是篡改行為嘛。搞不懂。）

FireFox中：

如果你在彈出框中，輸入正確的windows賬戶和密碼，則可以正常的瀏覽你請求的網頁。如果你不輸或者輸錯了，等待你的將是401錯誤（401，你懂得）。

”沒有為網站啟用SSL,將通過電纜以明文的方式.....”，機器人說的話聽起來很別扭，這里，我解釋一下。

當你沒有花錢去買SSL證書（安全套接層，你可以簡單的理解為：正常http請求都是明文傳送，使用SSL后可以幫你把http報文自動加密，就算有人在互聯網上截獲了也無法解密。我們偶爾訪問有些網站的時候，看到的“https://www.xxx.com”,就極可能是基于SSL證書的形式）。至于“通過電纜以明文的方式...”，其實這句話說的很不對，首先，電纜只是一種傳輸介質，里面傳送的只是電脈沖、光信號等等，而不是網絡協議報文（學過計算機網絡的都知道）。至于說“采用明文的形式”，也不對，其實“基本身份驗證”中，是將用戶名和密碼采用了Base64編碼的，感興趣的讀者，可以用httpwatch或者Fiddler之類的工具去監視一下http請求，我這里就不做演示了 。只是由于Base 64編碼很容易反編碼，所以和明文沒啥區別。這樣一來，你會發現“基本身份驗證”方式，確實存在很多不安全因素。

在IIS 7上測試一下 windows 身份驗證：

和之前的基本身份驗證差不多，我就不再截圖演示了。如果用戶輸入正確的windows用戶名和密碼，則能夠正常訪問網站。如果輸入錯誤的，則返回的401.1（前面基本身份驗證是401.2）。值得一提的就是，記得之前有位asp.net MVP 曾告訴過我，使用windows身份驗證的時候，只能用戶在使用IE瀏覽器時候才能夠正常訪問。因為這種情況下，不是使用http報文傳輸的形式，而是瀏覽器端直接與操作系統內部交互，進行用戶名和密碼的驗證。經過證實，發現這話的后半句是對的，確實監視不到http實體內容。但不僅僅局限于IE瀏覽器，我在firefox中也能夠正常的訪問和使用。

匿名身份驗證：

所謂匿名身份驗證，其實就可以理解為“不驗證”。就是匿名用戶都可以訪問資源，沒有任何限制。通常我們的網站，都要啟用匿名方式驗證，集成windows身份驗證。不難發現，其實匿名身份驗證，也是通過windows用戶組里面的一個特定的用戶來通過驗證的，如圖所示：

最后一種，Form身份驗證：

前面所講的那些身份驗證方式，其實都和asp.net沒有直接的聯系，都是IIS 和操作系統級別的驗證方式。而Form 身份驗證，則需要asp.net提供支持。因為通常網站的身份驗證和成員管理都非常復雜，而不是通過單純的某一種驗證方式能夠實現的。對于大部分互聯網的網站而言，用戶可以訪問部分頁面，但部分頁面必須登錄后才能訪問和操作，而且不同用戶角色登錄，操作權限也不一樣。這又會涉及到很多方面的知識，而且實現方式也有很多種。