在本節中
一個功能強大的 ASP.NET 應用程序依賴于許多元素及技術的成功的相互作用。每一個解決方案的組成部分都會提供安全性功能,這些功能被設計用來滿足自身需要。然而,只是從單一的一個組成部分的角度來看待安全性是不夠的。為了為整體的解決方案提供安全性,必須也要考慮各個組成部分是如何相互作用的。
本節介紹了 .NET Web 應用程序體系結構和安全性,并且提供了一個可供參考的框架,而在此系列中其它的章節會向此框架中補充其它內容。本節綜述了存在于一個典型的 .NET Web 應用程序各個層面的安全性特征和服務。也介紹了 .NET Framework 安全性, 并且解釋了在此框架中的哪些元素對 ASP.NET Web應用程序開發人員最為重要。
目標
本章用來:
• |
深刻理解 .NET Web 應用程序體系結構和邏輯上以及物理上的應用程序層概念。 |
• |
了解每個實現技術提供的哪些安全性特征可以用來構建 .NET Web 應用程序,以及它們如何一起工作。 |
• |
理解 .NET Framework 安全性功能,并且理解哪些元素對 Web 應用程序安全性最為重要。 |
• |
比較和對照 Web 應用程序中可以使用的授權和驗證機制。 |
• |
了解如何在 .NET Web 應用程序中使用主體和標識對象。 |
• |
確定可在應用程序中用于實現信任邊界的網關守衛和關口。 |
適用于:
本章應用于下面的產品和技術:
• |
Microsoft_ Windows_ XP 或者 Windows 2000 Server 及其以后的的操作系統 |
• |
Internet Information Services (IIS) |
• |
.NET Framework 1.0 版本及其以后的版本 |
如何使用本節
為了從本章得到更多的收獲:
• |
您必須具有 ASP.NET Web 應用程序的開發經驗。這將有助于您理解在本單元中討論的各種安全性元素在何處與您的應用程序相結合。 |
• |
閱讀“構建安全的 ASP.NET 應用程序簡介”,此文強調了授權、驗證以及安全通信在創建安全的、分布式的Web應用程序中的重要性。同時指出了在開發安全的Web應用程序時采用的主要原則和實踐。 |
本頁內容
![]() |
.NET Web 應用程序 |
![]() |
實現技術 |
![]() |
安全體系結構 |
![]() |
介紹 .NET Framework 安全性 |
![]() |
小結 |
.NET Web 應用程序
這一部分對 .NET Web 應用程序進行了簡要的介紹,并且分別從邏輯上和物理上說明其特征。還介紹了用于構建 .NET Web 應用程序的各種實現技術。
邏輯層
邏輯應用程序體系結構將任何系統都視為一組相互協作的服務,這些服務分為以下幾層:
• |
用戶服務 |
• |
業務服務 |
• |
數據服務 |
此邏輯體系結構視圖的意義的價值在于將普遍存在于任何系統中的各種服務區分開來、確保了適當的分離以及促成各層之間的接口定義。這種分離可以使您在實現每個邏輯層時更為謹慎地進行體系結構和設計選擇,從而構建出更易于維護的應用程序。
現將各邏輯輯層描述如下:
• |
用戶服務負責客戶端與系統之間的交互,并且提供一個與核心業務邏輯相連的公共網橋,這些業務邏輯由業務服務層內的組件封裝。一般說來,用戶服務與交互式用戶關聯的情況最多。不過,它們也對其他系統發出的編程請求進行初始處理,這種情況下不涉及任何可見的用戶界面。身份驗證和授權的確切性質因客戶端類型而異,它們通常在用戶服務層內執行。 |
• |
業務層提供系統的核心功能并封裝業務邏輯。它們獨立于傳輸信道和后端系統或數據源。這就為提升系統以支持新的、不同的信道及后端系統提供了必要的穩定性和靈活性。通常,為特定業務請求提供服務涉及到業務服務層內的許多協作組件。 |
• |
數據服務通過一般接口提供對數據(系統邊界內承載的)及其他(后端)系統的訪問;通過業務服務層內的組件可以方便地使用這些接口。數據服務對多種后端系統和數據源進行了抽象,并且封裝了特定的訪問規則和數據格式。 |
系統內各服務類型的邏輯分類既與實現這些服務的組件的可能的物理分布相關,又相對獨立于它們的物理分布。
可以在任何聚合級別上標識邏輯層,具體來說,可以對整個系統(在系統環境上下文和外部交互中)標識邏輯層,也可以對系統中所含的任何子系統標識邏輯層。記住這一點也很重要。例如,承載 Web 服務的每個遠程節點由用戶服務(處理傳入的請求和消息)、業務服務和數據服務組成。
物理部署模型
前面所述的三個邏輯服務層并不意味著存在特定數量的物理層。所有這三種邏輯服務在物理上可能位于同一臺計算機上,也可能分布于多臺計算機上。
Web 服務器用作應用程序服務器
.NET Web應用程序的常用部署模式是將業務和數據訪問組件放在 Web 服務器上。這樣就最大限度地減少了網絡躍點,有助于提高性能。圖 1 中顯示了這種模型。.

