ASP.NET 4 應用程式中的程式碼存取安全性

程式碼存取安全性 (CAS) 是指 ASP.NET 用來對執行程式碼之能力強制執行條件約束的 .NET Framework 安全性機制 (「沙箱」)。 自從 ASP.NET 1.1 以來，ASP.NET 就已經使用信任層級的概念來實作程式碼存取安全性。

本主題將說明 CAS 如何在 ASP.NET 4 中運作，並且特別強調這項功能自舊版以來如何變更。 如果您剛接觸 ASP.NET，這些變更對您而言可能不重要。 不過，本主題包含 CAS 如何在目前 ASP.NET 版本中運作的相關資訊，而這項資訊可能會影響您設計新應用程式的方式。

本主題將討論下列主旨：

• 不再使用 CAS 原則層級的原因，以及這項變更如何影響一般案例，例如讓部分信任 ASP.NET 應用程式從 UNC 共用執行。

• 如何在 ASP.NET 4 中自訂 CAS 行為。

• 當您讓信任的程式碼在 ASP.NET 4 中使用 CAS 時，可能會發生的相容性問題。

本主題假設您了解 .NET Framework CAS 和 ASP.NET 信任層級。 如需這些主題的詳細資訊，請參閱下列文件：

• HOW TO：在 ASP.NET 2.0 使用中度信任 (英文)

• 使用程式碼存取安全性搭配 ASP.NET (英文)

• .NET Framework 4 中的安全性變更

• 有關 CAS 原則和 CLR 的部落格系列文章，作者 Shawn Farkas (英文)

• 本主題包含下列資訊：

• ASP.NET 4 程式碼存取安全性模型概觀

• 同質性應用程式定義域

• 條件式 APTCA

• 安全性透明度以及它如何在 ASP.NET 4 中運作

ASP.NET 4 程式碼存取安全性模型概觀

在 ASP.NET 4 中，已經對 ASP.NET 3.5 和先前版本中的 CAS 進行許多基本變更，包括：

• 根據預設，ASP.NET 4 部分信任應用程式定義域為同質性。 這會針對在部分信任應用程式定義域中執行的程式碼產生一組受條件約束的可能權限集合。 這也表示應用程式定義域信任界限本身與部分信任授權集相關聯。 在同質性應用程式定義域中，安全性原則不會與電腦層級、使用者層級或企業層級 CAS 原則相交。

  注意事項
  新的同質性應用程式定義域模型所需的宣告式 ASP.NET 信任原則檔案集合與舊版 ASP.NET 中使用的原則檔案集合稍有不同。因此，在您安裝 ASP.NET 4 之後，電腦會包含兩組 ASP.NET 部分信任原則檔案。新的 CAS 模型會使用其中一組，而另一組則是在應用程式設定為使用 ASP.NET 4 之前的 CAS 模型時使用。

• 在舊版 ASP.NET 中，AspNetHostingPermission 屬性幾乎會用於所有公用 ASP.NET 相關類別，以便防止 ASP.NET 型別用於非 Web 部分信任環境中。 例如，如果 AspNetHostingPermission 屬性存在，系統就會防止您在部分信任 ClickOnce 應用程式中使用大部分 ASP.NET 類別 (如需 ClickOnce 應用程式中 CAS 的詳細資訊，請參閱 ClickOnce 應用程式的程式碼存取安全性)。ASP.NET 4 不仰賴 AspNetHostingPermission 屬性，而是改用稱為條件式 APTCA (以 AllowPartiallyTrustedCallersAttribute 型別為基礎) 的不同 CAS 技術來達到相同的結果。 因此，大部分的 ASP.NET 型別和成員都已經移除了 AspNetHostingPermission 屬性。

• 在 ASP.NET 4 中，許多系統組件都已經更新為使用 CLR 安全性透明度模型。 ASP.NET 4 中的透明度模型與 Silverlight 所使用的透明度模型非常相似。 如需程式碼透明度的詳細資訊，請參閱安全性透明的程式碼。

如果您原本仰賴使用 caspol.exe 等工具所建立的自訂 CLR CAS 原則，就會看見這些變更的影響。 當呼叫堆疊上只有 ASP.NET 或 .NET Framework 程式碼處於使用中狀態時，這些變更也會影響仰賴部署於 GAC 中之組件以便執行需要權限的作業的部分信任 Web 應用程式。 下列各節將討論這些 CAS 變更。

同質性應用程式定義域

本節將說明同質性應用程式定義域。 其內容將討論自從 ASP.NET 2.0 以來針對同質性應用程式定義域所產生的行為變更。 此外，也將討論您可以設定的相容性選項，以及您可以進行的程式碼變更，以便在同質性應用程式定義域中執行程式碼。

減少可能權限集合的數目

同質性應用程式定義域是指定義一組共用權限來執行程式碼的部分信任應用程式定義域。 在 ASP.NET 4 所裝載的同質性應用程式定義域中，可載入的程式碼會與兩個權限集合的其中一個相關聯。 程式碼會以完全信任執行 (GAC 程式碼一定會以完全信任執行)，或者程式碼會以目前 trustLevel 設定所定義的部分信任權限集合執行 (如需詳細資訊，請參閱 securityPolicy 的 trustLevel 項目 (ASP.NET 設定結構描述))。

注意事項
ASP.NET 4 應用程式定義域預設為完全信任。只有當 trustLevel 項目的 name 屬性設定為 Full 以外的值時，ASP.NET 4 中的同質性行為才會生效。

這種行為與舊版 ASP.NET 的部分信任應用程式不同。 在先前的版本中，您可能會建立多個權限集合，而且每個集合具有不同的授權集和不同的成員資格條件。 由於處理這類混合權限案例很困難，因此 .NET Framework 4 便導入了同質性應用程式定義域。 在考量了程式碼可能執行的所有狀況之後，發現建立多個權限集合，而且每個集合具有不同權限層級，然後再證明實際上強制執行不同的權限層級，實屬困難。 例如，程式碼可能會在反映底下執行、完全信任程式碼可能會代表部分信任呼叫端執行其他完全信任程式碼等等。 權限集合必須考量所有這類狀況。 同質性應用程式定義域會透過減少可能的結果，大幅簡化 CAS 決策。 程式碼具有完全信任，或者具有單一且妥善定義的部分信任權限集合。 對於 ASP.NET 而言，妥善定義的部分信任權限集合就是套用至指定之 ASP.NET 信任層級的集合。

