本單元內容

功能 ASP.NET 應用程式依賴於許多不同元素及技術的成功交互操作。每個方案元件都提供安全性功能，以滿足其自身的需求。然而，純粹從個別元件的角度考量安全性還不夠。若要提供整體方案的安全性，您還必須考量元件如何彼此互動。

本單元介紹 .NET Web 應用程式架構及安全性，提供本手冊其他單元補充的參考框架。並提供涵蓋典型 .NET Web 應用程式各層的安全性功能和服務的概觀。它還介紹了 .NET Framework 安全性，並說明哪些元素對於 ASP.NET Web 應用程式開發(fā)人員最為重要。

回到頁首

目標

透過此單元即可：

?	瞭解 .NET Web 應用程式架構的主要技術，以及邏輯及實體應用程式層的概念。
?	瞭解用於建置 .NET Web 應用程式的每項實作技術提供了哪些安全性功能，以及這些功能如何一同運作。
?	開始瞭解 .NET Framework 安全性功能，並瞭解哪些元素對於 Web 應用程式安全性最為重要。
?	比較對照用於 Web 應用程式的授權及驗證機制。
?	瞭解 .NET Web 應用程式如何使用原則及身分識別物件。
?	識別應用程式中可以用來強制信任界限的 Gatekeeper 及閘道。

回到頁首

適用於

本單元適用於下列產品及技術：

?	Windows XP 或 Windows 2000 Server 及更新的作業(yè)系統(tǒng)
?	Internet Information Services (IIS)
?	.NET Framework 1.0 版及更新版本

回到頁首

如何使用本單元

若要充分瞭解此單元：

?	您必須具有開發(fā) ASP.NET Web 應用程式的經驗。這可以協助您瞭解單元中所討論的各種安全性元素在何處與應用程式整合。
?	請閱讀第 1 單元＜簡介＞。其在強調驗證、授權及安全通訊對於建立安全分散式 Web 應用程式的重要性。同時也指出開發(fā)安全 Web 應用程式時應採用的主要原則及實務。

回到頁首

.NET Web 應用程式

本節(jié)簡短介紹 .NET Web 應用程式，並從邏輯和實體觀點說明它的特性。此外，還介紹各種用來建置 .NET Web 應用程式的實作技術。

邏輯層

邏輯應用程式架構把任何系統(tǒng)均視為由下列各層組成的合作服務集合：

?	使用者服務
?	商業(yè)服務
?	資料服務

邏輯架構觀點的價值在於識別任何系統(tǒng)一般固定的服務類型、提供適當的分段，以及定義層與層之間的介面。分段能讓您在實作各層時製作更周密的架構和設計選項，並建置更好維護的應用程式。

各層介紹如下：

?	「使用者服務」負責用戶端與系統(tǒng)的互動，並提供連接到由「商業(yè)服務」層元件所封裝的核心商務邏輯的共通橋樑。以往「使用者服務」經常與互動式使用者有關聯。但也會初始處理其他系統(tǒng)的程式設計要求 (不涉及可見的使用者介面)。驗證及授權 (其精確的本質，取決於用戶端類型)，通常在「使用者服務」層中執(zhí)行。
?	「商業(yè)服務」提供系統(tǒng)核心功能，並會封裝商務邏輯。這些服務與傳送通道和後端系統(tǒng)或資料來源互不相關。因此其所提供的穩(wěn)定性和彈性，得以讓系統(tǒng)支援其他的新通道和後端系統(tǒng)。服務特定商業(yè)要求時，通常需要「商業(yè)服務」層中的許多合作元件。
?	「資料服務」可透過一般介面存取資料 (裝載於系統(tǒng)界限內) 和其他 (後端) 系統(tǒng)，這種方式便於由「商業(yè)服務」層中的元件使用。「資料服務」會摘要出大多數的後端系統(tǒng)和資料來源，並且將特定的存取規(guī)則和資料格式封裝起來。

系統(tǒng)服務類型的邏輯分類可能與實作服務元件的實體分佈相互關聯，但是彼此之間則相互獨立。

請記得您可以在任何彙總層級中識別邏輯層，亦即可以識別出整個系統(tǒng) (在其環(huán)境和與外部互動的內容中) 或內含的任何子系統(tǒng)中的各層，這點十分重要。例如，每個裝載 Web 服務的遠端節(jié)點都包含「使用者服務」(處理傳入要求和訊息)、「商業(yè)服務」和「資料服務」。

實體部署模型

前述三個邏輯服務層，並不代表特定數目的實體層。這三個邏輯服務實際上可能都在同一臺電腦上，但也可能分散在多臺電腦上。