圖 1. Web 服務器用作應用程序服務器
遠程應用程序層
遠程應用程序層是常用的部署模式,尤其是以下 Internet 方案中的常用部署模式:Web 層在周邊網絡(也就是大家所知道的DMZ 和屏蔽的子網)中是獨立的部分,它依靠數據包篩選防火墻與最終用戶和遠程應用程序層分隔開圖 2 中顯示了遠程應用程序層。

圖 2. 遠程應用程序層簡介
實現技術
.NET Web 應用程序通常使用以下技術來實現一個或多個邏輯服務:
• |
ASP.NET ASP.NET 通常用于實現用戶服務。ASP.NET 提供一種可插接式體系結構,這種體系結構可用于構建 Web 頁。有關 ASP.NET 安全性,的詳細信息,請參閱:“ASP.NET 安全性”。 |
• |
企業服務 Enterprise Services 為應用程序提供基礎結構級別的服務。這包括分布式事務和資源管理服務,如 .NET 組件的對象池。有關Enterprise Services 的詳細信息,請參閱“企業服務安全性”。 |
• |
Web 服務 Web 服務使用基于 SOAP 的消息交換來防火墻移動數據和在異構系統之間移動數據,以此來實現數據交換和應用程序邏輯的遠程調用。有關 Web 服務的詳細信息,請參閱“Web 服務安全性”。 |
• |
.NET Remoting .NET Remoting 提供了一種用于跨越進程和計算機邊界訪問分布式對象的框架。有關.NET Remoting的詳細信息,請參閱“NET Remoting 安全性”。 |
• |
ADO.NET 和 Microsoft_ SQL Server™ 2000 ADO.NET 提供數據訪問服務。 ADO.NET從一開始就是專門為分布式 Web 應用程序設計的,很適合用于與 Web 應用程序有著內在聯系的分離方案。SQL Server 提供使用操作系統身份驗證機制(Kerberos 或 NTLM)的集成式安全性。授權由可應用于單個數據庫對象的登錄和細化權限提供。有關數據訪問安全性的詳細討論,請參閱“數據訪問安全性”。 |
• |
Internet 協議安全性 (IPSec) IPSec提供點對點的傳輸級別加密和身份驗證服務。有關 IPSec 的詳細信息,請參閱“安全通信”。 |
• |
安全套接字層 (SSL) SSL提供點對點的安全通信信道。通過該信道傳輸的數據都是加密的。有關 SSL 的詳細信息,請參閱“安全通信”。 |
安全體系結構
圖 3顯示了遠程應用程序層模型和前面介紹的各種技術提供的那些安全服務。身份驗證和授權在分布于各層中許多點分別進行。這些服務主要由 Internet 信息服務 (IIS)、ASP.NET、Enterprise Services 和 SQL Server 提供。同時,安全通信信道在各層上應用,并從客戶端瀏覽器或設備一直延伸到數據庫。信道的安全性由安全套接字層 (SSL) 或 IPSec 聯合提供保障。

