前言
在B/S系統開發中，經常需要使用“身份驗證”。因為web應用程式非常特殊，和傳統的C/S程式不同，預設情況下（不采用任何身份驗證方式和權限控制手段），當你的程式在網際網路/區域網路上公開後，任何人都能夠通路你的web應用程式的資源，這樣很難保障應用程式安全性。通俗點來說：對于大多數的内部系統、業務支撐平台等而言，使用者必須登入，否則無法通路和操作任何頁面。而對于網際網路（網站）而言，又有些差異，因為通常網站的大部分頁面和資訊都是對外公開的，隻有涉及到注冊使用者個人資訊的操作，或者網站的背景管理等才需要提示登入。（如果不做嚴格驗證，後果将很嚴重，人家一旦猜出你web目錄下面的頁面名，可以随意通路。當然，一般的開發人員是不會犯這種低智商的錯誤的）。
如何實作“身份驗證”
記得N年前我最早接觸Servlet + JSP開發的時候，有一種叫做“過濾器”（Filter）的東西，真是很神奇。有了這件神奇的東西後，我再也不需要去每個頁面判斷什麼“session”或者“cookie”了，就能把未登入使用者給彈出去（水準實作有限）。當然，在傳統webform開發中，也可以寫一個“BasePage的雞肋”，在該類中去做判斷，讓每個頁面對應的類都去實作這個"雞肋"，我看以前很多公司都是這麼幹的。
在asp.net中，其實微軟提供了一整套的完整的機制來實作“成員角色管理”。包含有：”登入控件”、“membership”、“個性化資料庫”等等。但是大多數開發人員是從來不用這些的（例如我，用微軟的asp.net三四年，還從來沒見過“登入控件”長啥樣）。在asp.net身份驗證中，主要有三四種。因為有些身份驗證的方式是依賴于IIS和windows作業系統的，是以在不同版本的作業系統和IIS上還是有些差異的。由于筆者暫時使用的是windows 7的作業系統，是以就拿IIS 7.5為例子。
首先打開IIS，然後輕按兩下右側“身份驗證”，會顯示出目前IIS支援的所有的身份驗證方式（由于我安裝IIS時候，在“安全性”那裡我是全部勾選的）。可以看到如圖：
大緻分為如下幾種：
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 可以了解為微軟對“單點登入”的一種實作方案，這裡不細說。感興趣的朋友可以參考http://baike.baidu.com/view/1182418.htm及相關資料。在“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提供支援。因為通常網站的身份驗證和成員管理都非常複雜，而不是通過單純的某一種驗證方式能夠實作的。對于大部分網際網路的網站而言，使用者可以通路部分頁面，但部分頁面必須登入後才能通路和操作，而且不同使用者角色登入，操作權限也不一樣。這又會涉及到很多方面的知識，而且實作方式也有很多種。
由于篇幅和時間有限，今天就先到此。後期我再詳細地去整理關于Form身份驗證的詳細及成員管理，權限管理方面的文章，敬請期待。
本文出自 http://www.cnblogs.com/dinglang/ , http://blog.csdn.net/dinglang_2009 ，轉載請注明出處。