網頁伺服器作為應用程式伺服器

.NET Web 應用程式的一般部署模式是將商業(yè)和資料存取元件放在網頁伺服器上。這能減少網路躍點，以提高效能。圖 2.1 顯示這個模型。

圖 2.1
網頁伺服器作為應用程式伺服器

遠端應用程式層

遠端應用程式層為一般部署模式，尤其是對 Web 層能在周邊網路 (又稱為 DMZ、非軍事區(qū)域和過濾子網路) 中獨立運作的網際網路案例而言，它使用封包篩選防火牆來與使用者和遠端應用程式層分隔開。圖 2.2 顯示遠端應用程式層。

圖 2.2
遠端應用程式層簡介

回到頁首

實作技術

.NET Web 應用程式通常使用下列技術，實作一或多個邏輯服務：

?	ASP.NET ASP.NET 通常用來實作「使用者服務」。ASP.NET 提供的可插入式架構，可用來建置網頁。在第 8 單元＜ASP.NET 安全性＞中詳細討論了 ASP.NET 安全性。
?	Enterprise Services Enterprise Services 為應用程式提供基礎結構層次的服務。其中包含分散式交易和資源管理服務，例如 .NET 元件的物件集區(qū)。在第 9 單元＜Enterprise Services 安全性＞中詳細討論了 Enterprise Services 安全性。
?	Web 服務 「Web 服務」可以使用 SOAP 式訊息交換，將資料穿越防火牆和在異質性系統(tǒng)之間移動，以交換資料和遠端呼叫應用程式邏輯。在第 10 單元＜Web 服務安全性＞中詳細討論了「Web 服務」安全性。
?	.NET 遠端處理 「.NET 遠端處理」提供的架構可以跨越處理序和電腦界限存取分散式物件。在第 11 單元＜.NET 遠端處理安全性＞中詳細討論了「.NET 遠端處理」安全性。
?	ADO.NET 及 Microsoft? SQL Server? 2000 ADO.NET 提供資料存取服務。它從一開始就是為分散式 Web 應用程式設計的，並具有對與 Web 應用程式有關的連線中斷狀況的豐富支援。SQL Server 提供使用作業(yè)系統(tǒng)驗證機制 (Kerberos 或 NTLM) 的整合式安全性。授權是由可套用到個別資料庫物件的登入和細部權限所提供的。在第 12 單元＜資料存取安全性＞中詳細討論了資料存取安全性。
?	網際網路通訊協定安全性 (IPSec) IPSec 提供點對點、傳輸層級加密和驗證服務。若需 IPSec 的相關資訊，請參閱第 4 單元＜安全通訊＞。
?	安全通訊端層 (SSL) SSL 提供點對點安全通訊通道。透過通道傳送的資料，都會經過加密。若需 SSL 的相關資訊，請參閱第 4 單元＜安全通訊＞。

回到頁首

安全性架構

圖 2.3 顯示遠端應用程式層模型，以及前述各種技術所提供的安全性服務集合。驗證及授權會發(fā)生在各層的許多個別點上。這些服務主要是由 Internet Information Services (IIS)、ASP.NET、Enterprise Services 和 SQL Server 提供的。安全通訊通道也可套用到各層，並從用戶端瀏覽器或裝置一直伸展到資料庫。結合「安全通訊端層 (SSL)」或 IPSec 以確保通道的安全。

圖 2.3
安全性架構

各層間的安全性

表 2.1 摘要出前述技術所提供的驗證、授權和安全通訊功能。

表 2.1：安全性功能

技術	驗證	授權	安全通訊
IIS	匿名 基本 摘要 Windows 整合式 (Kerberos/NTLM) 憑證	IP/DNS 位址 限制 Web 使用權限 NTFS 使用權限； 要求檔案的 Windows 存取 控制清單 (ACL)	SSL
ASP.NET	無 (自訂) Windows 表單 Passport	檔案授權 URL 授權 主體使用權限 .NET 角色	?
Web 服務	Windows 無 (自訂) 訊息層級 驗證	檔案授權 URL 授權 主體使用權限 .NET 角色	SSL 及訊息 層級加密
遠端處理	Windows	檔案授權 URL 授權 主體使用權限 .NET 角色	SSL 及訊息 層級加密
Enterprise Services	Windows	Enterprise Services (COM+) 角色 NTFS 使用權限	遠端程序 呼叫 (RPC) 加密
SQL Server 2000	Windows (Kerberos/NTLM) SQL 驗證	伺服器登入 資料庫登入 固定資料庫角色 使用者定義的角色 應用程式角色 物件使用權限	SSL
Windows 2000	Kerberos NTLM	Windows ACL	IPSec