圖 3. 安全體系結構
各層之間的安全性
表 1摘要說明前面討論的技術所提供的身份驗證、授權和安全通信功能。
表 1:安全功能 | |||
技術 | 身份驗證 | 授權 | 安全通信 |
IIS |
匿名 基本 摘要式 Windows 集成 (Kerberos/NTLM) 證書 |
IP/DNS 地址限制 Web 權限 NTFS 權限;所請求文件的 Windows 訪問控制列表 (ACL) |
SSL |
ASP.NET |
無(自定義) Windows 窗體 Passport |
文件授權 URL 授權 主體權限 .NET角色 |
- |
Web Services |
Windows 無(自定義) 消息級別身份驗證 |
文件授權 URL 授權 主體權限 .NET角色 |
SSL 和消息級別加密 |
Remoting |
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 ACLs |
IPSec |
身份驗證
Windows 2000上的.NET Framework提供下面的身份驗證選項:
• |
ASP.NET身份驗證模式 |
• |
Enterprise Services身份驗證 |
• |
SQL Server 身份驗證 |
ASP.NET 身份驗證模式
ASP.NET身份驗證模式包括 Windows、窗體、Passport和無身份驗證。
• |
Windows 身份驗證。在這種身份驗證模式下,ASP.NET 依靠 IIS 對用戶進行身份驗證并創建 Windows 訪問令牌來表示經過身份驗證的標識。IIIS 提供下列身份驗證機制:
| ||||||||||
• |
Passport 身份驗證。在這種身份驗證模式下,ASP.NET使用 Microsoft Passport 的集中式身份驗證服務。ASP.NET提供方便的包裝對 Microsoft Passport 軟件開發工具包 (SDK) 提供的功能進行包裝,該 SDK 必須安裝在 Web 服務器上。 | ||||||||||
• |
窗體身份驗證。此方法使用客戶端重定向將沒有經過身份驗證的用戶轉發到指定的 HTML 窗體,用戶可以在該窗體中輸入證書(通常是用戶名和密碼)。然后,系統對這些證書進行驗證,生成身份驗證票并將其返回客戶端。身份驗證票上有用戶標識,您還可以選擇在身份驗證票上列出用戶在會話期間所屬的角色。 有時,窗體身份驗證僅用于 Web 站點的個性化處理。在這種情況下,您幾乎不用編寫任何自定義代碼,因為 ASP.NET用簡單的配置自動處理這一過程的大部分工作。在個性化處理方案中,cookie 只需要保留用戶名。 注:窗體身份驗證以明文形式向 Web 服務器發送用戶名和密碼。因此,應該將窗體身份驗證與 SSL 保護的信道結合使用。為了對后續請求中傳輸的身份驗證 cookie 不間斷地提供保護,您應該考慮在應用程序內的所有頁上使用 SSL,而不僅僅是在登錄頁上使用 SSL。 | ||||||||||
• |
無“無”表示不希望對用戶進行身份驗證,或者使用的是自定義的身份驗證協議。 |
更多信息
有關ASP.NET身份驗證的更多詳細信息,請參閱“ASP.NET 安全性”。
企業服務身份驗證
企業服務身份驗證的通過基礎的“遠程過程調用”(RPC) 傳輸基礎結構來執行的,該基礎結構使用操作系統的“安全服務提供程序接口”(SSPI)?梢允褂 Kerberos 或 NTLM 身份驗證對企業服務應用程序客戶端進行身份驗證。
可以在庫應用程序或服務器應用程序中承載服務組件。庫應用程序是在客戶端進程內承載的,因此,它們采用客戶端的標識。服務器應用程序在單獨的服務器進程內運行,它們有自己的標識。有關標識的詳細信息,請參閱本章內下文中的“標識和主體”一節。
傳入的對服務組件的調用可以在以下級別進行身份驗證:
• |
默認:使用安全包的默認身份驗證級別。 |
• |
無:不執行身份驗證。 |
• |
連接:僅在連接時進行身份驗證。 |
• |
調用:每次開始遠程過程調用時進行身份驗證。 |
• |
數據包:鑒定并驗證是否已收到所有調用數據。 |
• |
數據包完整性:驗證數據在傳輸過程中是否被修改過。 |
• |
數據包保密性:驗證并加密數據包,包括數據和發送者的標識及簽名。 |
更多信息
有關 Enterprise Services 身份驗證的詳細信息,請參閱“企業服務安全性”。
SQL Server 身份驗證
SQL Server 既可以使用 Windows 身份驗證(NTLM 或 Kerberos)對用戶進行身份驗證,也可以使用其內置的身份驗證方案(稱為 SQL 身份驗證)對用戶進行身份驗證。共有以下兩個可用選項:
• |
SQL Server 和 Windows.客戶端可以使用 SQL Server 身份驗證或 Windows 身份驗證連接到 Microsoft SQL Server 的實例。有時,這也稱為混合模式的身份驗證。 |
• |
僅使用 Windows。用戶必須使用 Windows 身份驗證連接到 Microsoft SQL Server 的實例。 |
更多信息
關于每種方法的優點,請參閱“數據訪問安全性”。
授權
Windows 2000上 的 .NET Framework 提供了下列授權選項:
• |
ASP.NET 授權選項 |
• |
Enterprise Services 授權 |
• |
SQL Server 授權 |
ASP.NET 授權選項
ASP.NET授權選項可供 ASP.NET Web 應用程序、Web服務和遠程組件使用。 ASP.NET 提供下面的授權選項:
• |
URL 授權.這是通過計算機配置文件和應用程序配置文件中的設置來配置的授權機制。 URL 授權使您可以限制對應用程序的“統一資源標識符”(URI) 名稱空間中的特定文件和文件夾的訪問。例如,您可以選擇拒絕或允許指定的用戶對特定文件或文件夾(通過 URL 尋址)的訪問。您還可以根據用戶的角色成員身份和用于發出請求(GET、POST 等等)的 HTTP 謂詞類型來限制訪問。 URL 授權需要經過身份驗證的標識。它可以通過 Windows 或基于身份驗證票的身份驗證方案來獲得。 |
• |
文件授權.只有在使用 IIS 提供的一種 Windows 身份驗證機制對調用方進行身份驗證并且ASP.NET已配置為使用 Windows 身份驗證時,文件授權才適用。 您可以使用它限制對 Web 服務器上的指定文件的訪問。訪問權限由與文件相關的 Windows ACL 確定。 |
• |
主體權限需求.主體權限需求可以作為一種(以聲明方式或編程方式)更加細化的訪問控制機制來使用。這種權限需求使您可以根據單個用戶的標識和組成員身份控制對類、方法或單個代碼塊的訪問。 |
• |
.NET 角色..NET角色用于將應用程序內具有相同權限的用戶集合在一起。它們在概念上與以前基于角色的實現手段(例如,Windows 組和 COM+ 角色)類似。不過,與這些方法不同,.NET 角色不需要經過身份驗證的 Windows 標識,可在基于身份驗證票的身份驗證方案(如窗體身份驗證)中使用。 .NET 角色可用于控制對資源和操作的訪問,并且,這類角色既可以用聲明方式配置,也可以用編程方式配置。 |
更多信息
有關ASP.NET授權的詳細信息,請參閱“ASP.NET 安全性”。
Enterprise Services 授權
對企業服務應用程序內服務組件中所含功能的訪問受企業服務角色成員身份制約。與.NET角色不同,它們可以包含 Windows 組或用戶帳戶。角色成員身份在 COM+ 目錄內定義并通過使用“組件服務”工具管理。
更多信息
有關 Enterprise Services 授權的詳細信息,請參閱“企業服務安全性”。
SQL Server 授權
SQL Server 允許設置細化的權限,這些權限可應用于單個數據庫對象?梢宰寵嘞藁诮巧蓡T身份(SQL Server 提供固定的數據庫角色、用戶定義的角色和應用程序角色),也可以將權限授予單個的 Windows 用戶或組帳戶。
更多信息
有關 SQL Server 授權的詳細信息,請參閱“數據訪問安全性”。
網關守衛和關口
在本文檔的其余部分,術語網關守衛 用來指負責關口 的技術。關口表示應用程序內的訪問控制點(保護資源)。例如,資源可以是某個操作(由對象的方法表示)或數據庫或文件系統資源。
前面所列的每種核心技術都為訪問授權提供了網關守衛。請求必須先通過一系列的關口,然后才被允許訪問所請求的資源或操作。下面說明請求必須通過的各個關口:
• |
IIS 在您對用戶進行身份驗證(即您禁用匿名身份驗證)時提供關口。 IIS Web 權限可用作訪問控制機制,該機制限制 Web 用戶對特定文件和文件夾的訪問能力。與 NTFS 文件權限不同,Web 權限應用于所有 Web 用戶,而不是單個的用戶或組。 NTFS 文件權限對 Web 資源(如 Web 頁、圖像文件,等等)提供進一步的限制。這些限制適用于單個的用戶或組。 IIS 檢查 Web 權限,接著檢查 NTFS 文件權限。用戶必須獲得兩種機制的授權后才能訪問文件或文件夾。如果 Web 權限檢查失敗,IIS 將返回HTTP 403 — 訪問拒絕響應,如果 NTFS 權限檢查失敗,IIS 將返回HTTP 401 — 拒絕訪問。 |
• |
ASP.NET 提供了各種可配置的編程關口。其中包括 URL 授權、文件授權、主體權限需求和 .NET 角色。 |
• |
Enterprise Services 網關守衛使用 Enterprise Services 角色來授予對業務功能的訪問權限。 |
• |
SQL Server 2000 包括一系列關口,包括服務器登錄、數據庫登錄和數據庫對象權限。 |
• |
Windows 2000 使用與安全資源相關的 ACL 提供關口。 |
底線是:網關守衛根據調用到關口并嘗試訪問特定資源的用戶或服務的標識來授權。多個關口的好處是通過多條防御線提供縱深防御安全機制。表 2.2 摘要說明各種網關守衛及其負責的關口。
表 2. 網關守衛的責任及其提供的關口 | |
網關守衛 | 關口 |
Windows 操作系統 |
登錄權限(肯定和否定,例如“拒絕本地登錄”) 其他權限(例如“充當操作系統的一部分”) 對保護的資源(如注冊表和文件系統)進行訪問檢查。訪問檢查使用與安全資源相關的ACL,這些ACL指定允許誰訪問資源和不允許誰訪問資源,并指定允許執行的操作類型。 TCP/IP 篩選 IP安全性 |
IIS |
身份驗證(匿名、基本、摘要式、集成、證書) IP 地址和域名限制(它們可用來加強安全防御,但不應依靠它們,因為使用欺騙性的 IP 地址是比較容易的事情)。 Web 權限 NTFS 權限 |
ASP.NET |
URL授權 文件授權 主體權限需求 .NET角色 |
企業服務 |
Windows (NTLM / Kerberos) 身份驗證 Enterprise Services (COM+)角色 模擬級別 |
Web 服務 |
使用 IIS 和ASP.NET提供的關口 |
遠程處理 |
使用主機提供的關口。如果是在 ASP.NET中承載的,它使用 IIS 和 ASP.NET 提供的關口。如果是在 Windows 服務中承載的,則必須開發自定義的解決方案 。 |
ADO.NET |
連接字符串可以使用顯式證書,也可以使用 Windows 身份驗證(例如,連接到 SQL Server 時) |
SQL Server |
服務器登錄 數據庫登錄 數據庫對象權限 |
通過在應用程序各層上使用各種關口,您可以篩選出應允許哪些用戶訪問您的后端資源。請求在通過應用程序到達后端資源的過程中,一系列相連的關口的控制越來越細化,使得訪問范圍逐步縮小。
請考慮使用 IIS 的基于 Internet 的應用程序示例,如圖 4 所示。

