ASP.NET 安全性資料流程
更新：2007 年 11 月
您可以用數種方式設計 ASP.NET 應用程式的安全性。這個主題會說明兩個通用案例的安全性資料流程：模擬和使用 Cookie 的表單驗證 (Authentication)。
案例 1：模擬
這個模擬案例會使用 Microsoft Internet Information Services (IIS) 驗證和 Microsoft Windows 檔案存取安全性，將 ASP.NET 應用程式本身的安全性程式設計工作減到最少。下圖為案例的資料流程。
模擬
.gif)
圖例中顯示以下的事件順序：
網路用戶端要求進入 IIS。
IIS 使用基本、摘要式或 Windows 整合式安全性 (NTLM 或 Kerberos) 驗證用戶端。
如果驗證過用戶端，則 IIS 會將驗證過的要求傳送給 ASP.NET。
ASP.NET 應用程式會使用 IIS 傳送的 Access Token 來模擬用戶端身分，然後依據 NTFS 檔案的使用權限授與資源存取權。ASP.NET 應用程式只需要驗證 ASP.NET 組態檔中的模擬是設為 true ，而不需要任何的 ASP.NET 安全性程式碼。
如果未啟用模擬，則該應用程式會執行 ASP.NET 處理序識別 (Identity)。若是 Microsoft Windows 2000 Server 和 Windows XP Professional，預設識別是名為 ASPNET 的本機帳戶，是在安裝 ASP.NET 時自動建立的。若是 Microsoft Windows Server 2003，則預設識別是 IIS 應用程式之應用程式集區的識別 (預設是 NETWORK SERVICE 帳戶)。
.gif "注意事項")
注意事項：如果未啟用模擬，並想要限制特定使用者或一組使用者的存取權 (例如使用表單驗證進行驗證的使用者)，則必須使用一些其他授權方法 (例如 URL 授權)。如需 URL 授權的詳細資訊，請參閱 ASP.NET 授權。
如需在 ASP.NET 應用程式中使用模擬的詳細資訊，請參閱 ASP.NET 模擬和使用 IIS 驗證和 ASP.NET 模擬。
授與存取權後，ASP.NET 應用程式會透過 IIS 傳回要求的資源。
案例 2 - 表單驗證
在表單驗證案例中，應用程式會收集認證 (例如直接來自使用者的名稱和密碼)，並自行判斷它們的真實性。應用程式不會使用 IIS 驗證，但 IIS 驗證設定會影響表單驗證。因此，使用表單驗證時，會啟用 IIS 中的匿名存取。否則，如果使用者未通過 IIS 驗證，他們就無法到達您的應用程式，將使用者名稱和密碼提供給表單驗證。
下圖將顯示這個案例的資料流程。
Form 驗證
.gif)
圖例中顯示以下的事件順序：
使用者產生對受保護資源的要求。
IIS 會接收該要求，而因為已啟用 IIS 匿名存取，所以 IIS 不會執行任何使用者驗證，並會將要求傳送給 ASP.NET 應用程式。
因為 ASP.NET 驗證模式是設定為表單，所以 ASP.NET 應用程式會檢查表單驗證票證 (特定 Cookie) 的要求。如果要求中未附有任何驗證票證，則 ASP.NET 會將要求重新導向至應用程式之組態檔中所指定的登入網頁。
在登入網頁上，使用者需要輸入必要的認證 (通常為名稱和密碼)。應用程式程式碼會檢查認證，以確認它們的確實性。如果已驗證過認證，則應用程式程式碼會將驗證票證附加至代表使用者認證的回應中 (不含密碼)。如果驗證失敗，會傳回具有拒絕存取訊息的回應，或者再次顯示登入表單。
發出的驗證票證是隨附於 ASP.NET 應用程式的後續要求中。ASP.NET 會使用訊息驗證檢查 (MAC) 檢查票證的有效性。
如果已驗證過使用者，則 ASP.NET 會檢查授權，且允許存取原始要求的資源、將要求重新導向至其他網頁，或是將要求重新導向至自訂授權模組，在這個模組中，會測試認證授權，以存取保護的資源。如果授權失敗，ASP.NET 會將使用者重新導向至登入網頁。
如果使用者已取得授權，即可存取受保護的資源；或應用程式可能會依應用程式的設計方式，在對受保護資源授權存取之前，要求進行其他的認證測試。
注意事項：表單驗證和授權檢查只適用於驗證和授權組態項目所保護的資源。使用存取控制清單 (ACL) 保護的 Windows 資源存取權，是根據 ASP.NET 應用程式的目前 Windows 識別來檢查的。如需詳細資訊，請參閱 ASP.NET 模擬。