（轉）進行ASP.NET Web安全驗證方法

身份驗證和授權

ASP.NET 與 IIS 一起使用以支援身份驗證，并使用基本、簡要和 Windows 身份驗證。ASP.NET 支援 Microsoft Passport 身份驗證服務，該服務提供單一登入服務和對使用者配置檔案服務的支援。ASP.NET 還為要使用基于窗體的身份驗證的應用程式提供可靠的服務。基于窗體的身份驗證使用 Cookie 鑒别使用者的身份，并允許應用程式執行自己的憑據驗證。

認識到 ASP.NET 身份驗證服務取決于 IIS 提供的身份驗證服務很重要。例如，若要在 IIS 應用程式中使用基本身份驗證，必須使用 Internet 服務管理器工具為應用程式配置基本身份驗證的使用。

ASP.NET 提供兩類授權服務：

根據 ACL 或資源權限進行檢查，以确定已經過驗證的使用者帳戶能否通路資源。

URL 授權，它授權 Web 空間各部分的辨別。

為闡釋差異，請考慮這樣一個方案，在該方案中應用程式被配置為允許使用 IUSR_MYMACHINE 帳戶進行匿名通路。在授權對 ASP.NET 頁（如“/default.aspx”）的請求後，根據 ACL 檢查該檔案（例如“c:inetpubwwwrootdefault.aspx”）以确定 IUSR_MYMACHINE 帳戶是否具有讀取該檔案的權限。如果有，則授權通路。檔案授權自動執行。

對于 URL 授權，根據為 ASP.NET 應用程式計算的配置資料對匿名使用者進行檢查。如果允許通路請求的 URL，則授權該請求。在這種情況下，ASP.NET 檢查匿名使用者是否具有對 /Default.aspx 的通路權（即檢查根據的是 URL 本身而不是 URL 最終解析到的檔案）。

可能看起來差異很小，但它使應用程式能夠使用像基于窗體的身份驗證或護照身份驗證（在此身份驗證中使用者與計算機或域帳戶并不對應）這樣的身份驗證方案。此外，它還啟用對虛拟資源的授權，這類資源沒有實體檔案作為基礎。例如，應用程式可選擇将以 .stk 結尾的檔案的所有請求映射到某一處理程式，該處理程式基于查詢字元串中存在的變量提供常用引号。在這種情況下，不存在執行 ACL 檢查所依據的實體 .stk，是以 URL 授權用于控制對虛拟資源的通路。

檔案授權的執行依據的始終是由 IIS 提供的經過身份驗證的帳戶。如果允許匿名通路，則該帳戶是經過配置的匿名帳戶。否則，它使用 NT 帳戶。這與 ASP 的工作方式完全相同。

在“資料總管”屬性頁中使用“安全”頁籤為給定的檔案或目錄設定檔案 ACL。URL 授權被配置為 ASP.NET 架構應用程式的一部分，并在授權使用者和角色中有完整的描述。

若要激活 ASP.NET 身份驗證服務，必須在應用程式的配置檔案中配置 <authentication> 元素。該元素可具有下表中列出的任何值。

Value 說明

無 沒有 ASP.NET 身份驗證服務是活動的。注意，IIS 身份驗證服務仍可以存在。

Windows ASP.NET 身份驗證服務将 WindowsPrincipal (System.Security.Principal.WindowsPrincipal) 附加到目前請求以啟用對 NT 使用者或組的授權。

窗體 ASP.NET 身份驗證服務管理 Cookie 并将未經身份驗證的使用者重定向到登入頁。它通常與 IIS 選項一起使用以允許匿名通路應用程式。

護照 ASP.NET 身份驗證服務為護照 SDK（必須安裝在計算機上）提供的服務提供了一個友善的包裝。

例如，下列配置檔案為應用程式啟用基于窗體 (Cookie) 的身份驗證：

<configuration>

<system.web>

<authentication mode="Forms"/>

</system.web>

</configuration>