摘要
本指南介紹為基于 Microsoft® .NET 的單層或多層應用程序設計和編寫由應用程序管理的授權的指導原則，主要討論常見的授權任務和方案，并提供相應的信息幫助您選擇最佳方法和技術。本指南適用于體系結構設計人員和開發人員。
本指南假定讀者已經了解 Windows 身份驗證和授權、XML Web Service 以及 .NET Remoting 等主題的基本知識。有關設計分布式 .NET 應用程序的詳細信息，請參閱 MSDN® Library 中的“Designing Applications and Services”。有關分布式應用程序安全設計的詳細信息，請參閱 MSDN Library 中的 Building Secure ASP.NET Applications（英文）。有關其他的常規設計準則，請參閱 Microsoft TechNet 中的 .NET Architecture Center（英文）。
下載
單擊此處下載本指南（PDF 格式）。
目錄
本指南包括以下各節：
簡介
本指南介紹如何在基于 .NET 的應用程序中實現授權，解釋術語“授權”并討論幾種執行授權的機制。本指南還包括以下內容：
- 標識和主體等重要概念。
- 如何使用基于角色的安全設置來授權具有相同安全特權的一類用戶。
- 基于角色的 .NET 和 COM+ 安全設置之間的主要區別。
采用何種授權機制通常取決于驗證用戶身份（標識）的方法。本指南將探討以下內容：
- Windows 身份驗證和非 Windows 身份驗證之間的區別。
- 這些身份驗證機制如何影響授權。
- 如何向遠程應用程序層傳遞用于授權的標識信息。
在典型的企業應用程序中，需要在應用程序的不同層次執行不同類型的授權。為了幫助您識別各層的授權需要以及在不同的方案中選擇合適的授權策略，本指南介紹在用戶界面層、業務層和數據層中通常使用的典型授權任務。圖 1 顯示了企業應用程序的各個層上出現的一些重要授權問題。
圖 1：在企業應用程序的各層中執行授權
.NET Framework 類庫提供了多種接口和類，幫助您使用基于角色的 .NET 安全設置來執行授權。本指南介紹：
- 幾種檢查用戶是否屬于某個特定角色的技術。
- 如何處理授權錯誤。
- 在多線程的 .NET 應用程序中出現的特殊授權問題。
定義授權框架時所做的大部分工作，都可以在多個應用程序中重復使用。本指南將對以下內容進行總結：
- 如何定義可重復使用的授權框架。
- 使框架的安全性和性能達到最佳的原則。
注意：本指南適用于使用 .NET Framework 功能進行由應用程序管理的授權。Microsoft Windows® Server 2003 系列操作系統中的授權管理器 API 和 Microsoft Management Console (MMC) 管理單元，為應用程序提供了具有完整的基于角色的訪問控制框架。授權管理器 API 也稱為 AzMan，它提供了一種簡化的開發模型，用于管理靈活的分組和業務規則，并可用于存儲授權策略。有關詳細信息，請參閱 MSDN Library 中的 Authorization Interfaces（英文）和 Authorization Objects（英文）。
了解授權
“授權”是對通過驗證的主體（用戶、計算機、網絡設備或程序集）是否具有執行某項操作的權限的確認。授權提供的保護只允許指定用戶執行特定操作，并防止惡意行為。
本節的內容如下：
- 授權提供的保護。
- 基本授權。
- .NET Framework 的授權功能。
降低安全威脅
僅有授權還不足以保證應用程序的安全，因此，本指南將簡要介紹應用程序面臨的幾種威脅。以下是一些常見的安全威脅，這些威脅通�？s寫為“STRIDE”，包括：
- 標識欺騙 - 未授權的用戶冒充應用程序的合法用戶
- 篡改數據 - 攻擊者非法更改或毀壞數據
- 可否認性 - 用戶否認執行了操作的能力
- 信息泄露 - 敏感數據被泄露給本應無權訪問的人或位置
- 拒絕服務 - 導致用戶無法使用應用程序的破壞行為
- 特權升級 - 用戶非法獲得過高的應用程序訪問特權
您可以使用以下技術來解決 STRIDE 威脅：
- 身份驗證 - 嚴格的身份驗證有助于減少標識欺騙。當用戶登錄到 Windows 或啟動應用程序時，他（她）會輸入“憑據”信息，如用戶名和密碼。Windows 使用 NTLM 或 Kerberos 等協議驗證用戶的憑據，并讓用戶登錄到系統。應用程序則通常使用系統登錄產品，或者以實現自定義身份驗證作為授權的基礎。有關身份驗證的詳細信息，請參閱 MSDN Library 中的 Building Secure ASP.NET Applications（英文）。
- 授權 - 使用本指南介紹的授權技術來應對數據篡改和信息泄露的威脅。
- 標識流 - 跨多臺計算機部署的應用程序，有時需要在系統中的計算機之間傳遞代表通過驗證的用戶標識的信息。如果在第一臺計算機中進行身份驗證，而其他應用程序邏輯駐留在單獨的計算機上，通常會用到標識流。有關標識流的詳細信息，請參閱本指南后面的設計用于授權的標識流。
- 審核 - 記錄已授權的和未授權的操作，減少可否認性帶來的威脅。本指南不對審核進行詳細介紹。有關審核的詳細信息，請參閱 MSDN Library 中的 Building Secure ASP.NET Applications（英文）。
有關 STRIDE 的詳細信息，請參閱 MSDN Library 中的 Designing for Securability（英文）。
圖 2 顯示的模型說明了如何降低多層應用程序中的 STRIDE 安全威脅。
圖 2：多層應用程序的安全模型
圖 2 描述的是一種具有多個物理層的部署，但是，許多較小的應用程序是在一個物理層上完成的，這就簡化了身份驗證、授權和標識流。圖 2 包含了以下降低安全威脅的措施：
- 通過帶寬限制來降低拒絕服務 (DoS) 的攻擊。這可以防止惡意的應用程序和用戶對應用程序連續進行不受歡迎的干擾，從而避免應用程序出現問題。
- 使用加密來保證通信安全。
- 身份驗證可以防止標識欺騙。
- 身份驗證根據數據存儲庫來驗證憑證。
- 應用程序層之間使用標識流（可選）。
- 通過審核來保證可否認性。
- 通過授權來應對篡改和泄露數據的威脅。
選擇授權機制
您可以使用多種授權機制來控制應用程序的功能，使其按預期方式運行，不被意外或蓄意誤用。這些授權機制包括以下幾種：
- 系統授權 - Windows 使用訪問控制列表 (ACL) 保護資源，如文件和存儲過程。ACL 指定哪些用戶可以訪問安全資源。
- .NET 代碼訪問安全性授權 - 代碼訪問安全性根據代碼的來源授權代碼以執行操作。例如，代碼訪問安全性根據證據標準，確定 .NET 應用程序中可以訪問其他程序集的程序集。
- 應用程序授權 - 應用程序代碼自身授權用戶操作。
可以綜合使用這些方法創建安全的應用程序，如圖 3 所示。
圖 3：選擇授權機制
系統授權
“系統授權”是為操作系統控制的對象（例如打印機、文件）設置資源權限或 ACL 的過程。系統管理員負責維護這些設置。系統授權是一種非“是”即“否”的決策模式：用戶要么被授權訪問資源，要么不被授權訪問資源。
系統授權的示例包括：
- 基于 Microsoft ASP.NET 的應用程序授權設置，用于限制對 Web.config 文件中指定的 URL 文件或路徑的訪問。
- Active Directory® 目錄服務中的權限設置。
- NTFS 文件系統訪問控制項。
- 消息排隊權限。
- 服務器產品（如 Microsoft SQL Server™）中授予的權限。這種權限可能涉及各種對象，如表或視圖。
有關系統級安全和授權的詳細信息，請參閱 MSDN Library 中的 Building Secure ASP.NET Applications（英文）。
系統授權可以對各種對象施加約束，而限制代碼則需要采用 .NET 代碼訪問安全性授權。
.NET 代碼訪問安全性授權
.NET 公共語言運庫使用代碼訪問安全性來限制可執行的代碼。代碼訪問安全性根據證據向應用程序代碼授予權限（稱為“權限設置”）。這些證據可以包括代碼的來源、發布者或其他證據，如程序集的嚴格名稱。
權限設置使您能夠控制應用程序可以執行的操作，如刪除文件或訪問 Internet。例如，您可以限制應用程序只使用隔離的存儲單元或控制打印訪問。
不管用戶的身份如何，代碼訪問安全性只考慮證據，即使具有管理特權的用戶使用應用程序，代碼訪問安全性權限仍舊保持不變。例如，如果代碼來自 Internet，不管用戶是誰，對其應用的限制（如刪除文件的能力）保持不變。
代碼訪問安全性的應用示例包括：
- 限制下載組件的操作權利并將其放置到隔離環境中，防止下載組件執行危險操作。隔離有助于防止欺詐代碼損壞系統。
- 為在 Web 服務器或應用程序服務器上運行的宿主代碼創建隔離環境。
- 限制組件的操作權利，防止被惡意代碼誤用。
注意：請使用 Caspol.exe 或 Microsoft .NET Framework 配置管理控制臺配置代碼訪問安全性。
有關代碼訪問安全性的詳細信息，請參閱 MSDN Library 中《.NET Framework Developer's Guide》中的 Code Access Security（英文）一文。
代碼訪問安全性通過檢查代碼權限來保證系統的安全性，但可能還需要使用應用程序授權來檢查用戶的權限，這取決于應用程序。
應用程序授權
大多數應用程序會根據用戶與系統的交互活動實現不同的功能或安全權限。設計“應用程序授權”指根據程序中的用戶角色，實施業務規則或限制用戶對應用程序資源的訪問。
應用程序授權的主要目的是保護功能和其他無形內容，如業務邏輯。因此，很難使用當前的系統級技術實現應用程序授權，因為這些技術需要使用有關物理資源的設置，如 ACL。例如，您想確保對員工費用申請的批準操作的安全，卻沒有要保護的物理資源，因此，當您設計應用程序授權時，應該著眼于高級別的操作，而不是各種資源。
當系統授權機制分類過細或不考慮應用程序的數據與狀態時，應用程序授權提供了另一種系統授權方法。例如，如果 XML Web Service 的系統級安全標準仍處于開發階段，還在不斷地發展豐富，那么您可以不必等到標準形成之后再向 XML Web Service 添加安全設置或創建安全的 XML Web Service。對于目前已創建的 XML Web Service，您可以實現應用程序授權，使用安全套接字層 (SSL) 或其他組合來保護對服務的調用。
應用程序授權的示例包括：
- 檢查用戶是否具有執行應用程序中特定操作（如批準費用申請）的權限。
- 檢查用戶是否具有訪問應用程序資源（如從數據庫中檢索敏感數據列）的權限。
在本指南的后面部分中，您將學習如何設計這些應用程序授權以及如何編寫相關代碼。
入口檢查
為了防止操作被連續不斷地錯誤執行而導致最終失敗，您應該始終做到盡快地對用戶的每個請求進行授權。每個授權點稱為“看門人”。這種看門機制的示例包括 ASP.NET 入口中的文件和 URL 授權。在標識流向各個層次傳遞的過程中，可能會有若干個“看門人”。在門口進行檢查可以減少在系統深層（通過入口點或門以后）必需的授權檢查次數。
在系統深層執行授權檢查的對象需要較少的授權失敗補償邏輯。單個組件不負責處理授權失敗，不會拋出異常來通知失敗的調用者。
使用角色執行授權
.NET Framework 提供了基于角色的應用程序授權能力�！敖巧敝腹蚕硗话踩貦嗟囊活惢蛞唤M用戶。
使用角色代替特定的用戶標識具有以下優勢：
- 發生變化（如添加用戶、提升用戶或用戶調離工作）時，不需要改變應用程序。
- 維護角色的權限比維護各個用戶的權限容易。例如，處理 10 個角色比處理 120 個用戶容易，而且還節省時間。
- 一個用戶可以具備多個角色，這增強了分配和測試權限的靈活性。
根據業務組織定義角色
角色可以代表用戶在組織中的地位，例如：
- Manager
- Employee
- ClaimApprovalDepartment
使用這種方法的一個好處是信息通�？梢詮拇鎯欤ɡ� Active Directory）中檢索出來。通常情況下，這些角色在對實際業務需求進行建模時十分有用。
與組織的變化無關
您還可以使用角色來指出用戶執行的工作屬于哪種操作類型。這樣的角色可以將應用程序的功能鏈接到各個用戶，例如：
- CanApproveClaim
- CanAccessLab
- CanViewBenefits
第二種方法更靈活一些，因為您可以圍繞應用程序的功能來設計角色，而不用過多考慮組織的結構，但維護起來可能比較困難，因為缺乏保存角色的結構。大多數情況下，需要在應用程序中綜合使用這些方法。
不使用角色執行授權
有時您必須以用戶是誰作為授權的基礎，而不會過分關注用戶在應用程序中扮演的角色。例如，您可能要實現只允許部門經理批準員工的費用申請，而要達到這種授權級別，可以將當前用戶與提出申請的員工的經理進行比較。
在基于 .NET 的應用程序中使用基于角色的安全設置
.NET Framework 在 System.Security.Principal 命名空間中提供了基于角色的安全設置實現，您可以用此實現來授權應用程序。要在 .NET Framework 中使用應用程序授權，請創建 IIdentity 和 IPrincipal 對象來表示用戶。IIdentity 封裝的是一個通過驗證的用戶，IPrincipal 則是用戶標識和用戶角色的組合。
圖 4 顯示了 IIdentity 和 IPrincipal 對象之間的關系。
圖 4：IIdentity 和 IPrincipal 對象之間的關系
請注意圖 4 中的以下幾點：
- IIdentity 對象是實現 IIdentity 類的實例。IIdentity 對象表示特定的用戶。
- IIdentity 接口具有 Name、IsAuthenticated 和 AuthenticationType 屬性。實現 IIdentity 的類通常還包含有特定用途的其他私有成員，例如，WindowsIdentity 類封裝了正運行代碼的用戶的帳戶令牌。
- IPrincipal 對象是實現 IPrincipal 的類的實例。IPrincipal 對象是代表用戶的 IIdentity 及其具有的角色的組合。這樣就可以實現單獨的身份驗證和授權。
- IPrincipal 對象使用 IsInRole 方法執行授權，并通過 Identity屬性提供對 IIdentity 對象的訪問。
使用標識
.NET Framework 提供了四種實現 IIdentity 接口的類：
- WindowsIdentity
- GenericIdentity
- PassportIdentity
- FormsIdentity
每種類都允許您使用不同種類的用戶標識。要訪問使用 Windows 身份驗證的應用程序的當前 WindowsIdentity 對象，可以使用 WindowsIdentity 類的靜態 GetCurrent 方法，如以下代碼所示：
您還可以通過在自己定義的類中實現 IIdentity 接口來創建自定義標識類。有關創建自定義標識的詳細信息，請參閱本指南后面的擴展默認實現。有關如何使用默認 IIdentity 實現的詳細信息，請參閱本指南后面的設計用于授權的身份驗證。
使用主體
.NET Framework 提供了鏈接用戶角色和標識的 IPrincipal 接口。所有執行應用程序授權的托管代碼都應該使用實現 IPrincipal 的類的對象。例如，WindowsPrincipal 和 GenericPrincipal 類提供了內置的 IPrincipal 實現。另外，您也可以根據 IPrincipal 創建自己的自定義主體類。
為了提高編碼效率，您可以使用本指南的設計用于授權的身份驗證一節中介紹的技術，通過使用 Thread 對象的靜態 CurrentPrincipal 屬性可以將 IPrincipal 對象鏈接到線程，這樣當前線程就可以輕松地訪問 IPrincipal 對象了，如以下代碼所示：
然后，您可以測試用戶是否屬于某一特定的角色，從而執行授權檢查。為此，可以使用 IPrincipal 接口的 IsInRole 方法，如以下代碼所示：
ASP.NET 應用程序處理 IPrincipal 對象的方法與其他基于 .NET 的應用程序的處理方法有所不同。ASP.NET 通過無狀態的 HTTP 協議創建會話外觀。作為會話的一部分，執行用戶請求的所有代碼可以通過 HttpContext 對象的 User 屬性，使用代表用戶的 IPrincipal 對象。Global.asax 文件發生 OnAuthenticate 事件之后，公共語言運庫使用 HttpContext.User 值自動更新 Thread.CurrentPrincipal。
ASP.NET 應用程序通常使用 User 屬性執行授權檢查，如以下代碼所示：
注意：手動更改 HttpContext.User 將自動更新在同一 HTTP 上下文環境中執行的所有線程的 Thread.CurrentPrincipal。但是，改變 Thread.CurrentPrincipal 不會影響 HttpContext.User 屬性，它只影響為請求中其余內容選擇的線程。
有關創建自己的 IPrincipal 類型的詳細信息，請參閱本指南后面的擴展默認實現。有關如何使用默認 IPrincipal 實現的詳細信息，請參閱本指南后面的設計用于授權的身份驗證。
授予使用 IIdentity 和 IPrincipal 對象的權限
使用 IIdentity 對象是一種敏感操作，因為在該操作中可以使用與用戶相關的信息。允許應用程序更改當前的 IPrincipal 對象也應該受到保護，因為應用程序授權能力是以當前的主體為基礎的�？蚣芤筮@些操作具有代碼訪問安全性權限，從而提供了保護。使用 Caspol.exe 或 .NET Framework 配置工具為需要管理這些對象的應用程序授予 SecurityPermissionAttribute.ControlPrincipal 權限。
默認情況下，所有本地安裝的應用程序均具有該權限，因為它們是在“完全信任”的權限設置下運行的。
執行以下方法需要 ControlPrincipal 權限：
- AppDomain.SetThreadPrincipalPolicy()
- WindowsIdentity.GetCurrent()
- WindowsIdentity.Impersonate()
- Thread.CurrentPrincipal()
有關使用 CASPOL 設置安全權限的詳細信息，請參閱 MSDN Library 中的 Configuring Security Policy Using the Code Access Security Policy Tool (Caspol.exe)（英文）。
Windows 和公共語言運庫之間管理授權的區別
公共語言運庫在 Windows 安全結構之上有一個單獨的安全結構。Windows 線程具有 Windows 授權用戶的令牌，而運行時線程具有代表該用戶的 IPrincipal 對象。
因此，在開發代碼時，必須至少考慮兩種代表用戶的安全上下文。例如，設想一個使用窗體身份驗證的 ASP.NET 應用程序：默認情況下，ASP.NET 進程在名為“ASPNET”的 Windows 服務帳戶（專為應用程序創建的用戶帳號）下運行。假設有一位名為 Bill 的用戶登錄到 Web 站點。Thread.CurrentPrincipal 屬性代表窗體身份驗證的用戶 Bill。公共語言運庫看到以 Bill 運行的線程，于是所有托管代碼都將 Bill 看作主體。如果托管代碼要求訪問系統資源（如文件），則不管 Thread.CurrentPrincipal 的值如何，非托管代碼都可以看到 ASPNET Windows 服務帳戶。圖 5 說明了公共語言運庫和操作系統線程之間的授權關系。
圖 5：公共語言運庫和操作系統線程之間的授權關系
模擬允許您改變操作系統線程在與 Windows 的交互過程中執行的用戶帳戶�？梢酝ㄟ^調用 WindowsIdentity.Impersonate 方法模擬 Windows 標識。這種模擬形式允許您作為特定用戶訪問本地資源。當調用 Impersonate 方法時，您就以 WindowsIdentity 所代表的用戶登錄。您必須有權訪問服務器中的用戶憑據且有權調用 LogonUser API。但是，手動創建 WindowsIdentity 的過程比較復雜，因此，如果不是十分必要，最好不要執行模擬。
當應用程序代碼模擬其他用戶之后，WindowsImpersonatationContext.Undo 方法將用戶標識還原到原始標識。這些函數一般必須成對調用，如以下代碼所示：
有關模擬 Windows 帳戶的詳細信息，請參閱 MSDN Library 中的 Impersonating and Reverting（英文）。
注意：在 Windows 2000 中，調用 LogonUser API 的進程必須具備 SE_TCB_NAME 特權。有關驗證用戶憑據的詳細信息，請參閱文章 Q180548 HOWTO: Validate User Credentials on Microsoft Operating Systems（英文），位于 Microsoft Knowledge Base（英文）中。
設計用于授權的身份驗證
授權取決于身份驗證，也就是說，必須對用戶或過程進行身份驗證，然后才能對其授權，以便查看或使用受保護的資源。本節將分析兩種身份驗證機制并闡述這兩種機制對授權的影響：
- 根據 Windows 身份驗證執行授權
- 根據非 Windows 身份驗證執行授權
選擇哪種身份驗證機制通常受與授權無關的因素的影響，例如 Windows 用戶帳戶的可用性以及一些常見的環境問題，包括客戶端的瀏覽器類型。但是，您選擇的身份驗證機制確實會影響您執行授權的方式。
根據 Windows 身份驗證執行授權
所有應用程序在稱為“Windows 標識”的 Windows 用戶帳戶下執行。在 Windows 身份驗證過程中，您將使用這種 Windows 用戶帳戶或 Windows 用戶所屬的角色執行您的授權檢查。Windows 根據由以下技術提供的憑據來選擇用戶帳戶：
- 使用用戶登錄到計算機時提供的信息
- 使用通過配置工具（如組件服務管理實用程序）專為應用程序創建的服務帳戶
使用 Windows 身份驗證進行授權的整個過程是這樣的：
- Windows 使用 NTLM 或 Kerberos 驗證用戶的憑據。有關使用 Kerberos 委托的詳細信息，請參閱 Building Secure ASP.NET Applications（英文）中的“How To: Implement Kerberos Delegation for Windows 2000”。
- 如果登錄成功，將生成一個 Windows 訪問令牌，對 .NET 應用程序來說，該令牌封裝在 WindowsIdentity 中。
- 運行時通常會自動為包含 Windows 角色概念的 WindowsPrincipal 對象設置 Thread.CurrentPrincipal 屬性，但有些情況下，您必須親自按本節后面介紹的方法進行設置。
- 現在可以使用 Thread.CurrentPrincipal 進行授權。
- 當您遠程調用應用程序邏輯時，有時需要手動向被調用者提供標識信息。本指南后面的實現手動標識流將詳細討論該問題。
注意：先將 IPrincipal 對象鏈接到線程，然后再從 Thread.CurrentPrincipal 屬性檢索主體或標識信息。這樣就可以在內存中維護一個角色集，從而降低查找這類信息的頻率。
使用 Windows 角色執行授權
您可以使用 WindowsPrincipal 對象查看用戶是否屬于特定的 Windows 用戶組（例如 “<domain>\Users”）。WindowsPrincipal 對象具有 Identity 屬性，該屬性返回一個 WindowsIdentity 對象，描述當前用戶的標識。
您可以配置存儲在 ASP.NET 中的 .NET 應用程序，使其通過啟用 Web.config 中的 Windows 身份驗證，從 Thread.CurrentPrincipal 屬性自動訪問 WindowsPrincipal。您可以在 ASP.NET Web 應用程序、XML Web Service 以及存儲在 ASP.NET 中的 .NET Remoting 對象中使用該技術。
其他 .NET 應用程序，如 Windows 服務、控制臺和基于 Windows 窗體的應用程序，需要您使用以下方法之一建立 Thread.CurrentPrincipal：
- 調用 SetPrincipalPolicy
- 設置 CurrentPrincipal
注意：使用 IIdentity 和 IPrincipal 對象的代碼必須具備 ControlPrincipal 權限，請使用代碼訪問安全性為應用程序授予該權限。有關詳細信息，請參閱本指南前面的在基于 .NET 的應用程序中使用基于角色的安全設置。
調用 SetPrincipalPolicy
AppDomain 對象的 SetPrincipalPolicy 方法可以將特定類型的 IPrincipal 對象鏈接到應用程序域。請使用 PrincipalPolicy 枚舉類型的 WindowsPrincipal 值，將當前的 WindowsPrincipal 對象鏈接到應用程序線程，如以下代碼所示：
然后就可以授權檢查主體了。在開始執行應用程序時，調用 SetPrincipalPolicy 以確保在執行任何授權檢查之前 IPrincipal 對象已鏈接到線程。
請勿在 ASP.NET 應用程序中使用 SetPrincipalPolicy，因為在 Global.asax 中定義的 Application_AuthenticateRequest 事件處理程序過程中，ASP.NET 身份驗證將為您管理此值。
注意：只有在應用程序域中不存在默認的主體時，SetPrincipalPolicy 才有效。
設置 CurrentPrincipal
要設置 CurrentPrincipal 屬性，首先必須創建一個新的 WindowsPrincipal 對象，方法是將 WindowsIdentity 對象傳遞給 WindowsPrincipal 構造函數。然后將新的 WindowsPrincipal 對象鏈接到 Thread.CurrentPrincipal 屬性，如以下代碼所示：
然后就可以授權檢查 IPrincipal 對象了。
有關如何使用 WindowsPrincipal 執行授權檢查的詳細信息，請參閱本指南后面的執行授權檢查。
使用應用程序定義的角色執行授權
要根據應用程序定義的角色（如 CanApproveClaims）創建授權檢查，必須手動創建通用的或自定義的 IPrincipal 對象。您無需調用 SetPrincipalPolicy 方法，因為它的默認設置是 NoPrincipal，正是指定您自己的主體的正確設置。
大多數情況下，根據已通過身份驗證的用戶名來創建 GenericIdentity 對象。（通過使用 IIdentity 接口的 Name 屬性，可以得到該用戶名。）這樣，在向其他組件提供 IIdentity 對象時，就可以避免所有涉及用戶登錄令牌（可以使用 WindowsIdentity 對象訪問）的安全問題。然后，可以創建 GenericPrincipal，將 IIdentity 對象鏈接到自己的應用程序定義的角色列表中。
以下代碼顯示了使用 Windows 身份驗證時，如何創建 GenericIdentity 和 GenericPrincipal 對象：
大多數情況下，應該從數據存儲庫中檢索應用程序定義的角色，而不是為角色編寫代碼，從而在指定角色成員時獲得更大的靈活性。有關使用該方法的示例，請參閱附錄中的sqlserver" target=_self>如何使用 SQL Server 構建 GenericPrincipal。
有關如何使用 GenericPrincipal 執行授權檢查的詳細信息，請參閱本指南后面的執行授權檢查。
根據非 Windows 身份驗證執行授權
您可能不想或不能使用 Windows 身份驗證執行應用程序授權。出現這種情況的原因可能是用戶沒有 Windows 用戶帳戶，或者是因為技術限制而無法使用 Windows 身份驗證來驗證用戶的憑據。
非 Windows 身份驗證是使用非 Windows 技術驗證用戶憑據的過程。這種身份驗證包括 .NET Framework 為您提供的驗證（如 ASP.NET 窗體身份驗證）和您自己創建的驗證方法。
使用非 Windows 身份驗證進行授權的整個過程如下：
- 應用程序收集用戶憑據。
- 應用程序驗證憑據，通常是以自定義的數據存儲庫（如 SQL Server 數據庫）為參照。
- 開始是將 Thread.CurrentPrincipal 屬性設置為不包含任何角色的 GenericPrincipal 對象。然后用新的 GenericPrincipal 對象，或者用實現 IPrincipal 的自定義類對象取代 Thread.CurrentPrincipal，以提供應用程序定義的角色。
- 現在可以使用 Thread.CurrentPrincipal 進行授權。
- 當遠程調用應用程序邏輯時，需要向被調用者手動提供標識信息。
常見的非 Windows 身份驗證類型有：
- ASP.NET 窗體身份驗證 - ASP.NET 窗體身份驗證自動創建 FormsIdentity 對象，代表已驗證的標識。這種驗證包含一個 FormsAuthenticationTicket，提供用戶身份驗證會話的信息。
窗體身份驗證提供程序根據 FormsIdentity 對象創建 GenericPrincipal，但是沒有角色成員關系。
有關如何使用 ASP.NET 窗體身份驗證的詳細信息，請參閱文章 Q301240 HOW TO: Implement Forms-Based Authentication in Your ASP.NET Application by Using C# .NET（英文)，位于 Microsoft Knowledge Base（英文）中。
窗體身份驗證幾乎總是使用應用程序特定的憑據。有關如何使用窗體身份驗證方式來驗證獲得的 Windows 憑據的示例，請參閱文章 Q316748 HOW TO: Authenticate Against the Active Directory by Using Forms Authentication and Visual C# .NET（英文），位于 Microsoft Knowledge Base（英文）中。
- Passport 身份驗證 - ASP.NET 應用程序可以使用 .NET Passport 執行身份驗證。Passport 身份驗證生成一個表示用戶標識的 PassportIdentity 對象。PassportIdentity 對象擴展了基本的 IIdentity 接口，以便包括 Passport 配置文件信息。
Passport 身份驗證提供程序根據 PassportIdentity 對象創建一個 GenericPrincipal，但是沒有角色成員關系。
有關 Passport 身份驗證的詳細信息，請參閱 MSDN Library 中的 The Passport Authentication Provider（英文）。
- ISAPI 身份驗證解決方案 - 是一種備用方法，它使用 HTTP 標頭來實現手動或自定義的身份驗證機制，例如 Microsoft Commerce Server 中的身份驗證機制。有關 Microsoft Commerce Server 中安全設置的詳細信息，請參閱 MSDN Library 中的 Commerce Server Security（英文）。
HTTP 傳輸提供用于構建通用或自定義的 IIdentity 對象和 IPrincipal 對象的信息（如 cookie）。
有關 ASP.NET 的身份驗證技術的詳細信息，請參閱 MSDN Library 中的 Authentication in ASP.NET: .NET Security Guidance（英文）。
以上列舉的所有非 Windows 身份驗證類型均涉及到 GenericPrincipal 對象或自定義 IPrincipal 對象。關于如何將 GenericPrincipal 鏈接到應用程序定義的角色的示例，請參閱附錄中的sqlserver" target=_self>如何使用 SQL Server 構建 GenericPrincipal。
設計用于授權的標識流
身份驗證創建用于授權的 IIdentity 和 IPrincipal 對象，并確定如何通過編程方式將標識信息傳遞給其他計算機上遠程部署的應用程序邏輯。已通過驗證的標識的傳遞過程稱為“標識流”。實現標識流的方法有兩種：
- 自動標識流
- 手動標識流
使用自動標識流
如果所有需要標識信息的代碼是在同一上下文中執行的，公共語言運庫將自動提供標識流。調用者和被調用者共享相同的應用程序域時，它們處于同一上下文。如果客戶端代碼（稱為“調用者”）和被調用的組件（稱為“被調用者”）在同一上下文中運行，.NET 將對兩者自動使用同一個 Thread.CurrentPrincipal 對象。有關被調用者和調用者處在不同線程的情況，請參閱本章后面的使用多線程執行授權。
在一個應用程序域中執行的代碼示例包括：
- 在進程內組件中包含所有必需的代碼且未遠程部署邏輯的 ASP.NET Web 站點。
- 未遠程部署邏輯、基于 Windows 窗體的單機應用程序。
實現手動標識流
由于技術限制，需要在不能執行身份驗證的遠程層進行授權檢查時，可以實現手動標識流。例如，通過 TCP 通道使用 .NET Remoting 調用遠程組件。有關在 .NET Remoting 應用程序中使用通道的詳細信息，請參閱 MSDN Library 中的 Microsoft .NET Remoting: A Technical Overview（英文）。
如果您正在實現自己的標識流，請使用與調用代碼不同的方式傳遞數據（稱為“分離”）。如果您的組件接口涉及調用功能，并且使用參數傳遞數據，請使用其他方式發送標識信息。
例如，如果您正在使用 SOAP 調用 XML Web Service，則請勿將標識信息作為消息正文的一部分發送，而應將其放入自定義的 SOAP 標頭中。這時對安全性的要求不象處理代碼設計問題時那樣嚴格。這種分隔方式可以增加代碼接口的擴展性、可復用性和聚合性。這樣做還使您可以隨著技術標準的發展更改發送標識信息的方法，而無需改變接口約定。Web Services Security (WS-Security)（英文）規范說明了這一點。
請注意，標識流不同于傳遞憑據，后者是在服務器上進行的高效重驗證過程。另外，您還可以在消息本身中傳遞已加密的憑據，但是，加密需要使用共享密鑰或公鑰系統，所以用這種方式傳遞憑證沒有什么優勢。
以下是一些實現標識流的最佳方案：
- 使用功能要求和技術限制允許的最有力的身份驗證。
- 有些標識流技術會涉及存儲和/或傳遞機密信息，這些信息對于標識流機制的安全性至關重要。對機密信息進行加密或者使用安全的通道來保證信息的安全。System.Security.Cryptography 命名空間中的類或許能對您有所幫助。另外，Building Secure ASP.NET Applications（英文）中的“How To: Create a DPAPI Library”的示例也可以供您借鑒。
- 使用諸如數據保護 API (DPAPI) 之類的技術保存機密信息。有關 DPAPI 的信息，請參閱 MSDN Library 中的 Windows Data Protection（英文）。
- 確保您的實現允許您的審核達到所需的深度。有關審核的詳細信息，請參閱 Microsoft TechNet 中的 Monitoring and Auditing for End Systems（英文）。
在信任環境中傳遞標識信息
在信任環境中，被調用者將身份驗證的責任交給了調用者。這時認為我們從調用者傳遞到被調用者的所有信息都是安全可靠的，例如 Web 層是調用者，內部應用程序中的組件是被調用者。
注意：如果非法用戶可以調用其他（和潛在虛假）標識傳遞的代碼，這種解決方案將是不安全的。為了防止這類欺詐攻擊，請使用系統層提供的技術來保護安全套接字層 (SSL) 或 IP 安全性 (IPSec) 通信通道，并使用代碼訪問安全性來確保只有相應的代碼才能調用您的函數。
在信任環境中，主要采用兩種方法在應用程序層之間傳遞標識信息：
- 只傳遞用戶名 - 調用者只向被調用者傳遞用戶名。然后，如本指南前面提到的那樣，被調用者查詢授權存儲庫，創建通用的或自定義的 IPrincipal 對象，并將對象連接到線程中。
當您向數據庫傳遞標識信息進行審核時，也可以使用這種方法。有關詳細信息，請參閱本指南后面的在數據層執行授權。
該方法較為靈活，因為不需要強制調用者傳遞特定類型的對象或額外信息，例如應用程序角色。
- 傳遞角色（使用 IPrincipal 對象）- 驗證用戶標識之后，調用者通過序列化通用或自定義 IPrincipal 對象向被調用者傳遞角色。然后，如前面提到的那樣，被調用者反序列化對象，并將對象連接到線程中。這與在單個應用程序的域中自動發生的過程的效果相同。。
通過傳遞自定義的 IPrincipal 對象，您可以傳遞角色、自定義的 IPrincipal 對象包含的任意附加信息（如用戶配置文件）以及標識。
但是，不能傳遞封裝了某種信息的 IPrincipal 對象。例如，不能傳遞 WindowsPrincipal 或其他所有以 WindowsIdentity 對象為基礎的主體，因為這些標識信息中包含的令牌在其原始環境之外是沒有意義的。
有關序列化 IPrincipal 對象的詳細信息，請參閱附錄中的如何在 .NET Remoting 組件中啟用授權。
注意：只有在使用安全通信通道的信任環境中（如使用防火墻保護的某個公司 LAN），才可以傳遞標識信息，以免網絡數據在網絡上被截獲或修改而遭到欺詐。
在非信任環境中傳遞標識信息
非信任環境是指調用者不信任被調用者的情形。在非信任環境中，被調用者必須驗證調用者，然后才執行授權，例如 Web 應用程序驗證瀏覽器的所有請求。
在非信任環境中的應用程序層之間傳遞標識信息有兩種常見的方法：
- 傳遞簽名數據 - 使用公鑰結構傳遞加密的簽名數據，是傳遞標識流的一種有效方法。由于不存在身份驗證會話，這種方法通常是和異步通信一起使用的。
傳遞簽名數據包括對消息進行數字簽名。數字簽名是根據發件人的私鑰和消息內容計算出的。為了實現驗證，被調用者通過密鑰管理系統獲得發件人的公鑰，并使用該密鑰確定發件人在簽署消息時是否使用了相應的私鑰。
.NET Framework 提供的 SignedXml 類可以作為 XMLDSIG 標準的實現。該標準不涉及密鑰管理或密鑰信任等問題。收件人不必假設對該過程所使用的密鑰的信任程度，這部分由應用程序代碼負責。有關 XMLDSIG 標準的詳細信息，請參閱 W3C 網站上的 XML-Signature Syntax and Processing（英文）。
有關如何使用 SignedXml 類的代碼示例，請參閱 CAPICOM SDK。CAPICOM 是一種 Microsoft ActiveX® 控件，提供到 Microsoft CryptoAPI 的 COM 接口。該代碼示例說明了使用證書授權、簽名和驗證 XMLDSIG 簽名的全過程。您可以從 samples\c_sharp\xmldsig 目錄中的 Platform SDK Redistributable: CAPICOM 2.0 找到該代碼示例。有關 CAPICOM 的詳細信息，請參閱 MSDN Library 中的 CAPICOM Reference（英文）。
- 傳遞令牌 - 傳遞令牌會傳遞一些信息，被調用者要驗證這些信息以確定用戶標識。
傳遞令牌要求使用共享的身份驗證機制或確定令牌有效性的方法。傳遞令牌可能包括在組件之間傳遞 Kerberos 票據。另一個例子是電子商務網站中 Internet Information 服務 (IIS) 應用程序根據身份驗證創建的會話 cookie。每次瀏覽器發出調用命令時，cookie 都會傳遞回 Web 服務器，這是典型的 ISAPI 解決方案。
上面您已經了解了如何使用各種身份驗證機制實現授權，以及如何在各層之間傳遞授權數據，下面將為您介紹如何在企業應用程序的各層進行授權。
在企業應用程序中執行授權
目前大多數的應用程序都得益于多層設計，因為多個層次可以提供伸縮性、靈活性并且可以改善性能。盡管應用程序各層的授權目的相同（控制用戶訪問系統功能和數據），但是各層授權的設計方法和實現方法并不相同。企業應用程序中的三層是：
- 用戶界面層
- 業務層
- 數據層
在用戶界面層執行授權
本節介紹在用戶界面層執行授權的方法。本指南的后面將介紹以下主題：在業務層執行授權和在數據層執行授權。
在用戶界面層執行應用程序授權，有助于確保只有得到授權的用戶才可以查看和修改數據，或者執行與特定崗位相關的業務功能（例如與工資有關的操作）。對于還需要在系統的其他層進行授權的過程來說，在用戶界面層授權用戶，是限制對這些過程的訪問的第一道關卡。
要實現以下目的時，請在用戶界面層創建訪問檢查：
- 根據用戶的角色成員關系，啟用或禁用以及顯示或隱藏控件。有關詳細信息，請參閱本節后面的改變窗體中的控件。
- 根據用戶的角色成員關系，將流從一個窗體（或頁面）更改到下一個窗體（或頁面）。有關詳細信息，請參閱本節后面的改變頁面流。
在用戶界面層創建授權代碼時，請使用以下最佳方案：
- 只要可能，就配置系統授權，以控制用戶界面的輸入。例如，配置 ASP.NET 應用程序中的 Web.config 文件，只允許得到授權的用戶訪問輸入頁。有關 ASP.NET URL 授權的詳細信息，請參閱 MSDN Library 中的 Building Secure ASP.NET Applications（英文）。
- 在加載窗體或頁面時對用戶授權，以防止用戶在進程或任務出現錯誤時訪問用戶界面元素。例如，要求用戶在 ASP.NET 應用程序中填寫多個網頁之后才能完成操作。如果允許用戶在瀏覽器中直接輸入 URL，可能導致用戶能夠訪問那些在特定階段無權訪問的頁面。因此，加載頁面時應執行應用程序授權檢查。
- 請勿只將系統的安全設置建立在用戶界面中的應用程序授權之上。在業務層和數據層要執行其他的訪問檢查，因為有可能會以多種方式或從不同的應用程序中調用這些組件。
- 如果用戶界面限制用戶可以查看的數據，則請勿從數據源讀取不必要的數據，這樣可以避免受保護的數據在網絡傳輸中被泄露。
注意：以下主題的所有代碼示例均以 Web 窗體為例�？梢酝ㄟ^將 User.IsInRole 更改為 Thread.CurrentPrincipal.IsInRole，使代碼適用于 Windows 窗體。有關 IsInRole 方法和執行授權檢查的詳細信息，請參閱本指南后面的執行授權檢查。
改變窗體中的控件
在 Windows 窗體和 ASP.NET 應用程序中，都有可能需要根據授權改變控件在用戶界面中的顯示方式，包括改變某些控件的可見性或者禁用它們。
例如，在雇員費用申請的應用程序中，CanApproveClaims 角色的成員需要在窗體中使用一個按鈕批準申請，而所有不屬于該角色的用戶都看不到這個 Approve 按鈕。以下代碼說明實現該目的的方法：
如果用戶界面比較復雜或者有很多自定義的角色，那么在創建授權代碼時，以上這種過于簡單的方法會導致“if-then-else”語句鏈過長。
您可以使用以下技術來降低這種根據授權檢查顯示控件的復雜性：
- 合并邏輯 - 將改變控件的邏輯放到從窗體的 Load 事件中調用的私有方法內。這樣，就只用一個位置保存有關顯示控件的窗體授權邏輯。
以下代碼顯示了如何對 Web 窗體應用這種方法：
- 必要時使用中繼器控件 - 如果控件與多行數據相對應，可以使用中繼器控件，從而能夠同時修改所有的控件設置。
例如，如果您創建了一個使用 DataGrid 的 Web 窗體，則可以使用一個復選框模板列，允許已授權的用戶同時批準多項申請。
以下代碼說明了如何使用該技術在 DataGrid 中顯示 Approve 列。
- 使用模型視圖控制器模式 - 模型視圖控制器模式可以幫助您從控件激發的事件中分離控制用戶界面元素行為的邏輯。在費用申請示例中，窗體可以包含一個員工列表框和一個 Show Claims 按鈕。在按下 ShowClaims 時，通過將所有應執行的代碼放到另一個函數中（叫做控制器函數），甚至是另一個類中，可以強制實現清楚的邏輯分離。列表框充當員工數據的視圖，Show Claims 按鈕處理用戶操作（如“單擊”）并調用相關的控制器函數�？刂破骱瘮凳悄� Web 或 Windows 窗體上的一種方法，包含改變業務數據狀態和用戶界面狀態的邏輯。
將加載窗體之后改變控件狀態的授權代碼放在這些控制器函數中，而不要放在事件處理程序中。
- 為每個角色使用單獨的窗體 - 如果角色的數量比較少，而且每個角色需要完全不同的窗體，則可以為每個角色創建單獨的窗體。測試各個窗體中的角色成員關系，并重定向到正確的窗體中。這也許會增加大量的測試過程，但您可以使用前面介紹的模型視圖控制器模式降低由此帶來的工作量，并且還能重復使用顯示代碼。
改變頁面流
有時（比如典型向導的用戶界面）會根據用戶的角色成員關系，要求用戶完成多個窗體（或頁面）以執行業務流程。這種方法可以改變頁面的順序或“流”。
在上面的申請示例中，GeneralManager 成員可以查看并批準所有部門的員工申請，而 StoreManager 成員只能查看自己部門的員工申請。為了使 GeneralManager 成員可以選擇部門，需要另外創建一個步驟來檢索該信息，然后再顯示員工選擇窗體。
以下代碼說明了創建這種頁面流的方法。這段代碼使用 ASP.NET Server.Transfer 方法向不同的頁面傳遞控制。對 Server.Transfer 的調用包含在名為 DisplayNextPage 的私有方法中：
在業務層執行授權
業務過程可以是很簡單的業務邏輯，也可以是大型的、運行時間很長的、包含許多信任和非信任伙伴的工作流程。業務層代碼必須保證所有的客戶請求都能滿足組織規定的授權規則和邏輯規則。
您有如下需求時，請在業務層中創建訪問檢查：
- 對執行業務流程的操作進行授權。
- 在調用內部業務組件之前，對來自外部的、非信任源的調用進行授權。為此，需要創建一個 IPrincipal 對象，供授權過程中的業務流程使用。在標識進入業務流程時使用服務接口管理標識，或者對內部業務組件的調用進行授權，或者同時使用這兩種方法。
- 對分布式系統的其他部分或不屬于應用程序的外部服務的調用進行授權。為此，需要從組件之外管理標識流。使用服務代理來確保當前用戶可以執行外部調用和/或在標識溢出過程之外時可以處理標識。
在業務層創建授權代碼時，請使用以下最佳方案：
- 將授權能力分解到框架和實用程序組件，如自定義的 IPrincipal 對象。這將允許您創建獨立于業務邏輯的授權能力。
- 在高級別過程的開始處執行授權檢查。這樣可以在較少的位置配置授權，減少維護的工作量。
但要使解決方案更加安全，需要在每個可以公開訪問的方法中執行授權，因為對這些方法的調用可能未通過授權檢查。
在 .NET 和 COM+ 中使用基于角色的安全設置對比
COM+ 最有名的功能是可以為應用程序提供企業功能，如事務組件、異步激活和對象合并等。如果您要在 .NET 企業應用程序中使用這些功能，應該使用基于角色的 COM+ 安全設置，而不要使用基于角色的 .NET 安全設置�；诮巧� COM+ 安全系統和基于角色的 .NET 框架安全設置不能互相操作。因此，在設計初期，您就要確定在 COM+ 中駐留的組件和 .NET 類型的組件，否則以后將很難更改授權代碼。
有關如何確定基于角色的 .NET 安全系統和基于角色的 COM+ 安全系統的示例，請參閱 MSDN 雜志中的 Unify the Role-Based Security Models for Enterprise and Application Domains with .NET（英文）。
除了基于角色的安全設置以外，COM+ 還內置有傳遞 Windows 用戶上下文和前一調用者信息的能力。
注意：在組件中混合使用基于角色的 COM+ 和 .NET 安全設置是不安全的。因為在執行托管 COM+ 組件時，Windows 會在托管代碼和非托管代碼之間切換，從而導致重要信息不可靠。
有關基于角色的 COM+ 安全設置代碼示例，請參閱附錄中的如何使用 System.EnterpriseServices 基于角色的 COM+ 安全設置。有關在 .NET 應用程序中使用 COM+ 的詳細信息，請參閱 MSDN Library 中的 Understanding Enterprise Services (COM+) in .NET（英文）。
在業務邏輯組件中執行授權
包含業務邏輯的組件通常都需要執行授權檢查。您可以使用 .NET Remoting 或封裝業務組件的服務接口（如 XML Web Service）從用戶界面層的代碼中直接調用這些組件。
您創建的授權邏輯經常會與組件業務邏輯混合，并成為組件業務邏輯的一部分。有關如何分離業務邏輯和授權邏輯的詳細信息，請參閱本指南后面的分離業務邏輯和授權邏輯。有關如何創建授權檢查的詳細信息，請參閱本指南后面的使用基于角色的 .NET 安全設置創建授權代碼。
在實體中執行授權
實體表示數據，也可能包括一些行為方式�？梢允褂玫膶嶓w有許多，如 DataSet、XML 字符串、XML 文檔對象模型 (XML DOM)，以及應用程序中自定義的實體類，具體使用哪一類取決于應用程序的物理和邏輯設計限制。應用程序既生成實體又使用實體。
實體經常在應用程序層之間移動，包括從數據源檢索數據、發送到用戶界面再返回到數據源進行更新的整個過程。
您可以創建類來代表執行授權檢查的實體。例如，只有屬于某一角色的用戶才能創建和初始化實體對象。
但是，大多數情況下，不應在實體中執行應用程序授權，因為：
- 純數據實現（如 DataSet、XML 字符串和 XML DOM）不提供內置的執行應用程序授權檢查的方法。
- 實體（包括第三方提供的實體）的移動性很高�？蛻舳藨贸绦虿灰欢軌蚴褂脤嶓w授權功能。
在服務接口中執行授權
服務接口是將內部業務邏輯呈現給外部世界的窗口。服務接口向業務流程提供了一個入口點，使您可以靈活地改變內部流程的方法簽名，而不影響外部調用者。
非信任方或要求身份驗證和授權的一方訪問內部業務流程組件之前，服務接口為其提供入口。
在費用申請的示例中，服務接口使用 XML Web Service 允許非信任客戶訪問申請處理組件，使用 .NET Remoting 或分布式 COM (DCOM) 允許信任客戶訪問申請處理組件。服務接口也可以是自定義的消息隊列 (MSMQ) 偵聽器。
有關說明 XML Web Service 中授權的示例代碼，請參閱附錄中的如何在 XML Web Service 中執行授權。
在服務代理中執行授權
服務代理是業務邏輯和外部服務之間的一座橋梁。XML Web Service 和 MSMQ 消息隊列就是兩個外部服務代理的例子。
可以通過授權從業務層內部調用服務，使用服務代理控制對外部服務的訪問。服務代理作為外部服務的代理，在代碼調用外部服務時，使您可以執行驗證、授權、數據格式化和其他任務。使用服務代理還允許您改變被調用的外部服務及其簽名，而不影響您的業務邏輯�？梢栽谑跈喾⻊沾碇芯帉懘a，防止非授權的用戶調用外部服務。
注意：這種授權與在外部服務中進行的授權不同。如果您保持使用外部服務，必須在被調用者內執行授權檢查以確保系統的安全。
在下面的服務代理代碼中，如果用戶不屬于 CanApproveClaims 角色，他/她將不能向 ApproveClaim XML Web Service 方法傳遞 claimXML 消息。
有關處理授權代碼異常情況的詳細信息，請參閱本指南中的處理授權錯誤。
如果外部服務授權時要求使用特殊的用戶標識，請在服務代理中創建代碼，以傳遞可接受的 IIdentity 對象，從而將標識流傳遞到組件之外。有關管理標識流的詳細信息，請參閱本指南前面的設計用于授權的標識流。
在數據層執行授權
數據層是最后一道防線，用于抵御來自用戶界面、業務組件以及試圖直接訪問數據的攻擊者的非法請求。從授權的角度看，數據層確保只有經過批準的用戶才可以訪問和修改數據，而不管其訪問方式如何。
需要執行以下操作時，請在數據層中創建訪問檢查：
- 防止敏感數據泄露到數據層之外。
- 防止未經授權修改現有數據和插入新數據。
- 使用存儲過程或視圖限制對數據的訪問，而不是修改對數據表的直接訪問權限。
要在數據層執行授權，可以使用多種技術和對象，這取決于您的安全要求�？梢栽谝韵聰祿䦟咏M件中執行授權：
- 數據訪問邏輯組件 - 數據訪問邏輯組件負責從數據庫檢索數據、將數據保存回數據庫，還負責處理完成這些數據操作所需的邏輯請求。所有應用程序數據都是通過數據訪問邏輯組件在數據庫和應用程序的其他部分之間傳遞的。
- 存儲過程 - 存儲過程可以在數據庫中執行授權邏輯并檢索和更新數據。
- 數據庫安全功能 - 使用 SQL Server 內置的安全功能保護數據庫對象，例如表、列、視圖和存儲過程。
有關使用數據訪問邏輯組件和實體的詳細信息，請參閱 MSDN Library 中的 Designing Data Tier Components and Passing Data Through Tiers（英文）。
以下這些問題能幫助您選擇數據層的授權策略：
- 授權邏輯有多復雜？
- 簡單 - 在存儲過程中執行授權檢查。
- 復雜 - 在數據訪問邏輯組件中執行授權，并調用不同的存儲過程。
- 存儲過程的復雜程度如何？
- 簡單 - 在數據訪問邏輯組件中執行授權檢查，并調用不同的存儲過程（如果創建多個執行相似操作的存儲過程不會增加維護難度）。
- 復雜 - 在存儲過程中執行授權檢查，該存儲過程具有向授權檢查提供信息的參數。
如果創建執行相似操作的多個存儲過程會增加維護的難度，則可以向存儲過程傳遞一個值以減少存儲過程的數量。
- 有多少存儲過程會涉及授權檢查？
- 較少 - 創建多個涉及授權檢查的存儲過程版本。創建明顯地鏈接存儲過程的命名標準，例如 GetClaimsMGR 和 GetClaimsEMP。但這種方法在應用程序的開發過程中對設計是不利的，因此要慎用。
- 較多 - 創建多個單獨的存儲過程，根據連接的用戶的不同檢索不同的數據。使用表示應用程序角色的服務帳戶連接到數據庫，允許存儲過程執行授權檢查。這種方法最大限度地減少了存儲過程的數量，因而也減少了維護的工作量。
在數據層創建授權代碼時，請使用以下最佳方案：
- 連接到服務帳戶較少的數據庫，以使連接池的性能達到最優。當連接信息（如用戶信息）與現有連接匹配時，連接池允許應用程序重復使用連接。因此，不必為每個用戶創建連接。
有關連接管理的詳細信息，請參閱 MSDN Library 的 .NET Data Access Architecture Guide（英文）中的“Managing Database Connections”。
- 用 GRANT 和 DENY 權限保護數據庫對象。
拒絕對數據表的直接訪問可以使用應用程序（如查詢分析器）防止連接到數據庫的用戶，而不會強制對數據的業務邏輯進行更新或查詢。只有允許的用戶/服務帳戶可以訪問存儲過程和視圖。
- 在使用包括 WHERE 子句的應用程序授權技術時，始終使用存儲過程。這樣有助于防止 SQL 夾帶攻擊，實施這類攻擊的攻擊者會將其他的（通常是惡意的）SQL 語句附加到合法的 WHERE 子句中。有關 SQL 夾帶攻擊的詳細信息，請參閱 MSDN Library 中的 Building Secure ASP.NET Applications（英文）。
在數據訪問邏輯組件中執行授權
數據訪問邏輯組件是在訪問數據庫之前最后一個提供功能的組件。因此，您可以利用它們來確保只有獲得授權的用戶才可以訪問或修改數據。
出現以下情形時，請在數據訪問邏輯組件中執行授權：
- 多個應用程序使用相同的數據訪問邏輯組件。
- 需要對數據訪問邏輯組件或數據存儲庫提供的強大功能的訪問進行保護。
- 需要限制用戶對敏感數據的訪問。
在數據訪問邏輯組件中使用基于角色的安全設置的例子包括：在數據傳遞到其他應用程序層之前對數據進行過濾、控制代碼執行的存儲過程。
有關如何執行授權檢查的詳細信息，請參閱本指南后面的執行授權檢查。
在數據訪問邏輯組件中過濾數據
為了保證只向其他應用程序層返回適當的信息，應該在數據訪問邏輯組件代碼中有選擇地刪除敏感數據。
下面的代碼示例在用戶不屬于 Manager 角色時，刪除數據的 ConfidentialNotes 列。
從數據庫中檢索不需要的列是對資源的一種浪費，尤其是不需要的列很多時。相反，使用存儲過程只選擇必要的數據，可以改善數據庫引擎的性能。
從數據訪問邏輯組件調用不同的存儲過程
您可以創建僅為一個角色返回正確數據的多個存儲過程。然后，數據訪問邏輯組件代碼執行授權檢查，根據用戶角色確定要使用哪些存儲過程。
例如，可以為 Manager 創建一個存儲過程版本，為 Employee 創建另一個不同的版本，兩者只是檢索的數據不同。數據訪問邏輯組件代碼將檢查用戶的角色成員關系，并調用正確的存儲過程。
以下代碼顯示了數據訪問邏輯組件方法如何根據用戶的角色成員關系選擇要調用的存儲過程。這些代碼使用了一個輔助類，以避免顯示過多的 ADO.NET 代碼。Microsoft Application Blocks for .NET（英文）提供了 SqlHelper 類：
在存儲過程中執行授權
在存儲過程中執行授權的方法主要有兩種：
- 傳遞角色標志 - 在數據訪問邏輯組件中執行授權檢查，將授權結果標志傳遞到存儲過程。這樣將允許存儲過程根據授權標志過濾數據，如以下代碼所示。
- 傳遞用戶標識或其他角色信息 - 數據訪問邏輯組件將用戶標識作為參數傳遞到存儲過程。然后，存儲過程使用該參數來查找用戶的角色成員關系并選擇數據，如以下代碼所示。
在數據庫中執行授權
以數據庫安全功能作為安全解決方案的基礎。然后在數據庫安全功能之上使用存儲過程設計應用程序授權，如本指南前面所述。
使用數據庫安全功能執行授權：
- 使用 SQL 數據定義語言 (DDL) 安全語句，如 GRANT、DENY 和 REVOKE，控制對表、列、視圖、存儲過程和其他數據對象的訪問。
- 以可能的最低級別（只有數據）限制對敏感數據的訪問。SQL Server 本身不支持低級別授權，但是，您可以通過創建視圖和存儲過程來模擬低級別授權，本主題的后面將介紹有關內容。
- 盡可能地加強安全性。注意，較高的安全性會降低可伸縮性。
在數據庫中執行授權之前，必須選擇應用程序連接到數據庫的方式。
使用 SQL 角色簡化管理
設計系統時，必須考慮使用 SQL Server 角色簡化對 SQL Server 的維護。SQL Server 提供了多種角色，包括：
- 用戶定義的數據庫角色 - 由數據庫唯一的 sp_addrole 存儲過程創建的角色。然后可以使用 sp_addrolemember 存儲過程向這些角色添加 SQL 用戶。
- 應用程序角色 - 為應用程序而不是為 Windows 用戶或組創建的角色。
- 固定的數據庫角色 - 鏈接到通用數據庫功能的固定角色，例如 SQL 管理員和數據庫創建者：sysadmin 和 dbcreator。
有關 SQL Server 安全性、授權和授權角色的詳細信息，請參閱 MSDN Library 中的 Building Secure ASP.NET Applications（英文）。
考慮將應用程序角色鏈接到 SQL Server 角色，使應用程序和 SQL Server 的管理一致。將直接映射到 SQL 角色的服務帳戶連接到數據庫，以實現這種鏈接。下面一節介紹了這種技術。
連接到數據庫
為了控制對表、列、視圖、存儲過程和其他數據對象的訪問，SQL Server 必許能夠識別需要授權的用戶，這種識別可以通過以下連接方法實現：
- Windows 身份驗證 - 如果將 SQL Server 配置為只使用 Windows 身份驗證，則必須在用戶上下文中執行建立連接的過程。SQL Server 使用該 Windows 用戶帳戶進行所有形式的授權。
這種方法提供的連接最安全，因為它不通過線路傳遞憑據。
- SQL Server 身份驗證（混合安全設置）- 如果將 SQL Server 配置為使用 SQL Server 和 Windows 身份驗證，則既可以使用 Windows 身份驗證，也可以使用用戶名和密碼在連接字符串中指定用戶來進行身份驗證。
無論以何種方式連接到數據庫，都要先創建幾個代表應用程序角色的服務帳戶，然后根據角色要求，為各個服務帳戶授予權限。
例如，創建 USR_MANAGER 和 USR_APPROVER 等服務帳戶以實現最少特權的原則，即只允許訪問一部分應用程序功能。
這種方法會帶來某些不便，因為當您使用 Windows 身份驗證連接到數據庫時，需要從數據訪問邏輯組件模擬服務帳戶。
有關管理數據庫連接的詳細信息，請參閱 MSDN Library 中的 .NET Data Access Architecture Guide（英文）。
控制對敏感列的訪問
使用 T-SQL 語句或 SQL Server 企業管理器實用程序，在列級別應用 GRANT、DENY 和 REVOKE 權限，從而實現對列的訪問控制。請盡量少用這種授權技術，因為如果數據庫很大，要維護的列權限列表會很長，在實際操作中非常耗時。如果您要使用這種技術，請在連接到數據庫時使用服務帳戶，以使維護工作易于管理。
控制對敏感行的訪問
SQL Server 沒有隱含地讓您控制對各行的訪問。但是，您可以向數據表添加安全列，創建控制行的功能。安全列可以保存單獨的用戶名或訪問數據需要的最低角色（假設角色的組織形式是分層的）。安全列允許您限制對各行的訪問，但是如果用戶可以直接訪問數據表，該技術將沒有效果。
可以結合使用視圖或存儲過程中數據表的安全列功能和 SUSER_SNAME 函數，控制對各行的訪問。SUSER_SNAME 函數將檢索連接的用戶名（很可能是服務帳戶名）。
以下代碼顯示如何創建一個視圖，該視圖只返回當前用戶的行。
注意：該方法要求您在連接數據庫時使用單獨的用戶標識，以便 SUSER_SNAME 函數能夠檢索到正確的信息
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