若為嘗試在同質性應用程式定義域中載入的程式碼，還有第三種可能的狀態 (CLR 不會將這種狀態視為不同的權限集合)。第三種權限集合是空的權限集合，這種集合會在所有 ASP.NET 部分信任組態檔中定義為 Nothing 權限集合。 所有評估為 Nothing 權限集合的程式碼都會被視為無法載入的程式碼。 因此，任何嘗試將具有 Nothing 權限集合之組件載入同質性應用程式定義域的行為都會產生 SecurityException 例外狀況。

只套用 ASP.NET 部分信任原則

同質性應用程式定義域的部分信任權限集合只由負責建立應用程式定義域的主機建立。 在 ASP.NET 4 中，這表示部分信任權限集合只由位於 .NET Framework 安裝之 CONFIG 子目錄中的部分信任組態檔內容定義。 根據預設，ASP.NET 4 部分信任應用程式定義域的 ASP.NET 原則資訊不再與企業、電腦或使用者 CAS 原則設定重疊。

全域 CAS 原則資訊 (開發人員先前使用 caspol.exe 或 Mscorcfg.msc MMC 組態工具等工具管理的原則) 將不再影響 ASP.NET 4 同質性應用程式定義域 (您可以將 ASP.NET 設定為使用舊版 CAS 模型，其中 ASP.NET 設定會與企業、電腦和使用者原則相交。 後面的章節將說明這種舊版行為)。

最明顯的變更為 UNC 裝載的部分信任 ASP.NET 4 應用程式。 在先前的版本中，您必須使用 caspol.exe，將 UNC 共用提升至完全信任，才能讓 ASP.NET 部分信任原則生效。 這是因為，在舊版 ASP.NET 中，預設電腦層級 CLR CAS 原則會先生效。 因此，UNC 裝載的應用程式具有與內部網路區域相關聯的條件約束權限集合。 因為 ASP.NET 4 部分信任應用程式定義域只會根據 ASP.NET 原則檔案建立原則，所以 Web 應用程式的實體位置便不再影響與部分信任應用程式相關聯的權限集合。

下列案例將說明這項變更的副作用：系統管理員想要鎖定網頁伺服器，以便預設拒絕所有 Managed 程式碼的執行權限，然後針對選取的 ASP.NET 應用程式授與執行權限。 在舊版 ASP.NET 中，這項作業需要使用下列知識庫文件中所記載的罕見解決方法：修正：當您嘗試執行 ASP.NET 2.0 Web 應用程式時，如果沒有將 My_Computer_Zone 程式碼群組與「完全信任」權限集合產生關聯，就會出現錯誤訊息：「伺服器應用程式無法使用」(機器譯文)。 在 ASP.NET 4 中，系統管理員可以透過遵循下列步驟，鎖定網頁伺服器以拒絕或授與執行權限：

1. 建立自訂 ASP.NET 信任層級 (其原則檔案會將所有程式碼對應至 Nothing 權限集合 (空的權限集合))，然後將所有 ASP.NET 應用程式設定為預設使用該信任層級 (這是在根目錄 Web.config 檔案中進行設定)。

2. 選擇性地將個別 ASP.NET 應用程式與內建或自訂信任層級產生關聯，這些信任層級會授與 Managed 程式碼的執行權限 (以及其他所需的權限)。 若為電腦範圍的強制執行，您就可以使用根目錄 Web.config 檔案中的 location 項目，選擇性地指派信任層級。

信任原則檔案的位置和命名慣例

CAS 原則檔案的位置和命名慣例與舊版 ASP.NET 相同。 預設信任層級為 Full、High、Medium、Low 及 Minimal。 定義部分信任權限集合 (High 到 Minimal) 的原則檔案都位於 .NET Framework 安裝目錄的 CONFIG 子目錄中。

這些原則檔案會使用下列模式來命名：

web_[trustlevelname]trust.config

例如，Medium 信任的部分信任權限集合位於名為 web_mediumtrust.config 的檔案中。

ASP.NET 4 信任原則檔案的變更

ASP.NET 4 CAS 原則檔案中的資訊大致上與舊版原則檔案中的資訊相同。 不過，.NET Framework 3.5 和 .NET Framework 4 功能具有次要的新增項目。 與同質性應用程式定義域相關聯的部分信任權限集合名稱為 ASP.Net。 此外，根據預設，位於 Web 應用程式目錄結構或程式碼產生目錄結構中的所有程式碼都會被授與具名 ASP.Net 權限集合中的權限。

舊版部分信任原則檔案具有兩項變更：

• 在每個 ASP.NET 4 CAS 原則檔案的結尾，不再具有將完全信任對應至 Microsoft 簽署金鑰和 ECMA 簽署金鑰的 CodeGroup 項目。 ASP.NET 4 已移除這些項目，因為這些項目是舊版所遺留的項目，而且 GAC 未必隱含假設具有完全信任。

• 所有 ASP.NET 4 CAS 原則檔案都已經移除了 SecurityPermission 屬性的 Assertion 部分。 CLR 在 .NET Framework 4 中所做的基本變更為，部分信任程式碼無法宣告權限。 這表示，即使部分信任程式碼嘗試宣告它已經具有的權限，仍然會失敗。

部分信任的範圍

同質性應用程式定義域是指 ASP.NET 4 應用程式定義域界限受到部分信任。 當應用程式以部分信任執行時，安全性要求會產生堆疊查核行程。 系統會根據要求的權限評估堆疊上的所有程式碼。 在 ASP.NET 3.5 和舊版的應用程式定義域中，讓程式碼路徑一直向上產生堆疊查核行程直到應用程式定義域界限是很常見的情況。 因為在 ASP.NET 4 先前的版本中，應用程式定義域界限隱含為完全信任，所以某些程式碼路徑的堆疊查核行程會成功。 在 ASP.NET 4 同質性應用程式定義域中，任何到達應用程式定義域界限的堆疊查核行程都將根據應用程式定義域目前生效的部分信任權限集合進行評估。

應用程式定義域界限現在本身受到部分信任的事實是最常見的 CAS 變更，而且您通常必須變更完全信任程式碼，才能讓它在 ASP.NET 4 中運作。 例如，ASP.NET 程式開發小組必須在許多內部程式碼路徑上加入目標安全性判斷提示，以便抑制安全性要求並防止它們反昇至應用程式定義域界限。 如果程式開發小組沒有這樣做，頁面編譯等基本工作就會失敗，因為與 Medium 等信任層級的部分信任權限集合比較時，這類作業的安全性要求 (例如，進行編譯的檔案 I/O 權限) 會失敗。