圖 4 用網關守衛篩選用戶
圖 4 說明以下幾點:
• |
您可以在 IIS 中禁用匿名身份驗證。這樣,將只允許經過 IIS 身份驗證的帳戶進行訪問。這可將潛在用戶數減到 10,000。 |
• |
接著,您可以在 ASP.NET中使用 URL 授權,這可將用戶數減到 1,000。 |
• |
文件授權可能會將訪問范圍進一步縮小,將用戶數減少到 100。 |
• |
最后,根據特定的角色成員身份,Web 應用程序代碼可能只允許 10 個用戶訪問受限制的資源。 |
介紹 .NET Framework 安全性
.NET Framework 安全性在 Windows 安全性之上;它沒有取代Windows安全性,而是提供附加的安全特性。.NET 應用程序對所有資源訪問的成功或者失敗最終由操作系統的安全性決定。
例如,如果一個 ASP.NET Web 應用程序要打開一個文件,能否打開文件取決于和此文件相關的Windows ACL。用于資源訪問的標識要么是 ASP.NET 應用程序進程標識,要么是使用個性化處理的應用程序的個性化標識。
代碼訪問安全性
.NET Framework提供一個被稱為代碼訪問安全性 (CAS) 的附加的安全性機制。傳統的安全性(例如 Windows 提供的安全性)是以主體為中心的,并且授權基于一個驗證的主體,例如用戶運行代碼,或者用戶登錄一個 Web 應用程序。
CAS 通過支持基于代碼標識(而不是運行代碼的用戶)的授權為安全性添加了一項內容。這對于使用 Internet Explorer 從 Internet 上下載的移動代碼(例如控件和應用程序)尤為重要。這是因為您可能以管理員的身份登錄您的計算機,但是您真的想讓這種代碼具有管理員權限嗎?如果您考慮到計算機的安全性,您可能不會允許的。
證據和安全策略
代碼被驗證并且其標識使用代碼的屬性來決定,這種代碼被稱作為證據。證據可以包含一個匯編的公共鑰匙(是其強名稱的一部分)、下載 URL、安裝應用程序目錄和其它內容。一旦建立了代碼標志,收集的證據通過安全性策略傳遞,安全性策略最終管理代碼的功能以及給予何種許可訪問安全資源。
缺省策略確保安裝到本地機器上的所有代碼都是完全可信的,并且可以不受限制地訪問安全資源。因此所有資源訪問只受操作系統安全性管理。由于在安裝軟件時首先要求管理員作出謹慎的決定,所以安裝到本地機器上的代碼是完全可信的。
CAS 和 ASP.NET Web 應用程序
ASP.NET應用程序安裝到本地 Web 服務器上,因此在服務器上缺省策略給予 Web 應用程序完全的信任。這意味著 CAS 對服務器端 Web 應用程序開發人員來說使用范圍有限。實際上,建立于 .NET Framework 版本 1之上的 ASP.NET Web 應用程序必須作為完全信任的應用程序運行。
注.NET Framework 的 1.1 版本添加了對部分信任 Web 應用程序的支持,這樣就可以使 CAS 有效的使用于服務器端 Web 應用程序。引入 CAS 主要的好處是易于將應用程序之間分離開,以及將應用程序和關鍵的系統資源分離開;這對于由不同公司開發的可以承載多個 Web 應用程序的 Internet Service Providers (ISPs) 和 Application Service Provides (ASPs) 是一個重要的考慮因素。
主體和標識
盡管 CAS 以代碼為中心,但是 .NET Framework 安全性的其它方面以主體為中心。 .NET Framework 安全性以主體為中心對 ASP.NET 應用程序安全性起著支配作用。
Windows 安全性的用戶中心概念基于登錄會話提供的安全上下文,而 .NET 安全性基于 IPrincipal 和 IIdentity 對象。
在 Windows 編程中,如果要了解運行的代碼所依賴的安全上下文,應查詢進程所有者的標識或當前所執行線程的標識。在 .NET 編程中,如果要查詢當前用戶的安全上下文,應從 Thread.CurrentPrincipal 檢索當前的 IPrincipal 對象。
運行 .NET 代碼時。NET Framework 使用標識對象和主體對象來表示用戶,這兩個對象共同構成基于 .NET 角色的授權的主干部分。對 ASP.NET Web 應用程序來講,通過附加到當前線程和 Web 請求的主體和標志對象來表征驗證的用戶。
IPrincipal 和 IIdentity 接口
標識和主體對象必須分別實現IIdentity 和 IPrincipal 接口。這些接口在 System.Security.Principal 名稱空間內定義。公共接口使 .NET Framework 能以多態方式處理標識和主體對象,而不管基礎實現的詳細情況如何。
IPrincipal 接口使您可以通過 IsInRole 方法測試角色的成員身份,同時也提供了對關聯的 IIdentity 對象的訪問。
public interface IPrincipal { bool IsInRole( string role ); IIdentity Identity {get;} }
IIdentity 接口提供有關身份驗證的更多詳細信息,如名稱和驗證類型。
public interface IIdentity { string authenticationType {get;} bool IsAuthenticated {get;} string Name {get;} }
.NET Framework 提供了 IPrincipal 和IIdentity 的多個具體實現,如圖 5 所示,后面幾節對這些實現分別進行詳細說明。