驗證

Windows 2000 上的 .NET Framework 提供下列驗證選項：

?	ASP.NET 驗證模式
?	Enterprise Services 驗證
?	SQL Server 驗證

ASP.NET 驗證模式

ASP.NET 驗證模式包含 Windows、「表單」、Passport 和「無」。

?	Windows 驗證。在這種驗證模式中的 ASP.NET 依靠 IIS 來驗證使用者，並建立 Windows 存取語彙基元來代表驗證的身分識別。IIS 提供下列驗證機制： ? 基本驗證。「基本」驗證要求使用者以使用者名稱和密碼的形式提供憑證，來證明其身分識別。這個建議的網際網路標準是依據 RFC 2617：http://www.faqs.org/rfcs/rfc2617.html。Netscape Navigator 和 Microsoft Internet Explorer 都支援「基本」驗證。使用者的憑證是以未加密的 Base64 編碼格式，從瀏覽器傳輸到網頁伺服器。由於網頁伺服器獲有未加密的使用者憑證，因此網頁伺服器能以使用者憑證發(fā)出遠端呼叫 (例如，存取遠端電腦和資源)。 注意：「基本」驗證應僅與安全通道 (通常使用 SSL 建立) 搭配使用。否則，很容易使用網路監(jiān)視軟體盜取使用者名稱和密碼。如果使用「基本」驗證，則應該在所有網頁 (不僅是登入網頁) 上使用 SSL，因為所有後續(xù)要求都會傳遞憑證。若需以 SSL 使用「基本」驗證的相關資訊，請參閱第 8 單元＜ASP.NET 安全性＞。 ? 摘要驗證。IIS 5.0 所提供的「摘要」驗證類似於「基本」驗證，但它從瀏覽器傳送到網頁伺服器的是憑證的雜湊，而非未加密的使用者憑證。因此它的安全性更高，但是需要 Internet Explorer 5.0 或更新版本的用戶端和特定的伺服器設定。 ? 整合式 Windows 驗證。「整合式 Windows」驗證 (Kerberos 或 NTLM，取決於用戶端和伺服器設定) 使用加密的資訊和使用者的 Internet Explorer Web 瀏覽器交換，以確認使用者的身分識別。只有 Internet Explorer 支援它 (Netscape Navigator 不支援)，因此僅適用於能控制用戶端軟體的內部網路案例。如果停用匿名存取或 Windows 檔案系統(tǒng)使用權限拒絕匿名存取，則這種驗證方法只能用於網頁伺服器。 ? 憑證驗證。「憑證」驗證使用用戶端憑證來識別使用者。用戶端憑證由使用者瀏覽器 (或用戶端應用程式) 傳遞到網頁伺服器。(若是 Web 服務，則 Web 服務的用戶端會利用 HttpWebRequest 物件的 ClientCertificates 屬性來傳遞憑證)。然後網頁伺服器再從憑證中取出使用者的身分識別。這種方法需要在使用者的電腦上安裝用戶端憑證，因此大多用於對使用者相當瞭解並能加以控制的內部網路或外部網路案例。收到用戶端憑證時，IIS 能將憑證對應到 Windows 帳戶。 ? 匿名驗證。如果您不必驗證用戶端 (或您實作自訂的驗證配置)，則可將 IIS 設定為「匿名」驗證。此時，網頁伺服器會建立 Windows 存取語彙基元，以同一匿名 (或來賓) 帳戶來代表所有的匿名使用者。預設的匿名帳戶是 IUSR_MACHINENAME，其中 MACHINENAME 是安裝時所指定的電腦 NetBIOS 名稱。
?	Passport 驗證。在這種驗證模式中的 ASP.NET 會使用 Microsoft Passport 的中央驗證服務。ASP.NET 提供了由 Microsoft Passport「軟體開發(fā)套件 (SDK)」帶來的方便包裝函式，它必須安裝在網頁伺服器上。
?	表單驗證。這種方法以用戶端重新導向的方式，將未經驗證的使用者轉移到指定的 HTML 表單，讓使用者輸入自己的憑證 (通常是使用者名稱和密碼)。這些憑證經過驗證後會產生驗證票證，再傳回用戶端。驗證票證包含使用者的身分識別，並選擇性地包含使用者在工作階段期間所扮演的各種角色的清單。 有時「表單」驗證只在網站個人化中使用。此時，您僅需撰寫一點點自訂程式碼，因為 ASP.NET 會用簡單設定自動處理大部份的處理序。個人化案例中的 Cookie 只需保留使用者名稱。 注意：「表單」驗證以純文字格式將使用者名稱和密碼傳送到網頁伺服器。因此在使用「表單」驗證時，應該搭配由 SSL 確保安全的通道。為了繼續(xù)保護後續(xù)要求所傳輸的驗證 Cookie，您應考慮在應用程式的所有網頁 (不僅是登入網頁) 上使用 SSL。
?	無。「無」表示不想驗證使用者或正在使用自訂的驗證通訊協定。