ASP.NET 內部具有許多擴充點，這些擴充點可能會導致完全信任的程式碼在堆疊上只有 ASP.NET 程式碼時載入和執行。 在這些案例中，當 ASP.NET 呼叫實作某種擴充點的自訂型別時，堆疊上一開始只有 ASP.NET 程式碼。 如果自訂型別受到完全信任 (只有當此型別部署於 GAC 時才會發生這種情況)，結果就是整個呼叫堆疊都由完全信任的程式碼所組成。 在同質性應用程式定義域中，如果完全信任之擴充型別中的任何程式碼觸發了安全性要求，該項要求最後將到達應用程式定義域界限。 然後，當系統根據部分信任權限集合進行安全性檢查時，要求將會失敗。

下面將列出可能會發生這種情況的某些 ASP.NET 擴充點：

• 自訂 HTTP 處理常式。 自訂處理常式是在管線的處理常式執行階段中叫用。

• 自訂 HTTP 模組。 自訂 HTTP 模組是在註冊此模組的任何目標管線事件期間叫用。

• 自訂組建提供者和運算式產生器。 當 ASP.NET 剖析和編譯可執行的內容 (例如 .aspx 檔案) 時，就會叫用這些型別。

• 角色管理員提供者。 您可以在管線中的 AuthorizeRequest 事件期間叫用自訂提供者。

• 設定檔提供者。 您可以叫用自訂提供者，以便在 EndRequest 事件期間自動儲存設定檔資料。

• 健康狀態監視提供者。 您可以在任意時間叫用自訂提供者，以便儲存累積的健康狀態監視資料。

自訂 HTTP 提供者的簡單範例即可說明 CAS 行為的變更。 在下列範例中，處理常式程式碼會嘗試讀取位於 C:\ 磁碟機根目錄中的文字檔案。

Public Class CustomHandler 
    Implements IHttpHandler 
    Public Sub ProcessRequest(ByVal context As HttpContext) 
        Dim data As String = File.ReadAllText("c:\testfile.txt") 
        context.Response.Write(data) 
    End Sub 
    
    Public Sub New() 
    End Sub 
    
    Public ReadOnly Property IsReusable() As Boolean 
        Get 
            Return False 
        End Get 
    End Property 
End Class

public class CustomHandler : IHttpHandler

{

public void ProcessRequest(HttpContext context)

{

string data = File.ReadAllText("c:\\testfile.txt");

context.Response.Write(data);

}

public CustomHandler() { }

public bool IsReusable { get { return false; } }

}

如果處理常式已簽署、已使用 AllowPartiallyTrustedCallersAttribute 屬性標記，而且部署於 GAC，當處理常式用於 ASP.NET 3.5 或舊版的中度信任應用程式時，程式碼就會成功。 這個範例選擇了中度信任，因為在中度信任中，部分信任權限集合只允許對應用程式目錄結構進行讀取/寫入檔案 I/O 作業。 完全信任的程式碼 (例如範例處理常式) 則能夠存取 ASP.NET 3.5 和舊版中的其他檔案位置。 這是因為當處理常式執行時，堆疊上只有完全信任的程式碼，而且應用程式定義域界限本身受到完全信任。 因此，完全信任的應用程式定義域界限會隱含滿足來自 ReadAllText 呼叫的檔案 I/O 要求。

不過，如果相同的處理常式程式碼用於中度信任 ASP.NET 4 應用程式，它將會失敗，因為 ReadAllText 的呼叫會產生文字檔案之讀取存取權的檔案 I/O 要求。 檔案 I/O 要求將產生最終到達應用程式定義域界限的堆疊查核行程。 在 ASP.NET 4 中，應用程式定義域界限會與中度信任權限集合相關聯，而且該權限集合不會授與 C:\ 磁碟機根目錄的存取權。 因此，檔案 I/O 要求將會失敗。

在 ASP.NET 4 中，您必須抑制堆疊查核行程。 若要這樣做，請在 ProcessRequest 方法上使用 FileIOPermission 屬性的 SecurityAction.Assert 屬性。 下列範例示範如何針對此目的使用 FileIOPermission 屬性。

[Visual Basic]

Public Class CustomHandler 
    Implements IHttpHandler 

    <FileIOPermission(SecurityAction.Assert, Read = "c:\testfile.txt")> _ 
    Public Sub ProcessRequest(ByVal context As HttpContext) 
        Dim data As String = File.ReadAllText("c:\testfile.txt") 
        context.Response.Write(data) 
    End Sub 
    
    Public Sub New() 
    End Sub 
    Public ReadOnly Property IsReusable() As Boolean 
        Get 
            Return False 
        End Get 
    End Property 
End Class

