這裡使用的例子和前提條件可以參考以前的一篇文章《asp.net實現匿名訪問控制》，裡面使用的forms身份驗證有個缺點，如果能將使用者的驗證上公升到基於角色的驗證即可減少很多麻煩，它只會建立乙個空的genericprincipal物件，僅包含初始化過的 formsidentity 物件。如果要在應用程式中建立乙個管理部分，並想僅限於管理員使用者訪問，那麼必須拒絕每個使用者訪問，然後逐個新增管理員使用者。
要想使用基於角色的身份驗證，必須定製該過程。在介紹基於角色的安全的基礎結構和它的整個體系結構時，我們已經看到各種身份驗證的模組實際上都利用我們能夠使用的相同事件，特別是可以在 global.asax 檔案中給處理程式附加乙個 authenticaterequest 事件。
對於自定義身份驗證的實現，首先使用 genericprincipal 和 genericidentity 物件，這兩個物件可以為我們提供合理和簡單的實現。萬一它們不夠用，我們還可以繼承和擴充套件它們，甚至可以直接在自定義類中實現 iprincipal 和 iidentity 介面。
主要處理事件是 authenticaterequest 事件，在該事件處理程式中，可以先執行一些操作，例如驗證使用者的使用者名稱和密碼（與資料庫做比對），然後將 context.user 的屬性設定成自定義的主體和身份物件。與任何其他的身份驗證方案一樣，該安全環境也將通過頁、使用者控制項、後台編碼頁來跟隨使用者。只要執行了**，我們都可以訪問這些物件。
為了定製身份驗證，需要在某—點擷取該過程。在這種情況下，我們將把**保留在它所在的login.aspx頁中不動，讓forms身份驗證模組執行所有目前它正在進行的工作，直到到達某一特定點。再次看一看應用程式中乙個典型請求的步驟，並注意在什麼地方重寫該預設行為：
(1) 使用者請求 default.aspx——要進入應用程式的初始請求。
(3) 重定向產生對另一頁的請求，這次是login.aspx頁。
(5) 使用者輸入憑證並提交——向自身提交該窗體實際上是再次發出乙個新的請求。
(7) **按照資料庫進行檢查，返回ok——模組儲存具有身份驗證的cookie和userid，並重新定向到returnurl(returnurl)。
(8) 作為重新定位的結果，重新請求 default.aspx 頁。這次，已設定了身份驗證cookie。
從上面的順序可以看到，在最後的authenticaterequest中，isauthenticated屬性第一次返回true。從現在開始，這是發給身份驗證請求的惟一響應，因為身份驗證cookie將會出現，並且forms身份驗證模組將根據它恢復userid。實際上我們是在forms身份驗證模組處理cookie之後定製該身份驗證機制的。
獎我們要訪問的頁稱為受限制頁。它可以是應用程式中任何受保護的資源。
使用 formsauthentication.redirectfromloginpage()方法之後，實際上再次請求了受限制的頁——但是這次設定了安全令牌。這時可以重寫 forms 身份驗證實現的預設行為，可以將 context.user 的屬性設定成乙個能夠更好的表示我們需要的物件。該物件是包含與當前使用者相關聯的角色的 genericprincipal 物件。
過程是這樣的：
修改global.asax檔案。
首先引入我們要使用的命名空間
using system.security.principal;
using system.configuration;
if((context.user != null) && (context.user.identity.isauthenticated))
如果傳遞isauthenticated檢查，這就意味著 forms 身份驗證已經完成了工作，userid放置在了通常我們能夠發現的地方：在context.user.identity.name屬性中。這是在login.aspx頁中已經完成的工作。
genericprincipal建構函式接收乙個身份和包含所屬角色的乙個字串陣列。我們重新使用 forms 身份驗證所建立的身份，它一直附在我們使用的context.user.identity屬性上，因為我們不需要對它做什麼改變
genericprincipal ppal;
ppal = new genericprincipal(context.user.identity,roles);
最後，將新建立的主體附在context.user屬性上
context.user = ppal;
this.whlk_manageuser.visible = user.isinrole("admin");
user是page物件的乙個提供context.user的簡化形式的屬性，並且它的isinrole()方法允許我們檢查它是否屬於乙個特定角色。
我們有選擇性地在頁中使用自定義的、角色識別的新主體來顯示資訊。但是，僅僅隱藏或顯示鏈結是不夠的：如果非管理員使用者知道管理頁的位置和名稱，那麼他們就可以在瀏覽器的位址列中輸入位址和訪問應該限制的資源！為了解決該問題，我們將在限制訪問的資料夾(例如：admin資料夾)中新增乙個配置檔案(web.config檔案)，以保護該資料夾中所有檔案的安全。
<?xml version="1.0" encoding="utf-8" ?>
現在作為非管理員使用者進行登陸，試著在瀏覽器的位址列中直接輸入url來看看會出現什麼情況——您應該被重定向到登入頁。所有這些檢查都會自動進行，重新定位到登入頁是有道理的，因為無需角色的使用者甚至可能是乙個未驗證的使用者。只有屬於管理員角色的使用者才能夠看到我們構建的管理頁，無論他們如何試圖訪問它
Forms基於窗體身份驗證
forms 身份驗證通常指這樣乙個系統，在該系統中使用 http 客戶端重定向將未經身份驗證的請求重定向到 html 窗體。如果應用程式需要在登入時通過 html 窗體收集自己的使用者憑據，那麼選擇 forms 身份驗證就很好。使用者提供憑據並提交該窗體。如果應用程式對請求進行身份驗證，系統會發出乙...
基於token的身份驗證
token相當於是乙個令牌，在使用者登入的時候由伺服器端生成 基於使用者名稱 時間戳 過期時間 發行者等資訊進行簽名 然後發放給客戶端，客戶端將令牌儲存，在以後需要登入驗證的請求中都需要將令牌傳送到伺服器端進行驗證，如果驗證成功，則返回資料。目前很多大型 都在使用基於token的驗證方式 githu...
基於窗體的身份驗證
基於窗體的身份驗證是一項 asp.net 身份驗證服務，它使應用程式能夠提供自己的登入使用者介面並進行自己的憑據驗證。asp.net 對使用者進行身份驗證，將未經身份驗證的使用者重定向到登入頁，並執行所有必要的 cookie 管理。這種身份驗證是許多 使用的流行方法。應用程式必須配置為使用基於窗體的...