其他資訊

若需 ASP.NET 驗證的相關資訊，請參閱第 8 單元＜ASP.NET 安全性＞。

Enterprise Services 驗證

Enterprise Services 驗證是使用「遠端程序呼叫 (RPC)」傳輸基礎結構執(zhí)行的，然後 RPC 再使用作業(yè)系統(tǒng)的「安全性支援提供者介面 (SSPI)」。Enterprise Services 應用程式的用戶端可以用 Kerberos 或 NTLM 來驗證。

服務元件可以裝載於「程式庫」應用程式或「伺服器」應用程式中。「程式庫」應用程式裝載於用戶端處理序中，因此它會使用用戶端的身分識別。「伺服器」應用程式則是以自己的身分識別，在個別的伺服器處理序中執(zhí)行。若需身分識別的相關資訊，請參閱本單元稍後的＜身分識別和主體＞。

您可以在下列等級驗證對服務元件的傳入呼叫：

?	預設：使用安全性封裝的預設驗證等級。
?	無：不驗證。
?	連接：唯有連接時才驗證。
?	呼叫：每個遠端程序呼叫開始時驗證。
?	封包：驗證是否收到所有呼叫資料。
?	封包完整性：驗證傳輸時是否有資料被修改。
?	封包私密性：驗證和加密封包，其中包括資料和傳送者的身分識別與簽章。

其他資訊

若需 Enterprise Services 驗證的相關資訊，請參閱第 9 單元＜Enterprise Services 安全性＞。

SQL Server 驗證

SQL Server 能使用 Windows 驗證 (NTLM 或 Kerberos)，或使用內建的驗證配置 (稱為 SQL 驗證) 來驗證使用者。下列是可供使用的選項：

?	SQL Server 和 Windows。用戶端可以使用 SQL Server 驗證或 Windows 驗證，連接到 Microsoft SQL Server 的執(zhí)行個體。這有時稱作混合模式驗證。
?	僅 Windows。使用者必須使用 Windows 驗證，連接到 Microsoft SQL Server 的執(zhí)行個體。

其他資訊

第 12 章＜資料存取安全性＞會討論每種方法的相對優(yōu)點。

授權

Windows 2000 上的 .NET Framework 提供下列授權選項：

?	ASP.NET 授權選項
?	Enterprise Services 授權
?	SQL Server 授權

ASP.NET 授權選項

ASP.NET 授權選項可用於 ASP.NET Web 應用程式、Web 服務和遠端元件。ASP.NET 提供下列授權選項：

?	URL 授權。這是在電腦和應用程式設定檔中設定的授權機制。「URL 授權」讓您能限制存取應用程式 Uniform Resource Identifier (URI) 名稱空間中特定的檔案和資料夾。例如，您可以針對指定的使用者選擇拒絕或允許存取特定的檔案或資料夾 (使用 URL 指定)。您也可以根據使用者的角色成員和用來發(fā)出要求的 HTTP 動作類型 (GET 和 POST 等) 來限制存取。 「URL 授權」需要已驗證的身分識別。可以透過 Windows 或票證式驗證配置取得。
?	檔案授權。檔案授權只能在使用一種 IIS 提供的 Windows 驗證機制來驗證呼叫者，且 ASP.NET 設定為使用 Windows 驗證時套用。 您可以使用它限制存取網頁伺服器上的指定檔案。存取權限是由附加到檔案的 Windows ACL 決定的。
?	主體使用權限需求。主體使用權限需求可作為 (宣告式或程式設計式) 另一種精密的存取控制機制。這種授權方式讓您能根據個別使用者的身份識別和群組成員資格，來控制存取類別、方法或個別程式碼區(qū)塊。
?	.NET 角色。.NET 角色用來將應用程式中具有相同使用權限的使用者分到一組。其在概念上類似於先前的角色實作，例如 Windows 群組和 COM+ 角色。但 .NET 角色不需要已驗證的 Windows 身分識別，且可以與「表單」驗證等票證式驗證配置搭配使用，這點與前面的方法不同。 .NET 角色可用來控制存取資源和作業(yè)，且能進行宣告式或程式設計式設定。

其他資訊