圖 5. IPrincipal 和 IIdentity 實現類
WindowsPrincipal 和 WindowsIdentity
Windows 安全上下文的 .NET 版本分為兩個類:
• |
WindowsPrincipal.該類存儲與當前的 Windows 用戶相關的角色。WindowsPrincipal實現將 Windows 組視為角色。IPrncipal.IsInRole方法根據用戶的 Windows 組成員身份返回 true 或 false。 |
• |
WindowsIdentity該類存儲當前用戶安全上下文的標識部分,它可以從靜態的 WindowsIdentity.GetCurrent() 方法獲得。它返回具有 Token 屬性的 WindowsIdentity 對象,該屬性將一個表示 Windows 句柄的 IntPtr 返回給與當前執行線程關聯的訪問令牌。該令牌接著可被傳遞到本機 Win32® 應用程序編程接口 (API) 函數,如 GetTokenInformation、SetTokenInformation 和 CheckTokenMembership 等等,用于檢索與令牌有關的安全信息。 注:靜態 WindowsIdentity.GetCurrent() 方法返回當前所執行線程的標識,它可能是(也可能不是)模擬的。這與 Win32 GetUserName API類似。 |
GenericPrincipal 和 Associated Identity 對象
這些實現非常簡單,供不使用 Windows 身份驗證的應用程序在應用程序不需要主體的復雜表示時使用。您可以在代碼中非常容易地創建這些實現,因此,在應用程序處理 GenericPrincipal 時,必須存在某種程度的信任。
如果依靠GenericPrincipal 上的 IsInRole 方法作出授權決定,必須信任向您發送GenericPrincipal的應用程序。這與使用 WindowsPrincipal 對象形成對比:使用 WindowsPrincipal 對象時,必須委托操作系統提供有效的 WindowsPrincipal 對象,和一個授權表示符以及有效的組/角色名。
以下類型的標識對象可以與 GenericPrincipal 類相關聯:
• |
FormsIdentity該類表示已經過窗體身份驗證的標識。它包含的 FormsAuthenticationTicket 中存儲了與用戶的身份驗證會話有關的信息。 |
• |
PassportIdentity該類表示已經過 Passport 身份驗證的標識,它包含 Passport 配置文件信息。 |
• |
GenericIdentity該類表示一個不與任何特定操作系統技術相關的邏輯用戶,通常用在自定義的身份驗證和授權機制中。 |
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 標識
在 ASP.NET 應用程序執行過程中的任何給定時間內,單個請求中可能存在多個標識。它們包括:
• |
HttpContext.User返回IPrincipal對象,該對象包含當前 Web 請求的安全信息。這是經過身份驗證的 Web 客戶端。 |
• |
WindowsIdentity.GetCurrent()返回當前所執行的 Win32 線程的安全上下文標識。默認情況下,該標識為 ASPNET;這是用于運行 ASP.NET Web 應用程序的默認帳戶。.但是,如果已配置 Web 應用程序進行模擬,該標識則表示經過身份驗證的用戶(如果 IIS 匿名身份驗證有效,該標識為 IUSR_MACHINE)。 |
• |
Thread.CurrentPrincipal返回當前所執行的 .NET 線程(它位于 Win32 線程之上)的主體。 |
更多信息
• |
有關 Web 應用程序配置組合(包括使用模擬和不使用模擬)的ASP.NET標識的詳細分析,請參閱“ASP.NET Identity Matrix”。 |
• |
有關創建您自己的IPrincipal實現的詳細信息,請參閱“ASP.NET 安全性”和“How to implement IPrincipal”。 |
Remoting 與 Web 服務
在.NET Framework, 的最新版本中,Remoting 與 Web 服務沒有自己的安全模型。它們都繼承 IIS 和 ASP.NET 的安全功能。
雖然遠程處理體系結構中沒有內置的安全功能,但在設計時考慮到了安全性。開發人員和/或管理員可以自行決定在遠程處理應用程序中集成一定程度的安全性。是否在遠程處理邊界之間傳遞主體對象取決于客戶端和遠程對象的位置,例如:
• |
同一進程內的遠程處理。在同一應用程序域或不同的應用程序域內的對象之間使用遠程處理時,遠程處理基礎結構將與調用方上下文相關的 IPrincipal 對象的引用復制到接收方的上下文中。 |
• |
進程之間的遠程處理。在這種情況下,不在進程之間傳送 IPrincipal 對象。用于構造原始 IPrincipal 的證書必須傳送到遠程進程,該進程可能位于另一臺計算機上。這就使得遠程計算機能夠根據提供的證書來構造相應的 IPrincipal 對象。 |
文章來源于領測軟件測試網 http://www.kjueaiud.com/