摘要：本文主要介紹了ASP.NET WEB應用程式的安全模型的種類、比較其優缺點，提出了選擇的機制。
關鍵字：安全模型受信任子模型模擬/委託子模型ASP.NET WEB應用
1.前言
ASP.NET WEB應用程式通常屬於多層體系結構，一般從邏輯結構上可以分為表示層、業務邏輯層和資料存取層；用戶端要存取應用程式資源，其身分認證和授權必然要跨越多個層次。本文主要討論SP.NET應用程式的資源存取安全模型
2.資源存取標識
WEB應用程式對外提供的給客戶端的典型資源包括：
Web伺服器資源，如Web頁、Web服務和靜態資源（HTML頁和映像）。
資料庫資源，如針對每個使用者的資料或是應用程式層級資料。
網路資源，如遠端檔案系統資源等。
系統資源，如註冊表、事件日誌和設定檔等。
客戶端跨越應用程式的層來存取這些資源，要有一個標識流經各個層。這個用於資源存取的標識包括：
原始呼叫者的標識原始呼叫者的標識被取得並且隨後流經系統的每個層。
進程標識本地資源存取和下游呼叫是使用當前進程標識進行的。這種方式的可行性依賴於要跨越的邊界，因為進程標識必須能被目標系統辨識。這需要以下面兩種方式之一進行呼叫：
在同一個Windows安全域中跨Windows安全域-使用信任和網域帳戶，或在不存在信任關係的情況下使用重複的使用者名稱和密碼。
服務帳戶這種方式使用一個（固定的）服務帳戶。例如對於資料庫訪問，該服務帳戶可能由連接到資料庫的一個元件表示固定的SQL使用者名稱和密碼。
當需要固定的Windows標識時，應使用Enterprise Services伺服器應用程式。
自訂標識當沒有Windows帳戶可用時，可以使用Iprincipal和Iidentity實現構造自己的標識，可以包含安全上下文相關的詳細資訊。
3. 資源存取模型
3.1 受信任子系統模型
如圖1所示，在這個模型中，原始呼叫者的安全上下文並不在作業系統層級流經服務，而是在中間服務層使用了一個固定標識來存取下游的服務和資源。受信任子系統模型得名於這樣一個事實：下游服務（可能是一個資料庫）信任上游服務，讓其呼叫者進行授權。圖1中的範例，資料庫信任中間層對呼叫者進行的授權，並且只允許被授權的呼叫者使用受信任標識存取資料庫。
3.1.1 資源存取模式
在受信任子系統模型中，資源存取模式如下：
對使用者進行驗證將使用者對應為角色根據角色成員關係進行授權使用一個固定的受信任標識存取下游資源
3.1.2 固定標識
用於存取下游系統合資源管理器的固定標識，可以使用進程標識，也可以使用一個預先設定的Windows帳戶-服務帳戶來提供。對於SQL Server資源管理器，這意味著對SQL Server的Windows驗證。
使用進程識別碼時通常使用ASP.NET進程識別碼（默認識ASPNET帳戶）。實際應用時，經常需要將ASPNET帳戶變更為一個更安全的密碼，並在SQL Server電腦上鏡像建立一個與ASP.NET處理程序帳戶相符的Windows帳戶。具體方法如下：
編輯位於%windr%Microsoft.NETFrameworkv1.1.4322CONFIG目錄下的Machine.config文件，將<processModel>元素上的密碼屬性重新配置，將其預設值<!-UserName="machine" password ="AutoGenerate" -->改為<!-UserName="machine" password="NewPassword" -->；或是透過ASPNET_setreg.exe工具，將使用者名稱和密碼儲存到登錄，設定改為：<!- enable="true" UserName="Registry:HKLMSOFTWAREYourAPPprocesssModelASPNET_SETREG,userName" password=" Registry:HKLMSOFTWAREYourAPPprocesssModelASPNET_SETREG,password " -->
另外一些應用程式使用指定的SQL帳戶（在連接字串中由使用者名稱和密碼指定）來存取SQL Server。在這種情況下，資料庫必須配置為SQL身份驗證。在設定檔中儲存的連接字串需要加密保護。
3.2 模擬/委託模型
如圖2所示，使用類比/委託模型時，一個服務或元件（通常位於邏輯業務服務層）在存取下一個下游服務前，使用作業系統模擬功能來模擬客戶端標識。如果該服務位於同一台電腦上，則使用模擬就足夠了，如果下游服務位於遠端電腦則還需要使用委託，下游資源存取的安全上下文是用戶端的上下文。
3.3 選擇資源存取模型
兩種資源存取模型的比較如表一所示。
受信任子系統模型模擬/委託模型審核功能後端信任上層服務，若中間層受侵害，後端資源易受攻擊。 後端服務可以對每個呼叫者進行驗證、授權，安全性好。
可伸縮性支援連接池，伸縮性佳。 不支援連接池，伸縮性差。
後端ACL管理ACL針對單一實體進行配置，管理工作少。 每個使用者都要被授予相應的存取級別，後端資源和使用者數增大時，管理工作繁瑣。
技術問題不用委託。 需要委託。大多數安全服務提供程序不支援委託。
在大多數Internet應用程式以及大型intranet應用程式中都會使用受信任子系統模型，這主要是由於這種模型能很好的支援可擴展性。模擬/委託模型則傾向於用於小型的系統。對於這些應用程序，可伸縮性不是主要的考慮因素，其主要考慮的因素是審核。