|
摘要
本文討論了設計服務器應用程序時考慮安全性的重要性。Internet Information Services 和 ASP .NET 均提供了安全模型，以便您對用戶進行適當的身份驗證，并在應用程序中獲得正確的安全環境。
--------------------------------------------------------------------------------
目錄
簡介
安全性考慮
IIS 和 ASP .NET 之間的關系
身份驗證方法
Web 服務的安全性
代碼訪問安全性
通道安全性
其他信息
附錄 A
--------------------------------------------------------------------------------
簡介
不論對應用程序設計者還是開發人員，安全性都是關注的主要問題。您需要保護存儲敏感信息的應用程序，既要防止惡意攻擊，又要防止競爭對手竊取信息或知識產權。在為您的應用程序設計安全模型時，您需要從業務角度了解安全要求，以及選定的安全模型在性能、可伸縮性和部署上所具有的含義。
--------------------------------------------------------------------------------
安全性考慮
如果您在設計服務器應用程序，那么您的設計規范應包含一個解決安全問題的部分。在應用程序的功能規范中，您應當考慮以下項目并盡可能給出解決方案：
安全目標。理解您要保護的對象并確保您可以說明它。
安全風險。理解您的應用程序的弱點。您還必須理解這些弱點對業務的潛在危害程度。
身份驗證。這一過程接受用戶憑據，并根據指定的頒發機構來驗證憑據。用戶的（或者潛在的應用程序或計算機的）標識被稱為安全當事者。客戶端必須提供憑據，以便服務器驗證當事者的標識。確認標識后，應用程序就能授權當事者訪問系統資源。本文檔的下一節將講述各種標準，它們有助于您選擇恰當的身份驗證機制。
權限。這一過程確定已證實的標識是否可以訪問某一特定資源。
保護數據傳輸。在數據通過網絡時對數據進行加密，可以確保數據在傳輸過程中不被查看和修改。您必須考慮傳輸過程中需要的數據加密級別。
模擬。這一機制允許服務器進程使用客戶端的安全憑據來運行。當服務器模擬客戶端時，服務器的所有操作均使用客戶端的憑據進行。模擬不允許服務器代表客戶端訪問遠程資源。該操作需要使用代理。
代理。和模擬一樣，代理允許服務器進程使用客戶端的安全憑據來運行。但是，代理的功能更加強大，它允許服務器進程以客戶端方式來呼叫其他計算機。
操作系統安全性。它指建立適當的訪問控制列表 (Access Control List, ACL) 和網絡安全措施，以防止入侵者訪問受保護的資源。您必須為適當的資源設置適當的 ACL，從而只允許相關的當事者進行訪問。
保護物理訪問。是指將您的服務器計算機放在一個安全的房間中。您不應忽視這個基本問題。
代碼訪問安全性。它允許根據代碼的來源及代碼標識的其他特征來確定代碼的可信度。您應當了解如何創建自己的訪問許可。
--------------------------------------------------------------------------------
IIS 和 ASP .NET 之間的關系
在設計應用程序時，您應理解 Internet Information Services (IIS) 身份驗證和 Microsoft ASP .NET 安全結構之間的關系。這將允許您恰當地驗證您的用戶，并在應用程序中獲得正確的安全環境。請注意，ASP .NET 應用程序的安全配置和 IIS 的安全配置是完全獨立的，它們可以單獨使用，也可以結合使用。
IIS 在 IIS 元數據庫中維護與安全性相關的配置設置，而 ASP .NET 在 XML 配置文件中維護安全（或其他）配置設置。這一般會在安全性方面簡化應用程序的部署，但應用程序采用的安全模型則需要通過配置文件 (Web.config) 正確配置 IIS 元數據庫和您的 ASP .NET 應用程序。
圖 1 說明了 IIS 和 ASP .NET 之間的關系。
圖 1：IIS 和 ASP .NET 之間的安全性關系
ASP .NET 身份驗證提供程序和 IIS 安全性
ASP .NET 通過使用身份驗證提供程序來實現身份驗證，身份驗證提供程序是驗證憑據和實現其他安全功能（例如生成 Cookie）的代碼模塊。ASP .NET 支持以下三種身份驗證提供程序：
表單身份驗證。使用該提供程序，可以使用客戶端重定向將未通過身份驗證的請求重定向到指定的 HTML 表單。然后，用戶可以提供登錄憑據，并將表單發送回服務器。如果應用程序驗證了請求（使用應用程序特定的邏輯），ASP .NET 將發出一個 Cookie，其中包含憑據或用于重新申請客戶標識的密鑰。后續發出的請求在標頭攜帶該 Cookie，這就意味著以后不再需要身份驗證。
Passport 身份驗證。這是一個由 Microsoft 提供的集中身份驗證服務，它為參與的站點提供單一的登錄程序和成員服務。ASP .NET 與 Microsoft Passport 軟件開發包 (SDK) 相結合，為 Passport 用戶提供了類似表單身份驗證的功能。
Windows 身份驗證。該提供程序利用了 IIS 的身份驗證功能。當 IIS 完成身份驗證后，ASP .NET 使用已驗證標識的標記來授權訪問。
要在 ASP .NET 應用程序中使用某種指定的身份驗證提供程序，您必須在應用程序配置文件中創建如下項：
// web.config 文件
<authentication mode = "[Windows/Cookie/Passport/None]">
</authentication>
除身份驗證外，ASP .NET 還提供了模擬機制以建立應用程序線程的安全標記。能否獲得正確的標記取決于您是否恰當地配置了 IIS 身份驗證、ASP .NET 身份驗證提供程序和 ASP .NET 模擬設置。圖 2 顯示了 IIS 身份驗證和 ASP .NET 提供程序之間最可能的組合。
圖 2：ASP .NET 和 IIS 安全設置矩陣
使用 Windows 帳戶進行身份驗證
如果您計劃使用 Microsoft Windows NT 域控制器或 Microsoft Windows 2000 Active Directory 帳戶來進行用戶身份驗證，您應當結合使用 IIS 身份驗證和 ASP .NET Windows 提供程序（見圖 2）。使用該方法，您不必編寫任何特定身份驗證代碼。當使用該方法驗證時，ASP .NET 根據已驗證用戶在應用程序環境中構造并附加一個 Windows Principal 對象。這樣，ASP .NET 線程就能夠作為已驗證用戶運行，并可獲得用戶的組成員身份。
在某些情況下，您可能希望忽略 IIS 身份驗證，而實施自定義的解決方案。使用 ASP .NET 也可以實現這一目標。例如，您可以編寫自定義 ISAPI 過濾器，根據 Active Directory 檢查用戶憑據，并手動創建 Windows Principal 對象。除這種方法外，還有其他一些方法可以使用，但是與直接使用 .NET 提供程序相比，它們都需要編寫更多的代碼。
使用非 Windows 帳戶進行身份驗證
如果您計劃在應用層進行用戶身份驗證，并且用戶沒有 Windows 帳戶，則一般應將 IIS 配置為使用匿名驗證。在這種配置下，請考慮以下 .NET 身份驗證模塊：
無：在根本不驗證用戶時或開發自定義驗證代碼時使用。
表單：在需要為用戶提供登錄頁時使用。
Passport：在使用 Passport 服務時使用。
模擬和代理
在模擬情況下，ASP .NET 應用程序能夠使用客戶端標識以客戶端的身份有選擇地執行。模擬一般用于資源訪問控制。您應仔細考慮是否需要模擬，因為它將消耗額外的服務器資源。代理是一種比模擬更強大的形式，它允許服務器進程以客戶端的身份訪問遠程資源。
如果啟用模擬，ASP .NET 將從 IIS 收到模擬標記。與傳統的 Active Server Pages (ASP) 相比，使用 ASP .NET 將使您在 Web 應用程序中更廣泛地控制模擬。這種控制是通過在應用程序的 Web.config 文件中指定值來實現的。
在指定所需的模擬設置時，有以下三個選項：
啟用模擬。在這種情況下，ASP .NET 將模擬由 IIS 傳遞給它的標記，該標記可能是已驗證的用戶，也可能是匿名 Internet 用戶帳戶。
<identity impersonate="true"/>
啟用模擬，使用指定的特定模擬標識。在這種情況下，ASP .NET 將模擬使用配置的標識生成的標記。此時不使用客戶端標記（即使有）。
<identity impersonate="true" username="domain\user" password="pwd"/>
禁用模擬。此選項是默認設置，以便與 ASP 向后兼容。在這種情況下，ASP .NET 線程將使用應用程序輔助進程的進程標記（默認情況下為 IIS 系統帳戶）來運行，而不考慮采用的是 IIS 和 ASP .NET 身份驗證的何種組合。
<identity impersonate="false"/>
如果應用程序駐留在 UNC 共享中，ASP .NET 將一直模擬 IIS UNC 標記以訪問該共享，除非使用了配置帳戶。如果提供了顯式配置的帳戶，ASP .NET 將優先使用該帳戶。
表 1 顯示了根據三種不同的 Web.config 配置來執行請求的線程標記。請注意，IUSR_SERVER 帳戶表示已配置用于匿名訪問當前 URL 的帳戶（即，該帳戶不必是 IUSR_ 帳戶）。進程帳戶是應用程序輔助進程運行時使用的帳戶：默認情況下，該帳戶為系統帳戶，除非進行專門配置。
表 1：ASP 和 IIS 配置的 ASP 線程標記
應用程序標識
建議您使用專門配置的帳戶來運行 ASP .NET 應用程序輔助進程 (aspnet_wp.exe)，該帳戶的權限比默認系統帳戶低。主要原因有兩個。第一，如果出現安全問題，入侵者沒有管理權限。第二，它允許應用程序服務提供者 (ASP) 使用較低權限的帳戶運行應用程序，因此寄宿的應用程序不會破壞服務器計算機的完整性或執行需要管理員權限的操作。
要使用指定帳戶運行 ASP 輔助進程，需要在 \WINNT\Microsoft.NET\Framework\Version\Config 文件夾下的根配置文件 (machine.config) 中添加一個 <processModel> 元素，如下所示：
<system.web>
<processModel enable="true" username="domain\user" password="pwd"/>
</system.web>
除指定特定的用戶帳戶外，您還可以將 username 屬性設置為兩個專門識別的值“SYSTEM”和“MACHINE”之一。無論設為哪個值，密碼屬性必須設為“AutoGenerate”，因為不需要指定憑據。“SYSTEM”設置（默認）使用系統帳戶運行輔助進程，而“MACHINE”使用名稱中帶前綴 ASPNET 的特殊帳戶運行輔助進程。該帳戶與 IWAM_MACHINENAME 帳戶相同，IIS 寄放標準 ASP 應用程序時使用 IWAM_MACHINENAME 帳戶來運行 dllhost.exe 的實例。ASPNET 帳戶在 .NET 的安裝過程中創建。
如果您使用自定義帳戶，該帳戶必須具有對以下目錄的必要訪問權限。
對 %installroot%\ASP .NET 臨時文件目錄具有讀/寫訪問權限。該根目錄下的子目錄用于動態編譯輸出。
對 %temp% 目錄具有讀/寫訪問權限。在動態編譯過程中，編譯器將使用該目錄。
對應用程序目錄具有讀訪問權限。
對 %installroot% 層次結構具有讀訪問權限，以允許訪問系統程序集。
請注意，相關的 ACE 是在安裝 ASPNET 帳戶的過程中定義的。
如果您使用專門配置的進程帳戶，您應了解它對使用模擬的限制。雖然您可以繼續模擬客戶端標識，但您不能使用模擬的擴展形式（其指定的模擬帳戶已在應用程序的 Web.config 文件中定義）。這是因為該選項要求輔助進程具有 SE_TCB_NAME (“作為操作系統的一部分運行”) 權限，而權限較低的進程標識一般不具有此權限。針對每個請求的模擬仍然有效，因為 IIS 創建了登錄會話，并將模擬標記直接傳遞給輔助進程。請注意，此限制僅適用于 Windows 2000 和 Windows NT 4。Microsoft Windows XP 包含有增強功能，允許在不具有此權限的情況下生成特定的登錄會話。
詳細信息，請閱讀《.NET 框架開發人員指南》的以下章節：
ASP .NET 安全性的工作原理
ASP .NET 身份驗證
ASP .NET 配置概念
結合使用 IIS 身份驗證與 ASP .NET 模擬
有關 IIS 5.0 中身份驗證的詳細信息，請參閱文章 Internet Information Services 5.0 身份驗證方法（英文）。
--------------------------------------------------------------------------------
身份驗證方法
在 .NET Web 應用程序中可以采用各種身份驗證選項。例如，您可以選擇使用某種受支持的 IIS 身份驗證機制，或在應用程序代碼中執行身份驗證。選擇身份驗證方法時，應考慮以下部分或所有因素：
服務器和客戶端操作系統
客戶端瀏覽器類型
用戶數量、位置、用戶名以及密碼數據庫類型
部署考慮，如應用程序是基于 Internet 還是 Intranet，及其是否位于防火墻之后。
應用程序類型，如，是交互式網站還是非交互式 Web 服務
要保護的數據的敏感度
性能和可伸縮性因素
身份驗證要求。例如，您希望所有用戶均可使用應用程序；或希望限制某些區域僅供注冊用戶使用，而另一些區域“僅限管理員使用”。
確定身份驗證方法
使用附錄A中的流程圖，有助于您根據具體應用程序的要求確定最適合的身份驗證方法。要使用該流程圖，請先回答有關用戶群和部署模型性質的問題。圖的結尾處為適當的備選身份驗證方法。
檢查完流程圖后，您應研究以下小節。這些小節提供了關于各種身份驗證方法的更詳細信息，并提供進一步的指導以幫助您優化決策程序。在本節將要結束之際，您應該能夠選出一個備選身份驗證方法。
流程圖決策點解釋
用戶是否必須登錄？是否需要用戶名和密碼以訪問站點或服務？
是否需要個性化？站點是否可以不需要用戶登錄而提供個性化內容？
用戶帳戶？用戶帳戶是存儲于 Windows NT 域帳戶、Active Directory，還是其他數據存儲區，例如關系型數據庫、其他 LDAP（輕便目錄訪問協議）目錄服務或 XML 文件？
需要單一登錄還是無縫登錄？您是否希望用戶從登錄頁登錄，或需要自動進行身份驗證？例如，在自動化的企業對企業 (B2B) 交易中可能需要自動身份驗證。
您是否需要安全登錄？您的系統是否需要使黑客極難通過網絡來盜用用戶名和密碼？這個決策一般是根據站點上可用數據的敏感度來做出的。
應用程序將在 Internet 上運行嗎？應用程序是否位于防火墻之后（用戶未經過域身份驗證），或應用程序將基于 Intranet（最終用戶可能已經過域身份驗證）？
您是否需要代理安全環境？您是否需要業務組件與呼叫方標識共同運行？如果是這樣，則需要模擬。而且，如果您需要訪問系統資源（例如消息隊列、數據庫或遠程計算機中的文件系統），則需要代理級別的模擬。
服務器和客戶端是否僅運行 Windows 2000？運行環境中的計算機是同樣運行 Windows 2000，還是會有客戶端運行著其他操作系統（如 Windows 9x 和 Windows NT 4.0）？
匿名身份驗證
使用匿名身份驗證，服務器不請求客戶端向其發送用戶憑據。如果您的站點或服務可供公開使用，而您不必知道呼叫方的標識，那么這就是一個好的選擇。同時，也不會由于與支持的身份驗證機制不兼容而造成瀏覽器限制。所有用戶均可訪問配置為匿名身份驗證的站點。值得注意的是，盡管您可能已配置了 IIS 以進行匿名身份驗證，但身份驗證可能是在 ASP .NET 層進行，而這并不是真正的匿名身份驗證。本節假設 IIS 和應用程序均不要求登錄。
典型應用方案
以下情況下，您應考慮使用匿名身份驗證：
無論是對于登錄還是業務邏輯組件，您都不需要知道呼叫方的名字和/或密碼。
您所保護的信息被認為是“公有的”。
以下情況下，您不應考慮使用匿名身份驗證：
您要求使用登錄名和密碼以限制用戶群。
其他考慮
選擇匿名身份驗證時，您還應考慮以下問題。
站點中僅包含個性化內容
如果您設計的站點僅包含個性化內容，則匿名身份驗證可能是一個好選擇。例如，新聞站點可以根據用戶的郵政編碼來提供當地信息，而不需要用戶明確登錄。個性化功能可以通過使用獨立于身份驗證的 Cookie 來執行。有關 Cookie 的詳細信息，請參閱本文檔后面的 Cookie 一節。
模擬
當使用匿名身份驗證時，應用程序線程將運行為：
內部匿名 Internet 帳戶 IUSR_MACHINENAME。
在 IIS 中為匿名用戶配置的帳戶。
IIS 系統帳戶。
如果您的應用程序使用其他資源，例如 COM+ 組件、數據庫、消息隊列或 UNC 文件共享，您需要為匿名用戶啟用相應權限。如果是這樣，請考慮以下選項：
設置域控制器以包含所有 Web 和應用程序服務器。配置匿名用戶以作為域用戶運行，并具有訪問相應資源的權限。此方法中的帳戶管理是集中進行的，因此更易于管理。
如果您不在域中運行，則可以在每個 Web 和應用程序服務器中創建一個具有相同名字和密碼的用戶。由于重復帳戶的管理比較復雜，所以并不推薦這種方法。
性能
使用匿名網站而不使用 ASP .NET 模擬將帶來最佳性能，但是應用程序配置的安全性最差。
實現
要實現匿名身份驗證，應為匿名身份驗證配置 IIS 并配置適當的匿名用戶帳戶。使用 Web.config 文件配置 ASP .NET 以使用無身份驗證。
//web.config 文件
<system.web>
<authentication mode="None" />
</system.web>
基本身份驗證
當 IIS 配置為基本身份驗證時，它將指示瀏覽器通過 HTTP 發送用戶憑據。密碼和用戶名使用 Base64 編碼方法進行編碼。盡管密碼已經編碼，但由于其解密相對較容易，所以仍然是不安全的。瀏覽器將通過對話框提示用戶，然后重新發出原始匿名請求和提供的憑據（包括用戶名和密碼）。彈出式登錄對話框不一定適合您的用戶界面設計要求。大多數 Internet 瀏覽器支持基本身份驗證。
典型應用方案
以下情況下，您應考慮使用基本身份驗證：
您的用戶具有 Windows NT 域或 Active Directory 帳戶。
您需要支持多個瀏覽器類型，包括 Netscape Navigator 和所有版本的 Internet Explorer（包括 Pocket PC 和 Windows CE 平臺）。
您需要支持通過 Internet 進行身份驗證。
您需要在應用程序代碼中訪問明文密碼。
您需要支持代理。
以下情況下，您不應考慮使用基本身份驗證：
需要安全登錄且不使用安全通道，例如由安全套接字層 (SSL) 提供的通道。
您的用戶存儲在自定義數據庫中，并且沒有 Windows 帳戶。
您需要一個自定義表單作為登錄頁提供給用戶。
其他考慮
選擇基本身份驗證時，您還應考慮以下問題：
使用基本身份驗證代理
您可以使用基本身份驗證從一個計算機代理另一個（但不要超過一個）。代理會發生是因為 IIS 服務器將通過調用 Win32 API LogonUser 實現本地登錄。由于 IIS 擁有用戶的明文密碼，它可以響應遠程計算機的挑戰，允許 Web 服務器代表客戶端操作。如果您需要代理其他計算機的安全環境（超過單個躍點)，則必須本地登錄到呼叫鏈中的其他計算機。通過使用基本身份驗證能夠實現這一點，因為您可以訪問用戶的名字和明文密碼，而名字和明文密碼可以傳遞給其他應用程序（例如基于 ISAPI 或 CGI 的應用程序）。
保護基本身份驗證
值得注意的是，密碼的破譯相對容易，因此您應將基本身份驗證的使用限制在非安全或至多是半安全的應用程序中。
您可以通過與 SSL 結合來保護基本身份驗證。這將防止密碼被破譯。目前的許多 Internet 應用程序都結合使用了基本身份驗證和 SSL。
實現
要實現基本身份驗證，應在 IIS 內對其進行配置，并確保您的用戶在 Web 服務器上具有“本地登錄”權限。如果您的 ASP .NET 應用程序需要作為經過基本身份驗證的用戶來運行，請使用以下 Web.config 文件配置。
// web.config 文件
<system.web>
<authentication mode="Windows" />
</system.web>
簡要身份驗證
簡要身份驗證是 Windows 2000 和 IIS 5.0 的新功能。這種身份驗證形式能夠加密用戶的密碼信息并提供一種機制以便防止某些常見的服務器攻擊（如重放攻擊）。簡要身份驗證不像基本身份驗證那樣使用明文通過網絡發送憑據。相反，它使用一種由 RSA 開發的散列機制，稱為 MD5。（有關詳細信息，請參閱位于 http://www.ietf.org/rfc/rfc1321.txt ;的“MD5 消息簡要算法” 。）盡管它對于 Internet 來說是一個可行的身份驗證選擇，但客戶端和服務器的要求限制了它的廣泛使用。IIS 與基本身份驗證不同，而與 NTLM 和 Kerberos 類似。它不在本地登錄 Web 服務器，因此不能執行代理。
典型應用方案
以下情況下，您應考慮使用簡要身份驗證：
您的 Web 服務器運行 Windows 2000，并且您的用戶在 Active Directory 中存儲有 Windows 帳戶。
您所有的客戶端均使用 .NET 平臺或 Internet Explorer 5.x。
您需要比基本身份驗證更強大的密碼加密方法。
您需要支持通過 Internet 進行身份驗證。
以下情況下，您不應考慮使用簡要身份驗證：
您的某些客戶端使用非 .NET 或 Internet Explorer 5.0（或更高版本）的平臺。
您的用戶在 Active Directory 中沒有存儲 Windows 帳戶。
您需要代理。
其他考慮
選擇簡要身份驗證時，您還應考慮以下問題。
保護簡要身份驗證
簡要身份驗證的目的是提供比基本身份驗證更安全的登錄方法。然而，它沒有與 SSL、NTLM、Kerberos 或證書身份驗證相結合的基本身份驗證安全。
通過 SSL 使用簡要身份驗證是一個安全的解決方案，但是其部署要求目前限制了它的廣泛使用。
簡要身份驗證的特定平臺要求
簡要身份驗證要求客戶端運行 .NET 或 Internet Explorer 5.x。用戶帳戶必須存儲在 Active Directory 中，且 Active Directory 必須針對簡要身份驗證進行配置。
實現
您必須為簡要身份驗證配置 IIS。有關詳情，請參閱 Microsoft 知識庫文章 Q222028，設置簡要身份驗證以使用 Internet Information Services 5.0（英文）。
如果您的 ASP .NET 應用程序需要作為已進行 IIS 簡要身份驗證的驗證用戶來運行，請使用以下 Web.config 配置：
// web.config 文件
<system.web>
<authentication mode="Windows" />
</system.web>
要在 Windows 2000 中使用簡要身份驗證，服務器必須能訪問設置為進行簡要身份驗證的 Active Directory 服務器。
有關簡要身份驗證的詳細信息，請參閱 RFC 2069 規范 http://www.ietf.org/rfc/rfc2069.txt)。
集成 Windows 身份驗證
集成 Windows 身份驗證（使用 NTLM 挑戰/響應或 Kerberos）涉及對具有 Windows NT 域或 Active Directory 帳戶的用戶進行身份驗證。與基本身份驗證和簡要身份驗證不同，在該方法中加密密碼不通過網絡發送，因而非常安全。如果服務器中安裝有 Active Directory 服務，且瀏覽器與 Kerberos V5 身份驗證協議兼容，則將使用 Kerberos V5 協議和挑戰/響應協議，否則將僅使用挑戰/響應協議。該方法最適合 Intranet 環境。在這種環境中，用戶和 Web 服務器計算機在同一個域中，管理員可以保證每臺計算機均運行 Microsoft Internet Explorer 版本 3.01 或更高版本。
典型應用方案
以下情況下，您應考慮使用集成 Windows 身份驗證：
您的用戶具有 Windows NT 域或 Active Directory 帳戶。
您的應用程序運行于 Intranet 上（在防火墻后）。
所有客戶端均運行 Internet Explorer 版本 3.01 或更高版本。
您需要執行代理（這需要 Kerberos）。
您需要為域用戶采用無縫登錄程序（例如，沒有彈出式登錄對話框）。
以下情況下，您不應考慮使用集成 Windows 身份驗證：
您的用戶帳戶是存儲在外部數據庫中，而不是存儲在 Windows NT 域數據庫或 Active Directory 中。
您需要支持通過 Internet 進行身份驗證。
您的客戶端使用 Netscape Navigator 或其他非 Microsoft 瀏覽器。
您需要獲得客戶的明文密碼。
其他考慮
選擇集成 Windows 身份驗證時，還應考慮以下問題。
NTLM 和 Kerberos 的安全級別
這兩種協議均高度安全。對于 NTLM 和 Kerberos 協議，密碼不通過網絡傳輸。NTLM 使用一種挑戰/響應機制。Kerberos 甚至更加安全，因為它支持互相驗證（即，客戶端可以驗證其與之通訊的服務器）。
代理問題
NTLM 協議不支持代理。當客戶端的憑據傳送到 IIS 服務器之后，它們不能被傳送到后端服務器進行身份驗證。但是，Kerberos 支持代理，允許多個下游計算機的其他進程代理客戶端憑據。例如，您可以使用 Kerberos 將 Web 用戶的憑據提供給 COM+ 中間層，并通過該層到達 Microsoft SQL Server 數據庫（配置為 Windows 集成安全性）。Active Directory 的默認配置中未啟用 Kerberos 身份驗證。在決定將其作為代理解決方案之前，您必須確保您的環境支持 Kerberos。
Internet 的使用
NTLM 和 Kerberos 協議在 Internet 中均不常用。要在 Internet 中使用 Kerberos，關鍵問題是安全授權需要集中并對所有用戶可用。只有基礎設施到位才能實現這一點。部署 Internet 的另一個問題是非 Microsoft 瀏覽器不支持這些協議。對于特定的客戶群，這可能會是一個限制因素。
性能和可伸縮性
Kerberos 比 NTLM 快。但是，這兩種協議均比基本身份驗證或某些自定義身份驗證方法慢。如果您希望大量用戶同時登錄，就需要仔細設計 Active Directory 的配置。如果您擁有數百萬的潛在用戶，則您可以考慮使用高性能數據庫（如 SQL Server）來存儲用戶的名字和密碼。如果您在多層應用程序中代理安全環境，就很可能會遇到可伸縮性問題。特別是，不能使用數據庫連接池等中間層解決方案。
實現
要實現 Kerberos 或 NTLM，您需要配置 IIS 以使用集成 Windows 身份驗證。如果您需要支持運行非 Internet Explorer 的客戶端，則可以啟用基本身份驗證以結合 NTLM 或 Kerberos。
配置 Kerberos 時，您需要考慮這些特定細節：
客戶端和服務器必須都在同一 Windows 2000 域中運行 Windows 2000。
必須啟用客戶端的用戶帳戶以使用代理。
必須啟用服務器的帳戶以使用代理。
如果您的 ASP .NET 應用程序需要作為已由 IIS 使用集成 Windows 身份驗證進行過驗證的用戶來運行，請使用以下 Web.config 配置：
// web.config 文件
<system.web>
<authentication mode="Windows" />
</system.web>
有關使用 Kerberos 的詳細信息，請參閱：
Windows 2000 中的 Kerberos 組件（英文）
Kerberos 說明（英文）
證書身份驗證
證書是安裝在計算機中的數字“密鑰”。計算機試圖訪問服務器時，密鑰將自動傳送以對用戶進行身份驗證。客戶端證書可被映射到域或 Active Directory 中的 Windows 帳戶。如果您在 ASP .NET 中使用 Windows 身份驗證提供程序，應用程序線程將作為證書所映射的用戶運行。您也可在 ASP .NET 中實現自定義身份驗證，例如，您可以使用證書內包含的電子郵件地址（或類似的唯一字段）。從客戶端的觀點來看，安全性是無縫的，因為客戶端不需要使用登錄頁來登錄。這就使得證書在自動化業務流程方面成為一個有吸引力的選擇。
典型應用方案
以下情況下，您應考慮使用證書身份驗證：
您所保護的數據非常敏感，您需要非常安全的解決方案。
您需要互相身份驗證。
您希望第三方能夠管理服務器和證書擁有者之間的關系。
您希望實現無縫的客戶端交互，例如自動 B2B 交易。
以下情況下，您不應考慮使用證書身份驗證：
發布和管理客戶端證書的成本超過了增加安全性所獲得的價值。
其他考慮
選擇證書身份驗證時，您還應考慮以下問題。
部署
您需要將客戶端證書物理部署在客戶端工作站中。有多種方法可以進行此部署，從 Web 部署到從 CD-ROM 安裝證書。通常是部署的問題導致了證書模式的使用不如其他與 SSL 相結合的身份驗證模式廣泛。
映射到 Windows 帳戶
可以將證書映射到域或 Active Directory 帳戶。如果需要對個別用戶進行身份驗證，可以使用一種稱為“一對一映射”的技術，將證書映射到單獨帳戶。如果使用 Active Directory 映射，則對一對一映射沒有限制。
如果需要驗證來自特定組或組織的所有用戶，則可以使用多對一映射，例如，將所有包含同一公司名稱的用戶映射到一個帳戶。
例如，考慮以下 B2B 方案：
公司 A 允許其合作公司 B 查看其部分內部網站。
公司 B 的計算機安裝有證書。
多對一映射的結果是，ASP .NET 應用程序將作為通用的“CompanyB” Windows 帳戶運行。
有關證書的深入信息，請參閱由 Michael Howard 所著的《設計 Microsoft Windows 2000 基于 Web 的安全應用程序》。
實現
您必須配置 IIS 以進行證書身份驗證。有關將公共密鑰證書映射到 Windows 2000 用戶帳戶的詳細信息，請參閱將證書映射到用戶帳戶的循序漸進指南（英文）。
Passport 身份驗證
Passport 身份驗證是由 Microsoft 提供的集中身份驗證服務。使用 Passport 時，在某些情況下您不必實現自己的身份驗證代碼、登錄頁和用戶表。Passport 使用 Cookie 機制工作。如果客戶端以前已經通過了 Passport 驗證，則允許它們訪問您的站點。否則，它們將被自動重定向到 Passport 站點以進行身份驗證。
如果您需要在多個域之間進行單一登錄（這些域也支持 Passport），那么 Passport 是一個好選擇。Passport 不僅提供身份驗證服務，還提供包括配置文件管理和采購服務在內的其他服務。
在 Windows 2000 平臺上，Passport 沒有直接集成到操作系統內部的任何身份驗證和授權機制。.NET 框架確實會檢查 Passport Cookie，但如果您維護自己的數據庫，您必須實現自己的代碼，以將 Passport 用戶映射為自己的用戶，同時還要實現自己的授權機制。
典型應用方案
以下情況下，您應考慮使用 Passport 身份驗證：
您的站點要與其他啟用 Passport 的站點結合使用，同時您希望訪問這些站點的用戶能夠進行單一登錄。
您不想維護用戶名和密碼數據庫。
以下情況下，您不應考慮使用 Passport 身份驗證：
您希望使用已經存儲在自己的數據庫或 Active Directory 中的用戶名和密碼。（盡管有可能使用額外的代碼將 Passport ID 映射為用戶帳戶。）
您的客戶端是通過編程來訪問站點的其他計算機。
其他考慮
選擇 Passport 身份驗證時，您還應考慮以下問題。
啟用 Passport
使用 Passport 身份驗證要求站點注冊 Passport 服務并在服務器中安裝 Passport SDK。
代理
在 Windows 2000 中，不可能從一個服務器將用戶的 Passport 安全憑據代理到另一個。
映射到用戶帳戶
Passport 用戶 ID (PUID) 僅僅是一個標識。如果您的用戶帳戶是在 Active Directory 或任何自定義數據庫中定義的，并且您需要將 PUID 映射為用戶，則您需要實現自己的自定義代碼。Windows 的未來版本可能會提供將 PUID 映射到 Windows 帳戶的本機支持。
保護 Passport
當 Passport 作為單機身份驗證方法使用時，加密 Cookie 的本質使得 Passport 比較安全。然而，為了避免重放攻擊并維持最高安全級別，Passport 需要與 SSL 結合使用。
實現
要實現 Passport，您需要在服務器中安裝 Passport SDK。您還需要向 Passport 注冊以使用服務。您必須按如下方法配置 web.config 文件：
// web.config 文件
<system.web>
<authentication mode="Passport" />
</system.web>
有關 Passport 服務的詳細信息，請參閱：
Passport 身份驗證提供程序（英文）
Passport 技術白皮書（英文）
Passport 開發人員信息（英文）
表單身份驗證
表單身份驗證是指接受用戶憑據的自定義用戶界面組件，例如，一個用戶名和密碼。現在使用的許多 Internet 應用程序具有這種供用戶登錄的表單。值得注意的是，表單本身并不執行身份驗證，它僅僅是一種獲得用戶憑據的方法。身份驗證是通過使用自定義代碼訪問用戶名和密碼數據庫來實現的。
驗證用戶身份后，服務器一般會通過某種方式向客戶端表明其已經通過身份驗證，可以進行后續請求。如果需要，您可以強制用戶驗證每個請求，但這樣會影響性能和可伸縮性。您應考慮兩種基本方法來識別以前登錄過的客戶端：
Cookie。Cookie 是最初由服務器向客戶端發送的一小段數據。隨后，由客戶端隨每個 HTTP 請求將其發送回服務器。它可以用作客戶端已經通過身份驗證的標志。ASP .NET 通過 CookieAuthenticationProvider 模塊為您提供了使用 Cookie 進行表單身份驗證的機制。大多數 Web 瀏覽器（包括 Internet Explorer 和 Netscape Navigator）均支持 Cookie。
自定義。您可以實現自己的自定義機制來向服務器標識客戶端。如果您的客戶端禁用了 Cookie，您可以考慮在每個 URL 查詢字符串中存儲一個唯一標識符。或者使用存儲在永久性頂級或不可見框架中的隱藏表單域。無論如何，您要確保黑客不能通過編程模擬成已經通過應用程序身份驗證的用戶。
Cookie 廣泛應用于使用表單身份驗證的網站。.NET 的最初版本將僅支持使用 Cookie 的表單身份驗證。
典型應用方案
以下情況下，您應考慮使用表單驗證：
用戶名和密碼存儲在 Windows 帳戶以外的位置。請注意，Windows 帳戶也可以使用表單身份驗證。
您要在 Internet 上部署應用程序。
您需要支持所有瀏覽器和客戶端操作系統。
您希望為用戶提供自己的用戶界面表單作為登錄頁。
以下情況下，您不應考慮使用表單驗證：
您要為公司 Intranet 部署應用程序，并且可以利用集成 Windows 身份驗證。
您不能通過編程訪問來驗證用戶名和密碼。
其他考慮
選擇表單身份驗證時，您還應考慮以下問題。
保護表單身份驗證
如果用戶是通過登錄頁來提交密碼的，您可以使用 SSL 來保護通道，以防密碼被盜。如果您使用 Cookie 來維護用戶在各個請求之間的標識，您應當了解黑客通過網絡監視程序“盜用”用戶 Cookie 的潛在危險。使用 Cookie 時，要使站點真正安全，唯一的方法是站點內的所有通訊都使用 SSL。對大多數商業網站來說，由于這種方法的運行開銷太大，所以不切實際。使用 ASP .NET，您可以使服務器定期重生成 Cookie。這種使 Cookie 過期的策略是為了防止其他用戶盜用 Cookie 訪問站點。
性能和可伸縮性
設計大流量網站時，您需要考慮驗證用戶身份所帶來的性能影響。如果您預計會有大量用戶同時登錄，您需要盡快完成憑據確認過程。
如果使用 SSL，由于必須執行額外的加密步驟，性能會明顯下降。在 Web 中，您應將實現安全登錄的服務器和內容服務器分開，以滿足性能要求。
檢查 Cookie 的存在
如果您使用的是 .NET，則檢查 Cookie 存在的進程是自動實現的。但如果不使用 .NET，則有兩種基本方法：
實現 ISAPI 篩選器，它確認客戶端請求中 Cookie 的存在，證明客戶端已經通過身份驗證。如果 Cookie 存在，則允許請求繼續。如果 Cookie 不存在，則將客戶端重定向到登錄頁。如上所述的 ISAPI 篩選器可以由 Microsoft Commerce Server 2000 實現。
您可以在每個 Web 頁的開始處編寫代碼檢查 Cookie 是否存在，或編寫由 Web 頁傳遞的其他自定義值。如果標記不存在，代碼可將用戶重定向到登錄頁。這一實現方法很簡單；但是，您可能無法保護除 ASP 頁以外的資源。例如，圖像文件可能仍然可以訪問。
如果您使用的是 ASP .NET，則可以利用表單身份驗證提供的內置功能。
使用表單身份驗證與 Windows 帳戶
如果您部署的是 Internet 應用程序，而您的用戶在服務器中具有 Windows 帳戶，則可以使用表單身份驗證或 SSL 上的表單身份驗證，以替代基本身份驗證和簡要身份驗證。
如果您的應用程序基于 Intranet，并且已經在使用集成 Windows 身份驗證，則表單身份驗證可能并非好的解決方案。您公司的安全策略可能也不允許用戶將密碼輸入 HTML 表單。
實現
要實現表單身份驗證，您必須創建自己的登錄頁并重定向未驗證客戶端的 URL。您還必須創建自己的帳戶查找方案。使用 ASP .NET，可以使用以下 Web.config 配置：
// web.config 文件
<system.web>
<authentication mode="Forms" />
</system.web>
因為您實現的是自己的身份驗證，一般可以將 IIS 配置為匿名身份驗證。
有關實現 SSL 的詳細信息，請參閱以下文章。
Web 安全性揭密：最大限度地利用 IIS 安全性（英文）
《Internet Information Services 5.0 資源指南》中的“配置 IIS 5.0 安全性”
Cookie
Cookie 是由 Web 服務器放在您的硬盤驅動器上的一個小文本文件。其主要目的是讓服務器能夠識別返回的客戶端。無論是否存在身份驗證機制，您都可以使用 Cookie。請考慮以下應用方案：
與表單身份驗證結合使用。服務器根據身份驗證向客戶端發布一個 Cookie，并根據提交回服務器的 Cookie 來驗證后續請求。
僅用于向用戶提供自定義內容的個性化站點。
ASP .NET 提供了一種機制來創建 Cookie 并自動檢查客戶端請求中是否存在 Cookie。可以使用 .NET 框架支持的三級 DES 方案對由 ASP .NET 創建的 Cookie 進行有選擇的加密。您也可以實現自己的 Cookie 提供程序并在表單身份驗證中使用。
有關 Cookie 的詳細信息，請參閱關于 Cookie 的信息（英文）。
其他考慮
不同瀏覽器類型可能對 Cookie 的大小有不同的限制。RFC 2019 指定的大小限制為 4 KB。Internet Explorer 5 對 Cookie 沒有大小限制。瀏覽器的安全設置必須配置為接受 Cookie，程序才能正常工作。
--------------------------------------------------------------------------------
Web 服務安全性
Web 服務是基于 ASP .NET 結構的應用程序，可以通過 Internet 編程調用。從安全角度看，它存在的問題與開發交互式網站的問題類似。您需要使用與保護 ASP .NET 資源相同的機制來保護 Web 服務（如 IIS 和 ASP .NET 身份驗證提供程序）。但是，設計過程中您還需要考慮這些額外因素：
客戶端交互。您的 Web 服務可能沒有連接和輸入安全憑據的交互用戶。而您的“用戶”可能是應用程序。
方法級別安全性。您可能需要在方法級別授權用戶，以限制使用特定方法，您可以采用類似于 COM+ 組件方法級別安全性的方法來實現這一目的。
代理。您的 Web 服務可能需要（也可能不需要）呼叫其他服務并維護原始呼叫方的安全環境。
Web 服務身份驗證
Web 服務需要以某種方式接受用戶憑據。如果服務是非交互式的，則需要獲得呼叫方的安全標記，或需要顯露適當的方法以允許提供憑據。以下身份驗證方法容易使用，不需要用戶輸入憑據，對于可編程 Web 服務來說是很好的選擇：
基本、簡要和集成 Windows 身份驗證
證書映射身份驗證
應用程序專用或自定義身份驗證
以下的選項也有應用潛力：
Internet 協議安全性
Passport
使用 Windows 帳戶和 IIS 身份驗證
您需要考慮的問題與本文身份驗證方法一節中所述的問題一樣。本實現方法所需的自定義代碼最少，同時，您可以使用 Windows ACL 授權對其他資源的訪問。
使用證書和證書映射
當使用證書身份驗證時，客戶端和服務器之間可以進行無縫交互；即，客戶端不必通過編程提供用戶名和密碼。而且，這是一種高度安全的機制。B2B 交易（如提交訂單）是使用證書的理想場合。如果您使用證書映射來獲取 Windows 用戶帳戶，您也可以使用 Windows ACL 來授權對資源的訪問。
自定義身份驗證
您可以實現自定義身份驗證解決方案。與集成 Windows 身份驗證方法相比，此解決方案的優點是，不再需要應用程序來為每個用戶維護各自的帳戶。您還可以一起忽略 IIS 身份驗證，而在 Web 服務代碼中使用自己的自定義方法，并根據應用程序特定的要求進行優化。
可能的 Web 服務自定義身份驗證解決方案包括：
接受用戶名和密碼作為方法調用的參數。
提供一種必須在調用其他方法之前調用的登錄方法。您可以使用 Microsoft .NET 框架的 Cookie 功能來驗證對登錄方法的調用。
使用 SOAP 標頭或 SOAP 正文來存儲憑據。
創建自定義 HTTP 標頭或正文來存儲憑據。
Internet 協議安全性
如果您知道客戶端的 IP 地址，例如，客戶端是調用封裝在 Web 服務業務邏輯的中間層 Web 服務器，則可以選擇 Internet 協議安全性 (IPSec)。此方法允許您根據 IP 地址來限制連接到 Web 服務的計算機。
該方法在 Internet 方案中不可行，因為您預先不知道客戶端的 IP 地址。
有關 IPSec 的詳細信息，請參閱 MSDN 文章 Microsoft Windows 2000 服務器的 IP 安全性（英文）。
在 Web 服務中使用 Passport
有時 Web 服務可能會使用 Passport 進行身份驗證。但是，它的使用很有限，因為它要求將未通過驗證的客戶重定向到 Passport 站點。對非交互式客戶端來說，重定向會出現問題，除非專門為此編程來處理重定向到 Passport 服務器的情況。
授權
完成用戶身份驗證后，您可能需要授權其訪問 Web 服務。以下是幾種授權選項：
使用 Windows ACL
使用 URL 授權
使用 .NET Principal 對象
使用 Windows ACL
使用 Windows ACL，您可以創建特定應用程序文件的文件系統許可。如果您的 Web 服務對用戶進行 Windows 帳戶身份驗證并使用模擬，則可以使用此解決方案。
使用 URL 授權
URLAuthorizationModule 將用戶和角色映射到 URI 名稱空間中的元素。該模塊同時實現肯定和否定的授權聲明。也就是說，該模塊可以根據用戶的某種身份（例如角色關系），選擇性地允許或拒絕該用戶訪問 URI 名稱空間中的任意元素。下面的例子為某些域用戶授權，但拒絕其他用戶。
<configuration>
<system.web>
<authentication mode="Windows" />
<authorization>
<allow users="domain1\user, domain2\user2, domain1\user3 />
<deny users="*" />
</authorization>
</system.web>
</configuration>
Windows Principal 對象
.NET 框架類庫 (BCL) 中的 System.Security.Principal 名稱空間提供了一個 WindowsPrincipal 對象來表示代碼運行的安全環境。使用 IIS 中的 Windows 身份驗證時，該對象將自動創建。它允許您檢查 Windows 用戶的 Windows 組成員，并相應地限制訪問權限。
Generic Principal 對象
Generic Principal 對象可根據您自己的自定義角色來創建。如果您擁有自己的用戶/角色數據庫，則可以使用它。Principal 對象在 OnAuthenticate 事件中填充。您可以將自定義表映射到在此事件中映射的 Windows 帳戶。無論如何，您都可以為該特殊用戶創建一個自定義 Principal 對象。
對于已經通過身份驗證的返回用戶，您可以使用 Cookie 來重新為返回用戶重新創建 Principal 對象。
角色和方法級別安全性
您可能需要使用方法級別安全性來限制由特殊客戶端當事者調用的特殊方法。有許多方法可以處理該問題。
如果您使用 Windows 帳戶，可以以 Windows 組的形式為用戶創建角色。因為 ASP 線程將模擬客戶端，您將獲得一個 Windows Principal 對象；請使用以下方法：
為 ASP .NET 線程訪問的受保護資源創建 ACL。
從每一種方法調用 WindowsPrincipal 對象中的 IsInRole 方法，以驗證調用方具有適當的權限。您還可以在代碼中實現邏輯語句，根據客戶端的組成員身份調用特定的子例程。
如果您使用自定義數據庫中的用戶和角色創建 Generic Principal 對象：
您可以通過編程調用 Principal 對象的 IsInRole 方法以檢查角色成員身份，其方式與上文所述的 Windows Principal 對象相同。
如果您不使用 Principal 對象，則可以選擇其他選項：
接受用戶憑據作為方法調用的參數并進行查找。
方法調用的第一項操作是驗證 Cookie 的存在。
創建一個登錄方法返回自定義鍵值。后續的方法將接受此鍵值作為參數。這與使用受瀏覽器支持的 Cookie 類似，但是它在客戶端不支持 Cookie 的情況下也可以使用。
代理
和 ASP .NET 網站一樣，Web 服務也存在同樣的代理問題。要將安全環境代理到 Web 服務，您需要使用 Kerberos 身份驗證，或者必須傳遞憑據以便于運行在其他計算機上的 Web 服務能夠調用 LogonUser（對于 Windows 服務器）或等價身份驗證 API（對于非 Windows 服務器）。
客戶端訪問
如果您通過編程與 Web 服務連接，您可以利用 .NET 類進行客戶端連接。.NET 客戶端支持的身份驗證協議有：
基本
簡要
Windows 集成（NTLM 和 Kerberos）
證書
自定義
--------------------------------------------------------------------------------
代碼訪問安全性
為了保護計算機系統不受惡意代碼的干擾，也為了保證移動代碼的安全運行，.NET 框架提供了一種稱為代碼訪問安全性 (CAS) 的安全機制。CAS 是一種 .NET 安全特征，適用于所有 .NET 托管代碼，如 ASP .NET Web 應用程序。盡管如此，在編寫以下特定代碼時您需要牢記這一點：
設計瀏覽器承載的控件
承載第三方應用程序
在共享服務器上承載來自不同供應商的程序集
您希望保護某些本機功能（如文件寫 API）以供某些程序集使用
根據代碼的來源和代碼標識的其他特征（如強加密程序集名），CAS 允許代碼有不同的可信度，這取決于您的安全策略。CAS 減少了您的代碼被其他惡意代碼濫用的可能性。它使您可以專門設置允許代碼執行的操作，以及決不允許代碼執行的操作。特別是，CAS 支持許可支持機制，通過該機制，代碼可明確請求特定許可、或明確拒絕其他不需要的許可。
代碼訪問許可
代碼訪問安全性依賴于代碼訪問許可概念。每個許可代表代碼訪問受保護資源（如文件、目錄、注冊表項）的權限或執行受保護操作（如調用非托管代碼）的權限。代碼將請求許可，而運行時安全策略將決定授予何種許可。有關完整列表，請參閱代碼訪問許可（英文）。
.NET 允許管理員向應用程序分配預定義的許可集。這些許可集根據應用程序的可信度而有所不同。默認情況下，應用程序根據代碼的數字簽名、原始格式和應用程序位置等證據獲得信任級別。
例如，運行在 UNC 共享（在 Intranet 安全區域運行）上的應用程序將獲得 LocalIntranet 許可集。而運行在本地計算機（在 MyComputer 安全區域運行）上的應用程序將獲得 FullTrust 許可集。
通過為 ASP .NET Web 應用程序分配信任級別，可以進一步配置它們。信任級別的配置是通過使用配置文件中的 <trust> 元素來實現的。
<trust level="Full | High | Low | None" originUrl="url" />
每個級別都決定了應用程序的許可程度，其細節在 XML 安全策略文件中指定。每一級別都映射到一個特定文件。ASP .NET 的默認映射是：
高 - 映射到 web_hightrust.config 這一級別提供的授權允許應用程序讀/寫應用程序目錄（服從于操作系統許可），并允許應用程序取代身份驗證 Principal 對象。它還限制應用程序調用非托管代碼。
低 - 映射到 web_lowtrust.config 這一級別允許應用程序讀取應用程序目錄，并提供有限的網絡連接。如果 <trust> 元素的 originUrl 屬性配置恰當，應用程序就能夠連回其承載站點。
無 - 映射到 web_notrust.config 這一級別提供基本執行許可，并支持應用程序使用獨立存儲（一種允許代碼與保存數據安全關聯的機制）。
請注意，完全信任沒有相應的配置文件，因為完全信任允許應用程序使用所有資源（服從于操作系統許可），如同在沒有代碼訪問安全性的情況下運行一樣（但 CAS 不能關閉托管代碼）。您可以使用配置文件中的 <securityPolicy> 元素替代這些映射，也可以自定義和擴展每一級別。您還可創建自己的定義任意許可集的級別。以下所示為默認 <securityPolicy> 映射集。
<securityPolicy>
<trustLevel name="Full" policyFile="internal" />
<trustLevel name="High" policyFile="web_hightrust.config" />
<trustLevel name="Low" policyFile="web_lowtrust.config" />
<trustLevel name="None" policyFile="web_notrust.config" />
</securityPolicy>
鎖定配置設置
ASP .NET 配置在本質上是層次化的，在計算機級別、應用程序級別和子應用程序級別具有可選的配置文件。子級別配置文件可用于替代更高級別的設置，或用于添加其他配置信息。盡管它提供了很高的靈活性，但有時候管理員希望加強配置設置，不允許他們被指定的應用程序替代。例如，宿主網站的管理員希望指定代碼訪問安全級別，不允許單個應用程序更改它。結合使用 <location> 元素和 allowOverride 屬性可以實現這一目的。
例如，宿主網站的管理員希望確保所有應用程序都不能調用非托管代碼。以下配置文件片段說明管理員如何鎖定整個站點的代碼訪問配置設置，并限制高信任級別的應用程序（不允許調用非托管代碼）：
<location path="somesitepath" allowOverride="false">
<trust level="high" originUrl="http://somesite.com"; />
</location>
path 屬性可以指向站點或虛擬目錄，它適用于指定目錄及其所有子目錄。在上面的示例中，如果將 allowOverride 設置為“假”，則能夠保護站點內的所有應用程序不被 <location> 元素中指定的配置設置替代。請注意，鎖定配置設置的功能適用于所有設置，而不僅限于信任級別這樣的安全設置。
有關詳細信息，請參閱：
.NET 中的安全性：使用公共語言運行時限制代碼訪問權限（英文）
代碼訪問安全性（英文）
--------------------------------------------------------------------------------
通道安全性
通道通過遠程處理邊界（如 AppDomains、進程和計算機）來傳輸信息。.NET 框架提供兩種遠程處理通道：HTTP 和 TCP。
如果您希望保護通過這些協議傳輸的機密或敏感信息，則需要考慮使用安全通道。除非信息沒有加密保護，否則使用網絡監視軟件很容易中途截獲和讀取這些信息。
以下是通道安全性的一些關鍵問題：
承載于 IIS 和 ASP .NET 中的 HTTP 通道支持使用 SSL 傳送和接收安全數據。SSL 是設置安全通訊通道的最常用機制，可以在 IIS 內配置。
如果您希望使用非安全通道（如 HTTP/端口 80 或 TCP），則仍然可以使用加密 API 手動加密數據。
可以在傳輸層下實現通道安全機制。如果您使用 Windows 2000，則可以利用 Internet 協議安全性 (IPSec)，在對應用程序透明的同時，達到保護數據傳輸的目的。
如果您使用 ASP .NET 和 COM 或 DCOM 組件，并使用 DCOM 作為您的遠程處理機制，則可以考慮使用 DCOM 數據包保密身份驗證級別來加密 DCOM 通訊。
有關詳細信息，請參閱：
《Microsoft Windows 2000 Server 資源包》中的“保護 Web 通訊”，Microsoft Press
.NET 框架開發人員規范（英文）中的遠程處理規范
Microsoft Windows 2000 Server IP 安全性（英文）
MSDN 中的“設置 DCOM 和 NT 安全性”
--------------------------------------------------------------------------------
其他信息
要了解本文討論的安全問題的其他信息，請參閱以下參考內容。
《Microsoft Windows 2000 Server 資源包》中的“理解數字證書”，Microsoft Press
.NET 框架 SDK（英文）
Microsoft 知識庫文章 Q158229，信息：IIS 應用程序的安全性部分（英文）
使用 Microsoft Windows 平臺創建網站的藍圖（英文）
有關 Web 服務安全性的詳細信息，請參閱以下參考材料。
使用 SOAP 工具包保護 Web 服務（英文）
《設計基于 Web 的 Microsoft Windows 2000 安全應用程序》，Microsoft Press
Internet Information Services 5 安全性檢查表（英文）
Microsoft 知識庫文章 Q187506，運行 IIS 站點所需的 NTFS 權限列表（英文）
有關安全性的一般信息，請參閱：
Microsoft 安全性
|