若需 ASP.NET 授權的相關資訊，請參閱第 8 單元＜ASP.NET 安全性＞。

Enterprise Services 授權

存取保存在 Enterprise Services 應用程式服務元件中的功能是由 Enterprise Services 角色成員控制的。它不同於 .NET 角色，而且可包含 Windows 群組或使用者帳戶。角色成員在 COM+ 資料目錄中定義並使用「元件服務」工具進行管理。

其他資訊

若需 Enterprise Services 授權的相關資訊，請參閱第 9 單元＜Enterprise Services 安全性＞。

SQL Server 授權

SQL Server 允許使用能套用到個別資料庫物件的精密權限。使用權限可能基於角色成員 (SQL Server 提供固定資料庫角色、使用者定義的角色和應用程式角色)，也可以授與個別的 Windows 使用者或群組帳戶。

其他資訊

若需 SQL Server 授權的相關資訊，請參閱第 12 單元＜資料存取安全性＞。

Gatekeeper 和閘道

接下來，本手冊使用術語 Gatekeeper 來表示負責管制「閘道」的技術。閘道代表應用程式中的存取控制點 (用以保護資源)。例如，資源可能是一種作業(yè) (以作用在物件上的方法來表示)、資料庫或檔案系統(tǒng)資源。

前面列出的每種核心技術，都提供存取授權的 Gatekeeper。要求必須先通過一系列閘道，才能存取所要求的資源或作業(yè)。下面介紹要求必須通過的閘道：

?	IIS 會在您驗證使用者 (亦即停用「匿名」驗證) 時提供閘道。IIS Web 使用權限可作為一種存取控制機制，來限制 Web 使用者存取特定檔案和資料夾的能力。Web 使用權限可套用到所有 Web 使用者 (而非個別使用者或群組)，這點不同於 NTFS 檔案使用權限。NTFS 檔案使用權限還可進一步限制網頁和影像檔等 Web 資源。這些限制可以套用到個別使用者或群組。 IIS 會先檢查 Web 使用權限，再檢查 NTFS 檔案使用權限。使用者必須同時獲得這兩種機制的授權，才能存取檔案或資料夾。Web 使用權限檢查失敗會導致 IIS 傳回「HTTP 403 - 禁止存取」的回應；而 NTFS 使用權限檢查失敗則會導致 IIS 傳回「HTTP 401 - 拒絕存取」。
?	ASP.NET 提供各種可設定的程式設計閘道。其中包括「URL 授權」、「檔案授權」、「主體使用權限」需求和「.NET 角色」。
?	Enterprise Services Gatekeeper 使用 Enterprise Services 角色，來授權存取商業(yè)功能。
?	SQL Server 2000 包含一系列閘道，其中包括伺服器登入、資料庫登入和資料庫物件使用權限。
?	Windows 2000 提供的閘道使用附加到安全資源的 ACL。

底線是 Gatekeeper 根據呼叫閘道，並試圖存取特定資源的使用者或服務的身分識別來授權。多重閘道的價值在於用多條防護線來提供深層的安全。表 2.2 摘要出 Gatekeeper 集合，並指出每個 Gatekeeper 所負責的閘道。

表 2.2：Gatekeeper 的責任和其提供的閘道

Gatekeeper	閘道
Windows 作業(yè)系統(tǒng)	登入權限 (肯定和否定，例如「拒絕本機登入」) 其他權限 (例如「作為作業(yè)系統(tǒng)的一部份」) 針對確保安全之資源 (例如登錄及檔案系統(tǒng)) 的存取檢查。存取檢查使用附加到安全資源的 ACL，ACL 指定允許存取資源的人員，以及所允許的作業(yè)類型。 TCP/IP 篩選 IP 安全性
IIS	驗證 (匿名、基本、摘要、整合式及憑證) IP 位址和網域名稱限制 (這些可作為額外的保護線，但不應完全依賴它們，因為用 IP 位址詐騙相當容易)。 Web 使用權限 NTFS 使用權限
ASP.NET	URL 授權 檔案授權 主體使用權限需求 .NET 角色
Enterprise Services	Windows (NTLM / Kerberos) 驗證 Enterprise Services (COM+) 角色 模擬等級
Web 服務	使用 IIS 和 ASP.NET 提供的閘道
遠端處理	使用主機提供的閘道。如果在 ASP.NET 中裝載， 則它會使用 IIS 及 ASP.NET 提供的閘道。如果在 Windows 服務中裝載，則您必須開發(fā)自訂的方案。
ADO.NET	連接字串。憑證可能非常明確，或者您可使用 Windows 驗證 (例如，若您連接到 SQL Server)。
SQL Server	伺服器登入 資料庫登入 資料庫物件使用權限

