在該方案中，應用程序使用 ASP.NET Forms 身份驗證，該過程可使應用程序收集直接來自客戶端請求者的憑據（如名稱和密碼），并對其可靠性做出自己的判斷。雖然應用程序并不使用 IIS 身份驗證，但 IIS 身份驗證設置對于 ASP.NET Forms 驗證過程非常重要。除非您決定拒絕所有不符合已啟用的 IIS 身份驗證方法標準的請求，否則必須啟用 IIS“匿名訪問”設置。
注意 如果沒有啟用 IIS“匿名訪問”設置，不符合 IIS 身份驗證標準的請求將被拒絕而且永遠不會到達 ASP.NET 應用程序。
該方案中的數據流如下圖所示。
該插圖顯示了以下的事件順序：
- 客戶端生成一個對受保護資源的請求。
- IIS 接收到該請求，如果該請求者經過 IIS 身份驗證，或啟用了 IIS“匿名訪問”，則請求將傳遞到 ASP.NET 應用程序。在這種情況下，因為 ASP.NET 應用程序中的身份驗證模式設置為 Forms，所以沒有使用 IIS 身份驗證。
- 如果沒有 Cookie 附加到該請求，ASP.NET 將該請求重定向到登錄頁面，其頁面路徑保存在應用程序的配置文件中。在登錄頁面上，客戶端輸入必需的憑據（通常是名稱和密碼）。
- 應用程序代碼檢查憑據以確認其可靠性，通常在事件處理程序中。如果憑據通過了身份驗證，則應用程序代碼將附加上包含用戶名稱（但沒有密碼）的票據，例如 Cookie。如果沒有通過身份驗證，該請求通常返回“訪問拒絕”信息或再次顯示登錄頁面。
- 應用程序發出票據以后，ASP.NET 會使用消息身份驗證檢查來檢查票據的有效性。應用程序不需要 *.config 文件中的憑據。實際上，ASP.NET 在發出 Cookie 后并不檢查憑據，即使它們存在。
- 如果用戶通過了身份驗證，ASP.NET 會檢查授權，然后允許訪問最初所請求的、受保護的資源，或將請求重定向到其他頁面上，這取決于應用程序的設計。它也可以將請求定向到自定義的授權模塊上，在該模塊中將檢查憑據，以用于對所訪問的受保護資源進行授權。如果沒有通過授權，ASP.NET 會始終重定向到登錄頁面。
- 如果用戶已被授權，則允許對受保護資源的訪問；或應用程序在對受保護資源授權以前可能要求附加的憑據驗證，這取決于應用程序的設計。