[C#]

public class CustomHandler : IHttpHandler

{

[FileIOPermission(SecurityAction.Assert, Read = "c:\\testfile.txt")]

public void ProcessRequest(HttpContext context)

{

string data = File.ReadAllText("c:\\testfile.txt");

context.Response.Write(data);

}

public CustomHandler() { }

public bool IsReusable { get { return false; } }

}

您可以使用宣告式判斷提示 (如範例所示) 或程式設計判斷提示。 最佳做法是以宣告方式判斷提示讓程式碼區塊運作所需的最低權限。 雖然在每個位置加入不受限制的安全性判斷提示看起來似乎是簡單的方案，不過您不應該使用這種方式。 設計成新同質性應用程式定義域行為的安全性失敗會要求您分析完全信任程式碼，以及了解完全信任程式碼所需的權限作業。 然後，您可以選擇性地判斷提示重新啟用完全信任程式碼所需的最低權限集合。

將 ASP.NET 4 應用程式設定為使用 ASP.NET 2.0 CAS 模型

您可以將 ASP.NET 4 應用程式設定為使用 ASP.NET 1.0 和 ASP.NET 2.0 CAS 行為。 在 ASP.NET 4 中，trust 項目會提供新的 legacyCasModel 屬性 (預設為 false)。 如果您將此屬性設定為 true，就會將 ASP.NET 4 應用程式設定為使用大部分 (而非所有) 先前版本的 ASP.NET CAS 行為。

當 LegacyCasModel 屬性設定為 true 時，就會發生下列行為：

• 部分信任應用程式定義域界限會使用完全信任。 這表示如果完全信任程式碼執行時，堆疊上只有完全信任程式碼，您就不需要使用判斷提示來抑制安全性要求。

• 針對 .NET Framework 4 所定義的企業、電腦和使用者 CAS 原則設定會與 ASP.NET CAS 原則相交。 這表示使用 .NET Framework 4 caspol.exe 或 Mscorcfg.msc 所建立的任何自訂權限都會生效。

  注意事項
  因為 .NET Framework 4 的基底安全性原則檔案和 caspol.exe 工具與 .NET Framework 2.0 的這些項目位於不同的目錄中，所以您必須使用 .NET Framework 4 版的 caspol.exe，針對 .NET Framework 4 重新建立原本針對 .NET Framework 2.0 所建立的任何自訂安全性原則。

• 您可以指定多個套用至不同組件的自訂權限集合。

下列 CAS 相關的行為不會變更，即使採用舊版 CAS 模式也一樣：

• ASP. NET 4 組件仍然會標示為條件式 APTCA (本主題後面將說明條件式 APTCA)。條件式 APTCA 無法還原成舊版模式，因為它會涉及從大部分公用 ASP.NET 4 API 中移除 AspNetHostingPermission 屬性。 目前沒有有效率的方式可以在 ASP.NET 公用 API 以舊版 CAS 模式執行時，將該權限套用至這些組件，而在這些組件於新的 CAS 模型中執行時不套用該權限。

• 不再允許部分信任程式碼判斷提示任何權限。 先前被授與部分信任的程式碼可以呼叫 Assert 方法，並且成功地判斷提示部分信任程式碼已經被授與的任何權限。 在 .NET Framework 4 中，不論針對 ASP.NET 應用程式生效的 CAS 模型為何，都不再允許部分信任程式碼執行安全性判斷提示。

為了區別在舊版 CAS 模型中套用的權限集合以及在新 CAS 模型中套用的單一權限集合，當 trust 項目的 LegacyCasModel 屬性設定為 true 時，ASP.NET 4 就會從一組不同的部分信任組態檔讀取 CAS 原則。 針對 ASP.NET 內建信任層級存在的每個信任原則檔案都會存在兩種檔案版本。 ASP.NET 會針對新的 CAS 模型讀取其中一種版本，而針對舊版 CAS 模型讀取另一種版本。 例如，對於中度信任而言，當 ASP.NET 4 在舊版模式中執行時，它會讀取名為 legacy.web_mediumtrust.config 的原則檔案。 請注意，此檔案名稱的開頭為 "legacy"。 ASP.NET 4 會針對所有 CAS 原則檔案與內建 ASP.NET 信任層級使用相同的命名慣例。 舊版與非舊版 CAS 原則檔案之間的主要差異在於，舊版檔案包含參考 Microsoft 簽署金鑰和 ECMA 簽署金鑰的 CodeGroup 定義。

因為您可以將應用程式設定為使用舊的 CAS 模型，所以對於現有的應用程式而言，您可能會想要將 LegacyCasModel 選項設定為 true，因而避免進行任何變更。 不過，請務必了解舊版選項存在的主要目的是要簡化將現有應用程式轉換成 ASP.NET 4 CAS 模型的作業。 未來，CLR 和 ASP.NET 小組將著重於使用新的 CAS 模型進行設計和撰寫程式碼。

Silverlight 2 是第一個移至新模型的 .NET Framework 功能範圍。 .NET Framework 的目標是要移動所有桌面和伺服器部分信任案例，以便在新的 CAS 模型上執行。 因此，我們建議您投入將應用程式重新啟用成可在 CAS 模型中運作的工作。 同樣地，先前仰賴 caspol.exe 和 Mscorcfg.msc 的系統管理員應該改為仰賴自訂 ASP.NET 部分信任原則檔案和權限指派。

在 ASP.NET 4 CAS 模型中自訂權限集合指派

雖然 ASP.NET 4 同質性應用程式定義域會將程式碼限制為完全信任或具名的 ASP.NET 部分信任權限集合，不過開發人員和系統管理員可以影響權限集合與組件產生關聯的程序。 下列方式可讓您自訂將權限集合與一段執行中程式碼產生關聯的程序：

• 您可以針對個別信任層級自訂部分信任原則檔案 (舊版 ASP.NET 支援這種方式)。

• 您可以用靜態方式設定 ASP.NET 4 完全信任組件。

• 您可以使用 ASP.NET 4 HostSecurityPolicyResolver 型別，以受條件約束的方式存取 CLR HostSecurityManager 類別的功能。

前兩種方式可讓您以宣告方式進行自訂，而第三種選項可讓您在程式碼中進行自訂。

針對信任層級自訂原則檔案

第一種修改 ASP.NET 部分信任原則檔案的方式與舊版 ASP.NET 的方式相同：您可以在 ASP.NET 具名權限集合中修改權限集合。 您也可以加入其他具有自訂成員資格條件的 CodeGroup 定義。 如先前所述，您必須在 web_mediumtrust.config 等部分信任原則檔案中進行新的 CAS 自訂。 當 trust 項目的 LegacyCasModel 屬性設定為 true 時，系統就會剖析和使用檔案名稱開頭為 "legacy" 的檔案。

對於 ASP.NET 4 而言，所有自訂 CodeGroup 定義都必須對應至三個可能權限集合的其中一個：FullTrust、ASP.Net (亦即，部分信任權限集合) 或 Nothing。 因為 ASP.NET 4 部分信任應用程式定義域預設為同質性，所以自訂原則項目必須評估為一組受條件約束的權限集合。 雖然當您使用 ASP.NET 4 CAS 模型時，似乎可以定義不同的具名權限集合，不過評估為 FullTrust、ASP.Net 或 Nothing 以外之權限集合的任何程式碼都將產生執行階段 SecurityException 例外狀況。 這表示 CLR 無法辨識評估的權限集合。

FullTrust 權限集合表示程式碼會以完全信任執行。 ASP.Net 權限集合是具名的部分信任權限集合，通常用於部分信任應用程式定義域。 如先前所述，Nothing 不是 CLR 所辨識的實際權限集合，而是空的權限集合。 如果 CLR 判斷某個組件與空的權限集合相關聯，CLR 就會擲回 SecurityException 例外狀況，而且 CLR 不會載入該組件。

此外，ASP.NET 4 可讓您使用 trust 項目的 PermissionSetName 屬性來變更 ASP.Net 權限集合的名稱。 您可以針對 PermissionSetName 屬性設定不同的名稱。 在執行階段，ASP.NET 4 會在部分信任原則檔案中搜尋相同名稱的 PermissionSet 項目。 然後，該具名權限集合就會當做同質性應用程式定義域的部分信任權限集合使用。 您通常不需要這樣做。 不過，為了容納將自訂具名權限集合定義為不同於 ASP.NET 預設權限集合之實體的裝載環境 (例如 SharePoint)，我們加入了將部分信任權限集合名稱變更為 ASP.Net 以外之名稱的功能 (請記住，在新的 CAS 模型中，無法再具有多個定義部分信任權限的具名權限集合)。雖然您可以將部分信任權限集合名稱變更為 ASP.Net 以外的名稱，不過仍然只有一個部分信任權限集合會針對應用程式生效。

指定將被授與完全信任的組件

第二種宣告式原則自訂是 ASP.NET 4 新增的功能，可讓您明確建立一定會被授與完全信任的組件識別清單。 securityPolicy 組態包含新的子 fullTrustAssemblies 組態區段。 FullTrustAssembliesSection 區段是支援加入、移除和清除作業的標準集合，而且您可以在此區段中指定一個或多個將在執行階段被授與完全信任的組件識別。 下列範例將顯示 fullTrustAssemblies 組態區段。

<system.web>

<securityPolicy>

<fullTrustAssemblies>

<add assemblyName="MyCustomAssembly"

version="1.0.0.0"

publicKey="a 320 hex character representation

of the public key blob used with a

signed assembly"

/>

</fullTrustAssemblies>

</securityPolicy>

</system.web>

fullTrustAssemblies 項目中的每個項目都會依照其組件名稱和組件版本識別組件，並且依照 320 個字元的字串 (簽署金鑰中公用部分的十六進位字元表示) 識別組件。

注意事項
未來，新的 .NET Framework 組件可能會使用 2048 位元簽署金鑰。如果發行了使用 2048 位元簽署金鑰的新組件，就會產生長度為 576 個字元的十六進位字串。

此定義中沒有指定任何組件位置。 個別裝載環境 (例如 ASP.NET 4) 可自行決定是否要尋找並載入組件。 如果載入的組件符合 fullTrustAssemblies 中其中一個 add 項目所包含的資訊，該組件就會被授與完全信任。

若為沒有部署於 GAC 但是想要永遠以完全信任執行的組件，您就應該使用 fullTrustAssemblies。 因為您可以在組態階層架構 (從根目錄 Web.config 檔案到個別應用程式層級 Web.config 檔案) 中的任何一點自訂 fullTrustAssemblies 中所列的組件，所以使用這項設定來授與完全信任會比在部分信任原則檔案中使用成員資格條件和程式碼群組更簡單且更有彈性。 您可以針對不同的應用程式指定不同的資訊，藉以自訂個別應用程式的 fullTrustAssemblies 清單。 您可以使用 location 項目，在應用程式層級 Web.config 檔案或根目錄 Web.config 檔案中進行此作業。

當您建立部分信任應用程式定義域時，就會立即建立完全信任組件的集合。 因此，如果部分信任原則檔案所包含的資訊會針對 fullTrustAssemblies 項目中所列的組件產生不同的授權集，系統就會忽略這項資訊，而且該組件會被授與完全信任。

以程式設計方式自訂權限

您也可以透過建立 ASP.NET 4 HostSecurityPolicyResolver 型別的自訂實作，以程式設計方式變更權限集合與組件的關聯。 在執行階段，ASP.NET 4 會使用其 CLR HostSecurityManager 型別的自訂實作。 每次載入組件時，CLR 就會呼叫 HostSecurityManager 物件。 HostSecurityManager 屬性的其中一項功能就是傳回應該與指定之組件相關聯的 PermissionSet 物件以及代表辨識項集合。 每次 CLR 要求 ASP.NET 4 進行權限集合決策時，ASP.NET 4 可讓您透過呼叫自訂 HostSecurityPolicyResolver 物件，自訂此程序。

您可以使用 trust 項目的 HostSecurityPolicyResolverType 屬性來設定自訂 HostSecurityPolicyResolver 物件。 如果 ASP.NET 4 決定要針對應用程式設定自訂 HostSecurityPolicyResolver 物件，每次 CLR 要求進行權限集合決策時，它就會呼叫自訂解析程式的 ResolvePolicy 方法。 不過，與 HostSecurityManager 物件不同的是，HostSecurityPolicyResolver 物件只能將一組受條件約束的可能決策傳回給 ASP.NET 4。 ResolvePolicy 方法傳回值必須是 HostSecurityPolicyResults 列舉的下列其中一個值：

• DefaultPolicy. 這個值會指定 ASP.NET 4 應該使用其自訂邏輯來決定組件的適當權限集合。 若為您不想要讓 HostSecurityPolicyResolver 物件進行權限集合之相關決策的組件，您就應該傳回 DefaultPolicy。 傳回 DefaultPolicy 會導致 ASP.NET 根據目前 ASP.NET 信任層級之部分信任原則檔案中定義的宣告式程式碼群組和成員資格條件決定組件的權限授權集。

• FullTrust. 此組件應該被授與完全信任。

• AppDomainTrust. 此組件應該被授與部分信任權限集合，而且該集合與應用程式定義域相關聯。 通常這就表示此組件將被授與具名 ASP.Net 權限集合中定義的權限。

• None. 此組件的權限集合將設定為 Nothing 權限集合，而這是

因為基底 HostSecurityPolicyResolver 類別具有不受限制安全性權限的繼承要求，而且自訂 HostSecurityPolicyResolver 物件必須是可載入的物件，而不需要使用另一個 HostSecurityPolicyResolver 物件來建立完全信任，所以 HostSecurityPolicyResolver 類別的具象實作應該一律經過簽署且部署於 GAC。

下列範例將顯示自訂 HostSecurityPolicyResolver 物件，這個物件會將完全信任授與從特定目錄載入的所有組件。 這個案例可能適用於在磁碟上的特定位置 (而非 GAC) 中加入已編譯組件，而且想要讓該位置的所有檔案都自動以完全信任執行的組織。 為了讓 ASP.NET 應用程式能夠從 Web 應用程式的目錄結構外部載入組件，您必須加入明確的組件繫結重新導向，以便將組件識別與不同的實體磁碟位置產生關聯。

[Visual Basic]

Public Class MyCustomResolver 
    Inherits HostSecurityPolicyResolver 
    Public Overloads Overrides Function ResolvePolicy(ByVal evidence _
            As Evidence) As HostSecurityPolicyResults 
        Dim urlEvidence As Url = evidence.GetHostEvidence(Of Url)() 
        
        If (urlEvidence IsNot Nothing) AndAlso _
            (urlEvidence.Value.StartsWith("file:///C:/FullTrustExample_HSPR.dll")) Then 
            Return HostSecurityPolicyResults.FullTrust 
        End If 
        
        ' Specify that ASP.NET should perform its own logic.
        Return HostSecurityPolicyResults.DefaultPolicy 
    End Function 
End Class

public class MyCustomResolver : HostSecurityPolicyResolver
{ 
  public override HostSecurityPolicyResults 
                              ResolvePolicy(Evidence evidence)
  {
            Url urlEvidence = evidence.GetHostEvidence<Url>();
            if ( (urlEvidence != null)  && 
                 (urlEvidence.Value.StartsWith("file:///C:/FullTrustExample_HSPR.dll"))
               )
                return HostSecurityPolicyResults.FullTrust;

            // Specify that ASP.NET should perform its own logic.
            return HostSecurityPolicyResults.DefaultPolicy;
  }
}

條件式 APTCA

在 .NET Framework 4 之前的版本中，許多完全信任的組件 (包括 ASP.NET 組件) 都以 AllowPartiallyTrustedCallersAttribute (APTCA) 屬性標示。 這個屬性可讓部分信任呼叫端存取以這種方式標示之組件中定義的公用型別和成員。 在 .NET Framework 4 中，CLR 包含稱為「條件式 APTCA」(Conditional APTCA) 的 APTCA 變體 (條件式 APTCA 的簡略標記法為 C-APTCA)。條件式 APTCA 可讓使用 APTCA 屬性標示的組件，只在特定裝載環境中保留 APTCA 特性。 因此，條件式 APTCA 可讓 ASP.NET 4 更輕易地精確控制部分信任呼叫端能夠在哪些部分信任主機環境中成功呼叫公用 ASP.NET 4 API。

條件式 APTCA 的運作方式

部分信任主機環境與部分信任的組件都在讓條件式 APTCA 運作中扮演重要的角色。 權限集合很重要的部分信任主機環境可以將應該永遠讓其 APTCA 設定被接受的組件清單提供給 CLR。 應該讓其 APTCA 特性只在特定主機環境中啟用的完全信任組件會使用組件層級 APTCA 屬性的下列變體來表示這點：

[assembly: AllowPartiallyTrustedCallers(PartialTrustVisibilityLevel=NotVisibleByDefault)]

在執行階段，當系統要求 CLR 載入標示為條件式 APTCA 的組件時，CLR 將會檢查主機環境所提供的有效條件式 APTCA 組件清單。 如果該組件位於清單中，CLR 就會將組件中的所有公開程式碼視為已經使用舊版 .NET Framework 中之 APTCA 屬性標示的組件。

如果條件式 APTCA 組件不在應該被視為 APTCA 的主機環境組件清單上，系統仍然會載入該組件，但是不會載入其 APTCA 特性。 公用 API 對於這類組件中之部分信任使用者程式碼的實際可用性會因組件是否為 100% 安全性透明而異。 也就是說，其可用性主要取決於組件是否使用組件層級 SecurityTransparentAttribute 屬性來標示 (本主題後面的章節將說明 ASP.NET 4 中的安全性透明度)。

總而言之，ASP.NET 4 中的公用 API 可能具有下列其中一種行為：

• 對於大部分的 ASP.NET 組件而言，所有公用 API 都會變成無法供部分信任呼叫端使用。 實際上，這會讓 ASP.NET 4 中的大多數公用 API 無法用於 Web 應用程式以外的任何部分信任環境中。

• 標示為 100% 安全性透明的少數 ASP.NET 組件仍然可從部分信任呼叫端呼叫。 不過，如果這些組件中的程式碼路徑最後會到達 ASP.NET 程式碼基底的其餘部分，呼叫就會失敗。 此結果與舊版 ASP.NET 的行為相同，其些微差異之處在於，ASP.NET 4 組件中 API 的呼叫會在失敗之前進一步執行。

  請注意下列標示為安全性透明之組件的相關資訊：

  • 在組件層級中，只有兩個標示為安全性透明的 ASP.NET 組件：System.Web.DynamicData.dll 和 System.Web.RegularExpressions.dll。

  • 在 ASP.NET 4 中，System.Web.Routing.dll 不會被視為 100% 安全性透明，因為在舊版 ASP.NET 中定義於該組件的所有型別都已經移入 System.Web.dll。 實際上，在 ASP.NET 4 中，System.Web.Routing.dll 是只有中繼資料的組件。

在 ASP.NET 4 中，條件式 APTCA 屬性變體位於下列組件上：

• System.Web.dll

• System.Web.Extensions.dll

• System.Web.DynamicData.dll

• System.Web.DataVisualization.dll

• System.ComponentModel.DataAnnotations.dll

• System.Web.ApplicationServices.dll。 這個組件是 ASP.NET 4 新增的組件。

• System.Web.Abstractions.dll。 這個組件中的型別已經移至 ASP.NET 4 的 System.Web.dll。

• System.Web.Routing.dll。 這個組件中的型別已經移至 ASP.NET 4 的 System.Web.dll。

條件式 APTCA 與 ASP.NET 裝載權限屬性

條件式 APTCA 實際上已經從 99% 的 ASP.NET 4 公用 API 中移除了 AspNetHostingPermission 屬性。 AspNetHostingPermission 屬性仍然用於 ASP.NET 4 中的某些位置，不過僅限於權限目的真正有意義的位置。 AspNetHostingPermission 屬性的下列兩種用法不會出現在其他位置：

<AspNetHostingPermission(SecurityAction.LinkDemand,
                         Level=AspNetHostingPermissionLevel.Minimal)>
<AspNetHostingPermission(SecurityAction.InheritanceDemand,
                         Level=AspNetHostingPermissionLevel.Minimal)>

[AspNetHostingPermission(SecurityAction.LinkDemand,
                         Level=AspNetHostingPermissionLevel.Minimal)]
[AspNetHostingPermission(SecurityAction.InheritanceDemand,
                         Level=AspNetHostingPermissionLevel.Minimal)]

這些權限定義原本用於舊版 ASP.NET 是為了防止 ASP.NET 組件載入非 Web 部分信任環境中。 最大的考量環境為載入 Microsoft Internet Explorer 和 Mozilla Firefox 等瀏覽器中的部分信任 Managed 控制項和 Managed 應用程式。 透過使用條件式 APTCA，您實際上也強制執行相同的保護，因為 ClickOnce 應用程式和瀏覽器架構的 Managed 控制項不會定義任何條件式 APTCA 組件，以便視為完整 APTCA。

自訂 ASP.NET 4 條件式 APTCA 清單

如先前所述，個別主機環境可以將系統應該接受其 APTCA 特性的條件式 APTCA 組件清單套用至 CLR。 ASP.NET 4 會將硬式編碼清單提供給包含所有 ASP.NET 4 組件的 CLR。 如果 ASP.NET 4 沒有這樣做，當 ASP.NET 內部程式碼的第一行嘗試在部分信任應用程式定義域中執行時，Web 應用程式就會立即失敗。

在 .NET Framework 4 中，條件式 APTCA 是一項新的 CAS 概念，尚未實作於 .NET Framework 的其他部分。 因此，未來的 .NET Framework 版本可能會包含更多條件式 APTCA 組件。 此外，當您逐漸了解條件式 APTCA 並且將它用於您自己的完全信任組件時，條件式 APTCA 組件的集合將會成長。 因為 ASP.NET 4 無法事先知道所有可能的條件式 APTCA 組件，所以 ASP.NET 4 包含了可加入條件式 APTCA 組件的組態區段。

現有的 securityPolicy 區段具有名為 partialTrustVisibleAssemblies 的子組態區段。 這是支援加入、移除和清除作業的標準集合，而且您可以在此區段中指定一個或多個應該被視為 APTCA 的組件識別 (如果它們也標示為條件式 APTCA 的話)。 下列範例顯示 partialTrustVisibleAssemblies 區段。

<system.web>
  <securityPolicy>
    <partialTrustVisibleAssemblies>

      <add assemblyName="MyCustomAssembly"
           publicKey="a 320 hex character representation 
                      of the public key blob used with a 
                      signed assembly"
      />

    </partialTrustVisibleAssemblies>
  </securityPolicy>
</system.web>

partialTrustVisibleAssemblies 區段中的每個項目都會依照組件名稱識別組件。 此外，每個項目也會依照 320 個字元的字串 (例如 0x03FA4D...) 來識別，這個字串是用於條件式 APTCA 屬性組件之簽署金鑰中公用部分的十六進位字元表示。 您不需要指定版本屬性。 CLR 只需要組件名稱和公開金鑰語彙基元。

當您啟用條件式 APTCA 組件時，重要的效能影響在於您也應該啟用條件式 APTCA 組件的遞移封閉。 例如，如果條件式 ATPCA 組件 A 相依於 APTCA 組件 B，而且 APTCA 組件 B 又相依於條件式 ATPCA 組件 C，當您針對 A 啟用條件式 ATPCA 時，也應該針對 C 啟用條件式 APTCA。 否則，應用程式的效能可能會受到影響。 例如，如果您沒有啟用完整條件式 ATPCA 封閉，系統就會停用程式碼共用和 NGen 映像。

條件式 APTCA 如何影響非 Web 部分信任應用程式

在 ASP.NET 4 之前的 ASP.NET 版本中，某些型別和命名空間不會使用 AspNetHostingPermission 屬性來標示。 這可讓您從 ClickOnce 應用程式等非 ASP.NET 部分信任環境呼叫這些型別。 可用這種方式呼叫的型別和命名空間如下：

• System.Web.ClientServices 命名空間中的型別。

• System.Web.ClientServices.Providers 命名空間中的型別。

• HttpUtility 型別。

System.Web.ClientServices 型別無法用於 ClickOnce 等 .NET Framework 4 部分信任環境中。 因為包含的組件 (System.Web.Extensions.dll) 是標示為條件式 APTCA 的 ASP.NET 4 組件，而且 ClickOnce 不允許任何條件式 APTCA 組件的 APTCA，所以無法從部分信任 ClickOnce 應用程式呼叫任何用戶端服務型別。

造成這種行為的原因有幾個。 首先，.NET Framework 4 已經分割成用戶端和擴充的 SKU，而且假設許多 ClickOnce 應用程式都以用戶端 SKU 為目標。 您必須進行一些基本工作，將 ASP.NET 用戶端服務型別重構成用戶端 SKU。

其次，判斷如何重構用戶端型別，同時維持必要的條件式 APTCA 界限，實屬複雜。 因此，在 .NET Framework 4 中，用戶端服務型別只會提供給非 ASP.NET 完全信任環境使用，包括設定為使用擴充 .NET Framework 4 SKU 以完全信任執行的 ClickOnce 應用程式。

對於 HttpUtility 型別而言，條件式 APTCA 的作用主要取決於您所使用的方法，如下列案例所示：

• 部分信任程式碼正在呼叫 WebUtility 類別的 HtmlEncode 或 HtmlDecode 方法。 WebUtility 型別包含 ASP.NET HTML 編碼和解碼實作，但是這些實作已經重構並移入 System.dll 所包含的 System.Net 命名空間中。 因為 System.dll 可用於所有部分信任主機環境，所以存取非 ASP.NET 部分信任應用程式之 WebUtility 型別的方法不會發生任何問題。

• 部分信任程式碼正在呼叫 WebUtility 類別的任何其他方法。 在該情況下，則適用先前針對用戶端服務型別所描述的相同問題。 也就是說，WebUtility 只會提供給 .NET Framework 4 中的非 ASP.NET 完全信任呼叫端使用。

ASP.NET 4 中的安全性透明度

安全性透明度可讓您向 CLR 指出某個程式碼區塊是否將執行安全性敏感作業。 透明的程式碼永遠無法判斷提示權限、滿足連結要求、包含無法驗證的程式碼、呼叫機器碼或呼叫安全性關鍵程式碼。 不論透明的程式碼受完全信任 (例如，位於 GAC 中) 或受部分信任，這點都成立。

安全性透明度是 ASP.NET 等 .NET Framework 功能的一項強大功能。 它可讓 ASP.NET 向 CLR 指出部分 ASP.NET 程式碼絕對不會判斷提示權限，而且程式碼絕對不會實作或執行安全性敏感作業，例如機器碼的 PInvoke 呼叫。 如此一來，.NET Framework 程式碼就可以大幅減少大量公用和內部 API 的安全性暴露，即使 .NET Framework 程式碼位於完全信任的 GAC 中也一樣。

安全性透明度可以套用至整個組件或只套用至組件中的程式碼子集。 雖然將整個組件標示為安全性透明是理想的情況，不過 .NET Framework 程式碼中的某些程式碼具有執行安全性敏感工作的合法需求。 包含 100% 安全性透明程式碼的組件會使用組件層級 SecurityTransparentAttribute 屬性來標示。

包含透明與非透明程式碼混合的組件沒有組件層級透明度屬性。 不過，此組件中的個別類別可以使用 SecuritySafeCriticalAttributel 屬性或 SecurityCriticalAttribute 屬性來標示。

無屬性類別的行為很複雜。 不過，簡而言之，ASP.NET 4 組件中已經採用新透明度模型的無屬性型別會被視為安全性透明的型別。 ASP.NET 4 組件中無屬性而且尚未採用新透明度模型的型別會被視為安全性安全關鍵的型別。

實際的安全性透明度以及安全性規則集

因為 ASP.NET 4 程式碼基底的許多部分都位於 System.Web.dll 中，所以將所有 ASP.NET 4 程式碼都轉換成新的透明度模型並不實際。 不過，您可以將 ASP.NET 4 程式碼分割成下列分類：

• 不採用新透明度模型的程式碼，包括下列組件中的程式碼：

  • System.Web.dll

  • System.Web.ApplicationServices.dll

  • System.Web.Mobile.dll。 在 ASP.NET 4 中，這個組件中的型別標示為已過時。 即使該組件仍然存在，我們還是希望您隨著時間停止使用這個組件中的型別。

• 採用新透明度模型的程式碼，包括下列組件中的程式碼：

  • System.Web.Extensions.dll

  • System.Web.DynamicData.dll (100% 安全性透明)

  • System.Web.RegularExpressions.dll (100% 安全性透明)

  • System.ComponentModel.DataAnnotations.dll

  • System.Web.DataVisualization.dll

• 只有中繼資料而且其型別都已經移入不同 ASP.NET 組件的組件，包括下列組件：

  • System.Web.Abstractions.dll。 在舊版 ASP.NET 中位於這個組件中的型別已經移至 System.Web.dll。 因此，在 ASP.NET 4 中，Sytem.Web.Abstractions.dll 是只有中繼資料的組件。

  • System.Web.Routing.dll。 在舊版 ASP.NET 中位於這個組件中的型別已經移至 System.Web.dll。 因此，在 ASP.NET 4 中，System.Web.Routing.dll 是只有中繼資料的組件。

在 .NET Framework 4 中，CLR 導入了稱為安全性規則集的新概念。 SecurityRuleSet 組態具有兩個層級：層級一和層級二。 所有型別的 SecurityRuleSet 組態都是使用 SecurityRulesAttribute 組件層級屬性來指定的。 採用新透明度模型的 ASP.NET 4 組件會使用下列組件層級屬性來標示：

System.Security.SecurityRules(RuleSet=System.Security.SecurityRuleSet.Level2)

使用 .NET Framework 2.0 中之透明度模型 (對於 ASP.NET 而言，實際上就表示沒有透明度，因為 ASP.NET 4 之前的 ASP.NET 從未使用過透明度概念) 的 ASP.NET 4 組件會使用下列組件層級屬性來標示：

System.Security.SecurityRules(RuleSet=System.Security.SecurityRuleSet.Level1)

若為採用了新透明度模型的 ASP.NET 組件 (以及位於組件中的公用型別)，大多數程式碼都會被視為安全性透明。 不過，這些組件中的少數程式碼會執行安全性敏感作業，而且該程式碼會標示為安全關鍵或關鍵程式碼。

若為不採用新透明度模型的 ASP.NET 組件 (不考慮已過時或型別重新導向的組件)，所有公用 API 都可以從部分信任使用者程式碼呼叫，而且可以在內部執行安全性敏感作業。 由於存在部分信任呼叫端的開放存取權以及安全性敏感作業的可能性，因此表示舊版 ASP.NET 4 程式碼需要進行深入的檢查。 不過，因為大部分新的 ASP.NET 功能都是在 System.Web.Extensions.dll 和 System.Web.DynamicData.dll 等較新的組件中實作或在 ASP.NET MVC 等不同的版本中實作，所以大部分新的 ASP.NET 程式碼都是安全性透明的，因此預設會比舊版程式碼更安全。

根據預設，CLR 會將標示為 SecurityRuleSet.Level1 之所有 ASP.NET 4 組件的公用 API 視為安全關鍵 (亦即，相當於使用 SecuritySafeCriticalAttribute 屬性來標示)，只要裝載環境接受此 APTCA 屬性即可。 如果不接受 APTCA，CLR 就會觸發完全信任的連結要求，不過當堆疊上存在任何部分信任使用者程式碼時，這項作業將會失敗。 換言之，當環境不接受標示為 SecurityRuleSet.Level1 之 ASP.NET 組件的 APTCA 時，如果部分信任程式碼嘗試呼叫沒有使用 APTCA 屬性來標示的完全信任組件，您就看見與舊版 .NET Framework 相同的行為。

根據預設，CLR 會將標示為 SecurityRuleSet.Level2 之所有 ASP.NET 4 組件的公用 API 視為安全性透明 (亦即，相當於使用 SecurityTransparentAttribute 來設定屬性)，只要裝載環境接受此 APTCA 屬性即可。 否則，就會定義下列行為：

• 如果不接受 APTCA 而且標示為 Level2 的組件不是 100% 安全性透明，則 CLR 就會將公用介面區視為安全性關鍵。 因此，任何嘗試使用公用介面區的部分信任呼叫端都可能會失敗，並發生 MethodAccessException、TypeAccessException 或 FieldAccessException 例外狀況。

• 如果不接受 APTCA 而且標示為 Level2 的組件是 100% 安全性透明，則部分信任呼叫端就能夠成功呼叫該組件中的任何公用 API。 實際上，這就表示當 100% 安全性透明組件中的程式碼最後呼叫不是 100% 安全性透明的層級 1 ASP.NET 組件或層級 2 ASP.NET 組件時，呼叫路徑之後會發生 SecurityException 例外狀況。

透明度和 ASP.NET 編譯

ASP.NET 編譯系統所建立的輸出也會受到 ASP.NET 4 採用的新 CAS 模型和新安全性透明度模型所影響。 這包括一些項目，例如頁面組件、先行編譯的組件，以及 App_Code 目錄的已編譯結果。 此編譯系統會根據 trust 項目之 LegacyCasModel 屬性的設定改變其行為。

下表將說明如何在舊版 CAS 模型和新版 CAS 模型中標示動態編譯的物件。

legacyCasModel 屬性設定	網站信任層級	套用至已編譯組件的屬性
False (新 CAS 模型)	完全信任	SecurityRules(SecurityRuleSet.Level2)
	高度信任或更低	SecurityRules(SecurityRuleSet.Level2)
SecurityRules(SecurityRuleSet.Level2)
True (舊 CAS 模型)	完全信任	SecurityRules(SecurityRuleSet.Level1)
	高度信任或更低	SecurityRules(SecurityRuleSet.Level1)

因為 ASP.NET 4 編譯系統會根據 trust 項目之 LegacyCasModel 屬性的設定改變其行為，所以如何在不同的部分信任 ASP.NET 4 應用程式之間共用已編譯的程式碼可能會有所限制。 一般而言，您應該不會看見應用程式行為的任何變更。 不過，在某些案例中，當 LegacyCasModel 屬性設定為 false (亦即，使用新 CAS 模型) 之部分信任應用程式所建立的已編譯成品搭配其他應用程式使用時，這些成品無法如預期方式運作。 因此，對於某些案例 (例如，已簽署、設定 ATPCA 屬性而且部署於 GAC 之已編譯 .ascx 控制項的共用程式庫) 而言，當此程式庫是使用 Level2 來標示時，您可能必須將安全關鍵和關鍵屬性明確套用至部分程式碼。

請參閱

其他資源

裝載環境中 ASP.NET 應用程式的安全性