藉由在應用程式的各層間使用各種閘道，您可以篩選出允許存取後端資源的使用者。當要求經由應用程式進行到後端資源時，一連串愈來愈細的閘道會縮小存取的範圍。

圖 2.4 顯示使用 IIS 的網際網路架構應用程式範例。

圖 2.4
使用 Gatekeeper 篩選使用者

圖 2.4 說明下列幾點：

?	您可以停用 IIS 中的「匿名」驗證。因此只能存取 IIS 能夠驗證的帳戶。這可能將潛在的使用者人數減少到 10,000。
?	接著，您可在 ASP.NET 中使用「URL 授權」，這可能將使用者人數減少到 1,000。
?	檔案授權可能進一步將存取人數減少到 100 個使用者。
?	最後，Web 應用程式碼可能會根據特定的角色成員，只允許 10 位使用者存取您設限的資源。

回到頁首

.NET Framework 安全性簡介

.NET Framework 安全性位於 Windows 安全性的頂層；它不會以任何方式被取代，但會提供其他安全性功能。您 .NET 應用程式執(zhí)行的所有資源存取是否成功，最終由作業(yè)系統(tǒng)安全性決定。

例如，如果 ASP.NET Web 應用程式嘗試開啟一個檔案，則存取嘗試取決於檔案相關的 Windows ACL。資源存取使用的身分識別是 ASP.NET 應用程式的處理序身分識別。如果應用程式目前正在模擬，則是模擬的身分識別。

程式碼存取安全性

.NET Framework 提供另一種稱為「程式碼存取安全性 (CAS)」的安全性機制。慣用安全性 (如 Windows 提供的) 是主體導向的，且授權決策取決於驗證主體的身分識別，例如，執(zhí)行程式碼的使用者，或登入 Web 應用程式的使用者。

CAS 藉依據程式碼的識別身分 (而不是執(zhí)行程式碼的使用者) 來支援授權決策的方式 ，擴展了安全性的能力。這對透過 Internet Explorer 從網際網路下載的控制項及應用程式等行動程式碼尤為重要。這是因為當您也會以系統(tǒng)管理員身分登入電腦，所以是否也希望這類程式碼同樣具有系統(tǒng)管理員權限？但一考慮到電腦的整合性及安全性，其答案很可能是否定的。

證據及安全性原則

程式碼的驗證及其身分識別都由稱為證據的程式碼屬性決定。證據可以包括組件的公開金鑰 (它是其強式名稱的一部份)、下載 URL、安裝的應用程式目錄等。一旦建立了程式碼身分識別，收集的證據就會透過安全性原則傳送，該原則最終管理程式碼的功能及其存取安全資源的權限。

預設原則確保本機電腦上安裝的所有程式碼都完全可以信任，並可讓其不受限制的存取安全資源。因此，一切資源存取都僅取決於作業(yè)系統(tǒng)的安全性。本機電腦上安裝的程式碼是完全受信任的，因為系統(tǒng)管理員需要明確的決策來首先安裝軟體。

CAS 及 ASP.NET Web 應用程式

ASP.NET Web 應用程式安裝在本機網頁伺服器上，因此預設原則在伺服器上完全信任 Web 應用程式。對於伺服器端 Web 應用程式開發(fā)人員來說，這意味著 CAS 的用途有限。實際上，在 .NET Framework 1 版上建置的 ASP.NET Web 應用程式必須作為完全受信任的應用程式執(zhí)行。

注意：.NET Framework 1.1 版新增了對部份信任之 Web 應用程式的支援，這有效地啟用了伺服器端 Web 應用程式的 CAS。它的主要優(yōu)點是：使應用程式彼此隔離，以及從重要系統(tǒng)資源分離應用程式變得更容易；著重於不同組織開發(fā)之多個 Web 應用程式的「網際網路服務提供者 (ISP)」及「應用程式服務提供者 (ASP)」。

主體及身分識別

CAS 是以程式碼為中心的，而 .NET Framework 安全性的其他部份是以主體為中心的。.NET Framework 安全性以主體為中心的部份是 ASP.NET 應用程式安全性的核心。

Windows 安全性以使用者為中心的概念，是基於登入工作階段所提供的安全性內容，而 .NET 安全性則是基於主體及身分識別物件。

在傳統(tǒng)的 Windows 程式設計時，如果您想知道目前執(zhí)行程式碼的安全性內容，要參考處理序擁有者或目前執(zhí)行緒的身分識別。在設計 .NET 程式時，如果您想查詢目前使用者的安全性內容，請擷取與目前執(zhí)行緒相關，且透過 Thread.CurrentPrincipal 存取的目前主體物件。

.NET Framework 使用主體物件，主體物件包含執(zhí)行 .NET 程式碼時用來代表使用者的身分識別物件，並共同提供 .NET 角色式授權的骨幹。若為 ASP.NET Web 應用程式，驗證的使用者由附加到目前執(zhí)行緒及 Web 要求的主體及身分識別物件代表。

IPrincipal 及 IIdentity 介面

身分識別和主體物件必須分別實作 IIdentity 和 IPrincipal 介面。這些介面是在 System.Security.Principal 名稱空間中定義的。一般介面允許 .NET Framework 以各式各樣的方式來處理身分識別和主體物件，而不論其基礎實作的詳細情況為何。

IPrincipal 介面允許您用 IsInRole 方法測試角色成員，並可存取相關的 IIdentity 物件。

public interface IPrincipal {bool IsInRole( string role );IIdentity Identity {get;} }

IIdentity 介面提供其他的驗證細節(jié)，例如名稱和驗證類型。

public interface IIdentity {string authenticationType {get;}bool IsAuthenticated {get;}string Name {get;} }

.NET Framework 提供了許多 IPrincipal 和 IIdentity 的具體實作，如圖 2.5 所示，並在下面幾節(jié)中說明。

圖 2.5
IPrincipal 和 IIdentity 實作類別

WindowsPrincipal 和 WindowsIdentity

.NET 版的 Windows 安全性內容可分成兩類：

?	WindowsPrincipal。這個類別儲存與目前 Windows 使用者相關的角色。WindowsPrincipal 實作將 Windows 群組視為角色。IPrncipal.IsInRole 方法根據使用者的 Windows 群組成員資格，傳回 True 或 False。
?	WindowsIdentity。這個類別保留目前使用者安全性內容的身分識別部份，並可使用靜態(tài) WindowsIdentity.GetCurrent() 方法取得。它會傳回 WindowsIdentity 物件，其中的 Token 屬性則會將代表 Windows 控制碼的 IntPtr 傳回與目前執(zhí)行緒有關聯的存取語彙基元。然後可以將這個語彙基元傳遞到 GetTokenInformation、SetTokenInformation、CheckTokenMembership 等原始 Win32? 應用程式發(fā)展介面 (API) 函式，以擷取語彙基元的安全性資訊。 注意：靜態(tài) WindowsIdentity.GetCurrent() 方法會傳回目前執(zhí)行緒的身分識別，可能模擬也可能不模擬。這點類似於 Win32 GetUserName API。

GenericPrincipal 和相關身分識別物件

這些實作十分簡單，可供不使用 Windows 驗證和不需複雜的主體表示法的應用程式使用。您很容易就能在程式碼中建立這些實作，因此應用程式處理 GenericPrincipal 時，必須有一定程度的信任。

如果您在 GenericPrincipal 上使用 IsInRole 方法決定授權，則必須信任負責傳送 GenericPrincipal 的應用程式。如果使用 WindowsPrincipal 物件，就必須信任作業(yè)系統(tǒng)能提供驗證身分識別的 WindowsPrincipal 物件和有效的群組/角色名稱。

下列身分識別物件類型可能與 GenericPrincipal 類別有關聯：

?	FormsIdentity。這個類別代表以「表單」驗證的身分識別。其中的 FormsAuthenticationTicket 包含使用者驗證工作階段的相關資訊。
?	PassportIdentity。這個類別代表以 Passport 驗證的身分識別，並包含 Passport 設定檔資訊。
?	GenericIdentity。這個類別代表未結合任何特殊作業(yè)系統(tǒng)技術，且通常搭配自訂驗證和授權機制使用的邏輯使用者。

ASP.NET 和 HttpContext.User

決定授權之前，通常會在 .NET 程式碼中檢查 Thread.CurrentPrincipal。但是 ASP.NET 使用 HttpContext.User 提供驗證使用者的安全性內容。

這個屬性接受並傳回 IPrincipal 介面。這個屬性包含目前要求的驗證使用者。ASP.NET 在決定授權時會擷取 HttpContext.User。

當您使用 Windows 驗證時，Windows 驗證模組會自動建構 WindowsPrincipal 物件，並將其儲存在 HttpContext.User 中。如果您使用「表單」或 Passport 等其他驗證機制，就必須建構 GenericPrincipal 物件，並將它儲存在 HttpContext.User 中。

ASP.NET 身分識別

執(zhí)行 ASP.NET Web 應用程式時，單一要求期間內可能會出現多重身分識別。這些識別包括：

?	HttpContext.User，傳回包含目前 Web 要求之安全性資訊的 IPrincipal 物件。這是已驗證的 Web 用戶端。
?	WindowsIdentity.GetCurrent()，傳回執(zhí)行中 Win32 執(zhí)行緒之安全性內容的身分識別。根據預設，這個身分識別是 ASPNET，即用來執(zhí)行 ASP.NET Web 應用程式的預設帳戶。但如果 Web 應用程式已經設定為使用模擬，則其身分識別代表驗證的使用者 (如果使用 IIS「匿名」驗證，則為 IUSR_MACHINE)。
?	Thread.CurrentPrincipal，傳回在 Win32 執(zhí)行緒頂端之執(zhí)行中 .NET 執(zhí)行緒的主體。

其他資訊

?	若需 Web 應用程式設定 (模擬和不模擬) 的 ASP.NET 身分識別的詳細分析，請參閱本手冊＜參考＞中的＜ASP.NET 身分識別矩陣＞。
?	若需建立自己的 IPrincipal 實作的相關資訊，請參閱第 8 單元＜ASP.NET 安全性＞和本手冊＜參考＞中的＜How To：實作 IPrincipal＞。

遠端處理和 Web 服務

現行版本的 .NET Framework、遠端處理和 Web 服務沒有自己的安全性模型。它們都繼承 IIS 和 ASP.NET 的安全性功能。

雖然遠端處理架構沒有內建的安全性，但是其在設計之初即已注意到安全性。再由開發(fā)人員和/或系統(tǒng)管理者在遠端處理應用程式中加入某些等級的安全性。是否會跨越遠端處理的界限傳遞主體物件，需視用戶端和遠端物件的位置而定，例如：

?	相同處理序中的遠端處理。相同或不同應用程式網域中的物件之間使用遠端處理時，遠端基礎結構會將與呼叫者內容有關聯的 IPrincipal 物件參考，複製到接收者內容。
?	處理序間的遠端處理。此時的處理序之間，不傳輸 IPrincipal 物件。用來建構原始 IPrincipal 的憑證，必須傳輸到可能在別臺電腦上的遠端處理序。這能讓遠端電腦根據提供的憑證，建構適當的 IPrincipal 物件。

回到頁首

摘要

本單元介紹了各種 .NET 相關技術所提供的所有驗證及授權選項。同時還介紹了 .NET Framework 安全性，以及作為 ASP.NET 授權核心的主體及身分識別物件。

藉由在 .NET Web 應用程式中使用多重 Gatekeeper，您可以實作深度防禦的安全性策略。總括來說：

?	ASP.NET 應用程式可以使用 Windows 和 IIS 提供的現有安全性功能。
?	SSL 和 IPSec 的結合可以提供 .NET Web 應用程式各層間 (例如，從瀏覽器到資料庫) 的安全通訊。
?	在使用「基本」驗證或「表單」驗證時，您可用 SSL 保護在網路上傳遞的純文字憑證。
?	.NET Framework 1 版建置的 ASP.NET Web 應用程式，必須作為完全信任的應用程式來執(zhí)行，這表示對於伺服器端 Web 應用程式開發(fā)人員來說，「程式碼存取安全性」用途有限。.NET Framework 1.1 版會啟用部份信任的 Web 應用程式，在此情況下，CAS 將變得更重要。
?	.NET 以 WindowsPrincipal 和 WindowsIdentity 類別，來代表經 Windows 驗證識別的使用者。
?	GenericPrincipal 和 GenericIdentity 或 FormsIdentity 類別可用來代表以「表單」驗證等非 Windows 驗證配置識別的使用者。
?	藉由建立實作 IPrincipal 和 IIdentity 的類別，您可以建立自己的主體和身分識別實作。
?	在 ASP.NET Web 應用程式中，代表驗證使用者的 IPrincipal 物件，用 HttpContext.User 屬性與目前的 HTTP Web 要求產生關聯。
?	閘道是應用程式中的存取控制點，可供授權的使用者存取資源或服務。Gatekeeper 負責控制存取閘道。
?	您可以使用多重 Gatekeeper，提供深度防禦策略。
?	Web 服務及 .NET 遠端處理依賴於 ASP.NET 及 IIS 提供的基礎安全性服務。

下一單元 - 第 3 單元＜驗證及授權＞提供的其他資訊，能協助您選擇最適合特殊應用程式案例的驗證及授權策略。

轉載于:https://www.cnblogs.com/coolcat/archive/2005/10/14/254750.html

總結

以上是生活随笔為你收集整理的ASP.NET 應用程式的安全性模型的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。