構(gòu)建安全的ASP.NET應(yīng)用程序

1、構(gòu)建安全的 ASP.NET 應(yīng)用程身份驗證、授權(quán)和安全通信第3章一身份驗證和授權(quán)J.D. Meier、Alex Mackman、Michael Dunner 和 Srinath VasireddyMicrosoft Corporation2002年10月有關(guān)構(gòu)建安全的ASPNET應(yīng)用程序的起點和完整概述，請參見登陸頁面?？偨Y(jié)本章提供指導(dǎo)信息，幫助您為您的特定應(yīng)用程序方案制定合適的授權(quán)策略。還將幫 助您選擇最合適的身份驗證和授權(quán)技術(shù)，并在應(yīng)用程序正確的地方進行應(yīng)用。內(nèi)容設(shè)計身份驗證和授權(quán)策略授權(quán)方式傳遞身份基于角色授權(quán)選擇身份驗證機制總結(jié)為分布式 Web應(yīng)用程序設(shè)計身份驗證和授權(quán)策略是一項具有挑

2、戰(zhàn)性的任務(wù)。令人 欣慰的是，在應(yīng)用程序開發(fā)的早期階段，正確設(shè)計身份驗證和授權(quán)將有助于降低許 多安全方面的主要風(fēng)險。本章將幫助您為應(yīng)用程序設(shè)計合適的授權(quán)策略，還將幫助您解答下列關(guān)鍵問題：應(yīng)該在什么情況下執(zhí)行授權(quán)，使用什么機制？應(yīng)該使用什么身份驗證機制？應(yīng)該用 Active Directory? 目錄服務(wù)來進行身份驗證，還是應(yīng)該對照自定義數(shù) 據(jù)存儲來驗證憑據(jù)？使用異類和同類平臺分別意味著什么？在設(shè)計上有哪些需要注意的地方？在應(yīng)用程序中應(yīng)該如彳5表示不使用Microsoft? Windows? 操作系統(tǒng)的用在應(yīng)用程序的各層之間應(yīng)該如何傳遞用戶身份？在什么情況下應(yīng)該使用操作 系統(tǒng)級模擬/委派？當(dāng)您考慮

3、授權(quán)時，也必須考慮身份驗證。兩個過程是同時進行的，這有兩方面的原 因：第一，任何有意義的授權(quán)策略都需要已驗證身份的用戶。第二，驗證用戶身份的方式（具體說，就是如何在應(yīng)用程序中表示已經(jīng)過驗 證的用戶身份）將決定您可支配的關(guān)守。某些關(guān)守（如，ASP.NET 文件授權(quán)、Enterprise Services （COM+）角色和Windows ACL ）要求某一身份需經(jīng)過Windows以WindowsIdentity 對象形式（該對象封裝了定義調(diào)用方安全上下文的Windows訪問令牌）驗證，而其他關(guān)守（如，ASP.NET URL授權(quán)和.NET角色）則沒有這一要求。它們只要 求身份經(jīng)過驗證即可，并不需要

4、一定是由Windows訪問令牌來表示。設(shè)計身份驗證和授權(quán)策略下列步驟確定了幫助您為應(yīng)用程序制定身份驗證和授權(quán)策略的過程：.確定資源.選擇授權(quán)策略.選擇用于資源訪問的身份.考慮身份傳遞.選擇身份驗證方法.決定如何傳遞身份確定資源確定應(yīng)用程序需要向客戶端公開的資源。典型資源包括：Web Server資源，例如 Web頁、Web服務(wù)、靜態(tài)資源（HTML頁面和圖像）,數(shù)據(jù)庫資源，例如每用戶數(shù)據(jù)或應(yīng)用程序范圍的數(shù)據(jù)。網(wǎng)絡(luò)資源，例如遠程文件系統(tǒng)資源和來自目錄存儲（如 Active Directory）的 數(shù)據(jù)。還必須確定應(yīng)用程序需要訪問的系統(tǒng)資源。這些資源與向客戶端公開的資源相反， 是不公開的。它們包括注

5、冊表、事件日志和配置文件。選擇授權(quán)策略有兩種基本授權(quán)策略：基于角色。對操作（通常是方法）的訪問是根據(jù)調(diào)用方的角色成員身份來加 以保護的。使用角色將應(yīng)用程序的用戶群分為在應(yīng)用程序內(nèi)共享相同安全權(quán) 限的用戶組，例如“高級經(jīng)理”、“經(jīng)理”和“職員”。用戶被映射到角色，如 果用戶有權(quán)執(zhí)行所請求的操作，那么應(yīng)用程序?qū)⑹褂霉潭ㄉ矸菰L問資源。這 些身份被各自的資源管理器（例如數(shù)據(jù)庫、文件系統(tǒng)等）所信任?；谫Y源。使用 Windows ACL分別保護各個資源。應(yīng)用程序在訪問資源之 前模擬調(diào)用方，這使操作系統(tǒng)可以執(zhí)行標(biāo)準(zhǔn)訪問檢查。所有資源訪問都是使 用原調(diào)用方的安全上下文執(zhí)行的。此模擬方法嚴(yán)重影響應(yīng)用程序的可擴

6、展性， 因為這意味著在應(yīng)用程序的中間層無法高效地使用連接池。在絕大多數(shù)必須進行擴展的.NET Web應(yīng)用程序中，基于角色的授權(quán)方法是最佳選擇。而某些規(guī)模較小的Intranet應(yīng)用程序則從各種資源（如文件）中提取單個用戶信息，當(dāng)各個用戶訪問這些資源時，這些資源是通過Windows ACL加以保護的，因此更適合采用基于資源的授權(quán)方法。在進行基于角色的授權(quán)時，所推薦使用的和常見的做法是：在前端 Web應(yīng)用程序中驗證用戶身份。將用戶映射到角色。根據(jù)角色成員身份授權(quán)對操作（不是直接對資源）進行訪問。通過使用固定服務(wù)身份，訪問必要的后端資源（用來支持所請求和授權(quán)的操 作）。后端資源管理器（例如數(shù)據(jù)庫）信任

7、應(yīng)用程序可以授權(quán)調(diào)用方，并且愿意將權(quán)限授予被信任的服務(wù)身份。例如，數(shù)據(jù)庫管理員可以將訪問權(quán)限只授予特定人力資源應(yīng)用程序（而不是 授予個別用戶）。更多信息有關(guān)這兩種截然不同的授權(quán)方法，請參見本章后面的“授權(quán)方法”。有關(guān)基于角色授權(quán)和各種可以使用的角色類型，請參見本章后面的“基于角 色授權(quán)”。選擇用于資源訪問的身份請回答這樣的問題：“誰將訪問資源？”選擇用來在應(yīng)用程序各個層級進行資源訪問的身份。這些資源可以由基于Web的應(yīng)用程序來訪問，還可以由Web服務(wù)、Enterprise Services和.NET遠程處理組件訪問。一般來講，用于資源訪問的身份可以是以下幾類：原調(diào)用方身份。它采用一種模擬/委派

8、模式，即可以獲得原調(diào)用方身份，然后 將此身份在系統(tǒng)的每一層之間傳遞。委派因素是用于確定身份驗證機制的重 要標(biāo)準(zhǔn)。進程身份。這是默認(rèn)情況（沒有具體的模擬）。使用當(dāng)前進程身份可以訪問本 地資源并進行下游調(diào)用。這一方法是否可行取決于被跨越的邊界，因為進程 身份必須被目標(biāo)系統(tǒng)識別。這意味著要用以下方式之一來進行調(diào)用： 在同一 Windows安全域中 跨 Windows安全域（使用信任和域帳戶，如果不存在信任關(guān)系，則使用 重復(fù)的用戶名和密碼） 服務(wù)帳戶。這一方法使用一個（固定）服務(wù)帳戶。例如： 如果是訪問數(shù)據(jù)庫，它可以是與數(shù)據(jù)庫連接的組件提供的固定SQL用戶名和密碼。 當(dāng)需要固定 Windows身份時，

9、則可以使用 Enterprise Services服務(wù)器應(yīng) 用程序。自定義身份。當(dāng)沒有可用的 Windows帳戶時，您可以構(gòu)建自己的身份 （使用 Principal和Identity ）,它將包含您指定的安全上下文的具體內(nèi)容。例如， 它可以包含角色列表、唯一標(biāo)識符，或任何其他類型的自定義信息。通過用Principal和Identity 類型實現(xiàn)您的自定義身份，并將 Principal 和Identity 類型放在當(dāng)前的 Web上下文（使用 HttpContext.User ）中，您可以直接從內(nèi)置的關(guān)守（如.NET角色和 PrincipalPermission請求）中獲益?？紤]身份傳遞要支持每用

10、戶授權(quán)、審核和每用戶數(shù)據(jù)檢索，您可能需要在不同的應(yīng)用程序?qū)又泻?在不同計算機之間傳遞原調(diào)用方身份。例如，如果某個后端資源管理器需要執(zhí)行每 調(diào)用方授權(quán)，調(diào)用方的身份就必須傳遞給該資源管理器。您要根據(jù)系統(tǒng)的資源管理器授權(quán)要求和審核要求來確定需要在應(yīng)用程序中傳遞的身 份。選擇身份驗證方法影響身份驗證方法選擇有兩個關(guān)鍵因素：第一，也是最重要的因素是，應(yīng)用程序的用戶群的特點（他們使用哪一類瀏覽器以及他們是否有Windows帳戶），第二是,應(yīng)用程序的模擬/委派和審核要求。更多信息有關(guān)幫助您為應(yīng)用程序選擇身份驗證機制的更多具體注意事項，請參見本章后面的 “選擇身份驗證機制”。決定如何傳遞身份可以在應(yīng)用程序級

11、傳遞身份（以提供安全上下文），也可以在操作系統(tǒng)級傳遞身份和 安全上下文。要在應(yīng)用程序級傳遞身份，請使用方法和存儲過程參數(shù)。應(yīng)用程序身份傳遞支持：使用受信任的查詢參數(shù)檢索每用戶數(shù)據(jù)SELECT x,y FROM SomeTable WHERE username=bob在任何應(yīng)用程序?qū)又凶远x審核操作系統(tǒng)身份傳遞支持：平臺級審核（例如 Windows審核和SQL Server審核）基于 Windows身份的每用戶授權(quán)要在操作系統(tǒng)級傳遞身份，可以使用模擬/委派模式。在某些情況下，可以使用Kerberos委派，而在另一些情況下（多半是環(huán)境不支持Kerberos）,可能需要使用其他方法，例如使用“基本”

12、身份驗證。在“基本”身份驗證中，用戶憑據(jù)可由服 務(wù)器應(yīng)用程序使用，還可以用于訪問下游網(wǎng)絡(luò)資源。更多信息有關(guān)傳遞身份和如何用網(wǎng)絡(luò)憑據(jù)獲得模擬令牌（即支持委派）的更多信息，請參見本章后面的“傳遞身份”。授權(quán)方法有兩種基本授權(quán)方法：基于角色。用戶被劃分為應(yīng)用程序定義的邏輯角色。在應(yīng)用程序中，某一特 定角色的成員將共享相同的權(quán)限。對操作（通常由方法調(diào)用表示）的訪問是 根據(jù)調(diào)用方的角色成員身份進行授權(quán)的?？梢杂霉潭ㄉ矸荩ɡ鏦eb應(yīng)用程序固定身份或Web服務(wù)的進程身份）訪 問資源。資源管理器信任應(yīng)用程序可以正確授權(quán)用戶，并且它們將權(quán)限授予 受信任的身份。基于資源。各個資源是通過 Windows ACL得

13、到保護的。ACL將決定哪些用 戶可以訪問資源，還決定每個用戶可以執(zhí)行哪類操作（讀取、寫入、刪除等）?？梢允褂迷{(diào)用方身份（使用模擬）訪問資源?；诮巧诨诮巧ɑ虿僮鳎┑陌踩椒ㄖ校瑢Σ僮鳎ǘ呛蠖速Y源）的訪問是根據(jù)調(diào)用 方的角色成員身份進行授予的。角色（在設(shè)計應(yīng)用程序時分析和定義）被用作邏輯 容器，它們將應(yīng)用程序中共享同一安全權(quán)限（或功能）的用戶組合起來。用戶被映 射到應(yīng)用程序中的角色，而角色成員身份用來控制對應(yīng)用程序公開的特定操作（方 法）的訪問權(quán)。在應(yīng)用程序的什么位置映射角色是設(shè)計中需要考慮的一個關(guān)鍵因素；例如：第一種情況是，可以在后端資源管理器（如數(shù)據(jù)庫）中映射角色。它要求原 調(diào)用方

14、的安全上下文通過應(yīng)用程序的各層傳遞到后端數(shù)據(jù)庫。另一種情況是在前端 Web應(yīng)用程序中映射角色。 如果是運用這種方法， 那么 就要通過固定身份來訪問下游資源管理器，各資源管理器就會層層把關(guān)，進 行授權(quán)和信任。第三種選擇是在前端層和后端層之間的某個位置進行角色映射；例如：在中 間層 Enterprise Services應(yīng)用程序中。在多層 Web應(yīng)用程序中，使用受信任的身份訪問后端資源管理器為應(yīng)用程序可擴展性提供了更大的機會 （這歸功于連接池）。另外，使用受信任的身份減少了在操作 系統(tǒng)級傳遞原調(diào)用方安全上下文的需要，而這種需要可能是很難（如果在某些情況 中并非不可能）實現(xiàn)的?；谫Y源基于資源的授權(quán)

15、方法依賴于Windows ACL和操作系統(tǒng)基本的訪問控制機制。應(yīng)用程序模擬調(diào)用方，將執(zhí)行訪問檢查的任務(wù)留給了與特定資源管理器（文件系統(tǒng)、數(shù) 據(jù)庫等）關(guān)聯(lián)的操作系統(tǒng)。這種方法通常最適合于這樣的應(yīng)用程序，即用它們來訪問可通過Windows ACL加以個別保護的資源，如文件資源。FTP應(yīng)用程序或簡單的數(shù)據(jù)驅(qū)動Web應(yīng)用程序就屬于這類應(yīng)用程序。如果被請求資源中的數(shù)據(jù)需要從多個不同來源（如多個數(shù)據(jù) 庫、數(shù)據(jù)庫表、外部應(yīng)用程序或Web服務(wù)等）獲取和合并，那么這種方法就力不從心了。基于資源的方法還依賴于傳遞到應(yīng)用程序后端資源管理器的原調(diào)用方的安全上下 文。這需要進行復(fù)雜的配置，而且會大大降低多層應(yīng)用程序增加

16、受訪的能力，因為 使用這種方法，您就無法在應(yīng)用程序中間層有效運用集合功能（如數(shù)據(jù)庫連接集合）。資源訪問模式通過研究.NET Web應(yīng)用程序（以及一般情況下分布式多層應(yīng)用程序）最常用的兩 種資源訪問安全模式，我們可以看到有兩種截然不同的授權(quán)方法。這兩種模式是：受信任的子系統(tǒng)模式模擬/委派模式兩種模式在安全和可擴展性方面都各有優(yōu)缺點。以下各節(jié)將介紹這些模式。受信任的子系統(tǒng)模式在此模式中，中間層服務(wù)使用固定身份訪問下游服務(wù)和資源。原調(diào)用方的安全上下 文不在操作系統(tǒng)級通過服務(wù)傳遞，但應(yīng)用程序可以選擇在應(yīng)用程序級傳遞原調(diào)用方 身份。它這樣做可能是需要支持后端審核要求，或支持每用戶數(shù)據(jù)訪問和授權(quán)。該模式之

17、所以得此名稱是因為下游服務(wù)（或許是數(shù)據(jù)庫）在授權(quán)調(diào)用方時信任上游服務(wù)。圖3.1顯示了此模式。請?zhí)貏e注意信任界限。 在這個例子中，數(shù)據(jù)庫信任 中 間層可以授權(quán)調(diào)用方，并只允許被授權(quán)的調(diào)用方使用受信任的身份訪問數(shù)據(jù)庫。Web服務(wù)器或 應(yīng)用程序服務(wù)器數(shù)據(jù)庫服務(wù)器Insert figure: CH03 - TrustedSubSystem.gif圖3.1受信任的子系統(tǒng)模式在受信任的子系統(tǒng)模式中，資源訪問步驟如下：驗證用戶的身份將用戶映射到角色根據(jù)角色成員身份進行授權(quán)使用固定的受信任身份訪問下游資源管理器固定身份用于訪問下游系統(tǒng)和資源管理器的固定身份通常由預(yù)配置的Windows帳戶（稱為服務(wù)帳戶）提供。

18、在Microsoft SQL Server?資源管理器中，這意味著對 SQL Server使用Windows身份驗證。另一種情況是，某些應(yīng)用程序使用指定的SQL帳戶（由連接字符串中的用戶名和密碼指定）訪問 SQL Server。在這種情況下，必須為數(shù)據(jù)庫配置 SQL身份驗證。有關(guān)與 SQL Server通信時 Windows和SQL身份驗證的相對優(yōu)點，請參見第12章“數(shù)據(jù)訪問安全性”。使用多個受信任的身份一些資源管理器可能需要根據(jù)調(diào)用方的角色成員身份，執(zhí)行更進一步細(xì)分的授權(quán)。例如，您可能有兩組用戶，一組應(yīng)被授權(quán)執(zhí)行讀取/寫入操作，另一組則應(yīng)被授權(quán)執(zhí)行只讀操作。請看下面的 SQL Server方

19、法：創(chuàng)建兩個 Windows帳戶，一個用于讀取操作，一個用于讀取/寫入操作。更通常的情況是，用不同的帳戶映射應(yīng)用程序特定的角色。例如，您可能需要為Internet用戶使用一個帳戶，為內(nèi)部操作員和/或管理員使用另一個帳戶。將每個帳戶映射到一個SQL Server用戶定義的數(shù)據(jù)庫角色， 并且為每個角色建立必要的數(shù)據(jù)庫權(quán)限。將用戶映射到應(yīng)用程序中的角色，并使用角色成員身份確定連接到數(shù)據(jù)庫之 前模擬的帳戶。圖3.2中顯示了這一方法。服務(wù)器或應(yīng)用程序服務(wù)器數(shù)據(jù)庫服務(wù)器Insert figure: CH03 Trusted Subsystem- Multiple Identities.gif圖3.2使用多

20、種身份訪問數(shù)據(jù)庫以支持更細(xì)分的授權(quán)模擬/委派模式在此模式中，服務(wù)或組件（通常在邏輯業(yè)務(wù)服務(wù)層中的某處）在訪問下一個下游服 務(wù)之前模擬客戶端的身份（使用操作系統(tǒng)級模擬）。如果下一個服務(wù)在同一臺計算機 上，模擬就足夠了。如果下游服務(wù)位于遠程計算機上，則需要委派。委派的結(jié)果是，用于下游資源訪問的安全上下文是客戶端的安全上下文。使用此模 式通常是由于幾個原因：它允許下游服務(wù)使用原調(diào)用方身份執(zhí)行每調(diào)用方授權(quán)。它允許下游服務(wù)使用操作系統(tǒng)級審核功能。這一方法的一個具體示例是，中間層Enterprise Services組件在訪問數(shù)據(jù)庫之前可以模擬調(diào)用方。使用依賴于原調(diào)用方的安全上下文的數(shù)據(jù)庫連接訪問數(shù)據(jù)庫。

21、在此 模式中，數(shù)據(jù)庫驗證每個調(diào)用方的身份，并基于指派給各調(diào)用方的身份（或調(diào)用方 的Windows組成員身份）的權(quán)限做出授權(quán)決定。圖 3.3顯示了模擬/委派模式。w如果在方法級使用說明性檢查(以確定哪些用戶可以調(diào)用哪些方法)就足夠的話， 可以使用“組件服務(wù)”管理工具部署應(yīng)用程序和更新角色成員身份。如果需要用方法代碼以編程方式進行檢查，您將會失去Enterprise Services (COM+)角色的一些管理和部署優(yōu)點，因為角色邏輯是硬編碼的。SQL Server用戶定義的數(shù)據(jù)庫角色在這一方法中，您在數(shù)據(jù)庫中創(chuàng)建角色、基于角色分配權(quán)限并將Windows組和用戶帳戶映射到角色。這一方法要求您將調(diào)用

22、方的身份傳遞到后端(如果您對SQLServer使用首選的 Windows身份驗證)。SQL Server應(yīng)用程序角色在這一方法中，對數(shù)據(jù)庫中的角色授予權(quán)限，但是SQL Server應(yīng)用程序角色不包含用戶或組帳戶。因此，您將丟失原調(diào)用方的粒度。在應(yīng)用程序角色中， 您被授權(quán)訪問特定的應(yīng)用程序(與一組用戶相對)。此應(yīng)用程序使用接受角色名稱和密碼的內(nèi)置存儲過程激活角色。這一方法的一個主要缺點是它 要求應(yīng)用程序安全管理憑據(jù)(角色名稱和關(guān)聯(lián)的密碼)。更多信息有關(guān)SQL Server用戶定義的數(shù)據(jù)庫角色和應(yīng)用程序角色的詳細(xì)信息，請參見第12章“數(shù)據(jù)訪問安全性”。.NET 角色與 Enterprise Ser

23、vices (COM+) 角色的對比下表顯示了 .NET角色和 Enterprise Services (COM+)角色的功能對比。表3.2： Enterprise Services角色 與.NET角色的對比功能Enterprise Services色角.NET角色管理組件服務(wù)管理工具自定義數(shù)據(jù)存儲COM+目錄自定義數(shù)據(jù) 存儲(如 SQL Server或Active Directory )說明性是SecurityRole(Manager)是PrincipalPermission( SecurityAction.Demand,Role=Manager)命令性是ContextUtil.IsCall

24、erInRol e()是IPrincipal.IsInRole類、接口和方法是是級粒度可擴展否是（使用自定義 IPrincipal實現(xiàn)）可供所有.NET只供派生自是組件使用ServicedComponent 基類的組件使用角色成員角色包含Windows組或用戶當(dāng)使用 WindowsPrincipals 時，帳戶角色是 Windows組一沒有額外的抽象級別需要顯式接口是否實現(xiàn)要獲取方法級的身份驗證，必須明確定義并實現(xiàn)接口使用.NET角色您可以使用.NET角色保護以下各項的安全：文件文件夾Web 頁（.aspx 文件）Web服務(wù)（.asmx文件）對象方法和屬性方法中的代碼塊您可以使用.NET角色保

25、護操作（由方法和屬性執(zhí)行）和特定代碼塊的事實，意味 著您可以保護對應(yīng)用程序所訪問的本地和遠程資源的訪問。注意：使用 UrlAuthorizationModule 保護上述列表的前四項（文件、文件夾、Web頁和 Web服務(wù)），UrlAuthorizationModule 可以利用調(diào)用方的角色成員身 份（和調(diào)用方的身份）做出授權(quán)決定。如果您使用 Windows身份驗證，系統(tǒng)會為您完成使用.NET角色所需的大部分工作。ASP.NET 會構(gòu)建 WindowsPrincipal對象，用戶的 Windows組成員身份確定 關(guān)聯(lián)的角色集。要在非 Windows身份驗證機制中使用 .NET角色，必須編寫代碼執(zhí)

26、行以下操作：捕獲用戶的憑據(jù)。對照自定義數(shù)據(jù)存儲（如 SQL Server數(shù)據(jù)庫）驗證用戶的憑據(jù)。檢索角色列表、構(gòu)建GenericPrincipal對象并將它與當(dāng)前的Web請求關(guān)聯(lián)。GenericPrincipal對象表示已驗證身份的用戶并用于后面的.NET角色檢查，例如說明T* PrincipalPermission 命令和編程方式的 IPrincipal.IsInRole 檢查。更多信息有關(guān)為“表單”身份驗證創(chuàng)建GenericPrincipal對象所涉及過程的詳細(xì)信息，請參見第 8章“ASP.NET 安全性。檢查角色成員身份可使用以下類型的.NET角色檢查：重要信息：.NET角色檢查依賴于

27、Principal對象(表示已驗證身份的用戶)是 否與當(dāng)前請求關(guān)聯(lián)。對于ASP.NET Web應(yīng)用程序，Principal對象必須附加到HttpContext.User。對于 Windows窗體應(yīng)用程序，Principal對象必須附加到 Thread.CurrentPrincipal 。手動角色檢查。對于細(xì)分授權(quán)，您可以調(diào)用 IPrincipal.IsInRole 方法，基于 調(diào)用方的角色成員身份授予對特定代碼塊的訪問。當(dāng)檢查角色成員身份時， AND和OR邏輯都可以使用。說明性角色檢查 (方法入口)。您可以用 PrincipalPermissionAttribute 類(可 以簡寫為Princ

28、ipalPermission )對方法進行注釋，以聲明方式請求角色成員 身份。這些檢查只支持OR邏輯。例如，您可以要求調(diào)用方至少有一個特定的角色(例如，調(diào)用方必須是出納或經(jīng)理)。不能用說明性檢查指定調(diào)用方必須是經(jīng)理和出納。命令性角色檢查(在方法中檢查)?？梢栽诖a中調(diào)用 PrincipalPermission.Demand 執(zhí)行細(xì)分授權(quán)邏輯。支持邏輯 AND 和 OR運角色檢查示例下面的代碼片段顯示了一些使用編程、說明性和命令性方法的角色檢查示例。授權(quán)Bob執(zhí)行操作：使您可以授權(quán)在應(yīng)用程序中共享相同特權(quán)的用戶組。直接用戶名檢查Genericidentity useridentity = new

29、 GenericIdentity(Bob);if (userIdentity.Name=Bob) 說明性檢查PrincipalPermissionAttribute(SecurityAction.Demand, User=Bob) public void DoPrivilegedMethod() 命令性檢查PrincipalPermission permCheckUser = new PrincipalPermission(Bob, null);permCheckUser.Demand();授權(quán)出納執(zhí)行操作:直接角色名稱檢查Genericidentity useridentity = new

30、GenericIdentity(Bob);/從自定義數(shù)據(jù)存儲中檢索角色名稱string口 roles = new StringManager, Teller;GenericPrincipal userPrincipal = new GenericPrincipal(userIdentity, roles);if (userPrincipal.IsInRole(Teller)說明性檢查PrincipalPermissionAttribute(SecurityAction.Demand, Role=Teller) void SomeTellerOnlyMethod()命令性檢查public Som

31、eMethod()Principalpermission permCheck = new PrincipalPermission(null,Teller);permCheck.Demand();/只有出納可以執(zhí)行下面的代碼/任何非出納角色成員將導(dǎo)致安全異常.授權(quán)經(jīng)理或出納執(zhí)行操作：直接角色名稱檢查if (Thread.CurrentPrincipal.IsInRole(Teller) |Thread.CurrentPrincipal.IsInRole(Manager)/執(zhí)行特權(quán)操作說明性檢查PrincipalPermissionAttribute(SecurityAction.Demand,

32、Role=Teller), PrincipalPermissionAttribute(SecurityAction.Demand, Role=Manager) public void DoPrivilegedMethod()命令性檢查Principalpermission permCheckTellers = new PrincipalPermission( null,Teller);Principalpermission permCheckManagers = new PrincipalPermission(null,Manager);(permCheckTellers.Union(perm

33、CheckManagers).Demand();僅授權(quán)那些既是經(jīng)理又是出納的用戶執(zhí)行操作：直接角色名稱檢查if (Thread.CurrentPrincipal.IsInRole(Teller) &Thread.CurrentPrincipal.IsInRole(Manager)/執(zhí)行特權(quán)操作說明性檢查不能用.NET角色以聲明方式執(zhí)行AND檢查。將 Principalpermission命令堆疊在一起使用會產(chǎn)生邏輯OR。命令性檢查PrincipalPermission permCheckTellers = new PrincipalPermission(null,Teller);permChe

34、ckTellers.Demand();PrincipalPermission permCheckManagers = new PrincipalPermission(null, Manager);permCheckManagers.Demand();選擇身份驗證機制本節(jié)提供指導(dǎo)信息，旨在幫助您選擇適合常見應(yīng)用方案的身份驗證機制。您應(yīng)該從 考慮以下問題著手：身份。僅當(dāng)應(yīng)用程序用戶的Windows帳戶可由受信任的機構(gòu)進行身份驗證，并且應(yīng)用程序的 Web服務(wù)器可以訪問該機構(gòu)時，才適合使用 Windows身份 驗證機制。憑據(jù)管理。Windows身份驗證的一個主要優(yōu)點是它使您可以讓操作系統(tǒng)負(fù)責(zé) 憑據(jù)管理

35、。在非 Windows方法（如“表單”身份驗證）中，您必須仔細(xì)考慮 在何處以及如何存儲用戶憑據(jù)。兩種最常見的方法是使用： SQL Server 數(shù)據(jù)庫 Active Directory 中的用戶對象有關(guān)將SQL Server用作憑據(jù)存儲的安全注意事項的詳細(xì)信息，請參見第12章“數(shù)據(jù)訪問安全性”。有關(guān)對照自定義數(shù)據(jù)存儲（包括Active Directory ）使用“表單”身份驗證的詳細(xì)信息，請參見第 8章“ASP.NET安全性。 身份傳遞。您需要實現(xiàn)模擬/委派模式并在操作系統(tǒng)級的各層間傳遞原調(diào)用方 的安全上下文嗎？例如，支持審核或每用戶（粒度）授權(quán)。如果需要，您需 要能夠模擬調(diào)用方并將它們的安全

36、上下文委派給下一個下游子系統(tǒng)，詳見本 章前面的“委派” 一節(jié)。瀏覽器類型。您的用戶是否都有Internet Explorer ?或者您是否需要支持使用混合瀏覽器類型的用戶群？表 3.3闡釋了哪些身份驗證機制要求InternetExplorer瀏覽器，以及哪些支持各種常見的瀏覽器類型。表3.3:身份驗證瀏覽器要求身份驗證類型是否要求InternetExplorer備注表單否Passport否集成 Windows (Kerberos 或 NTLM )是Kerberos在客戶 機和服務(wù)器上還要求Windows 2000或更高版本的操作系統(tǒng)以及為 委派配置的帳戶。有關(guān)的詳細(xì)信息，請參見本 指南“參考”

37、部分的“如何做：對Windows 2000實現(xiàn)Kerberos 委派”?；痉瘛盎尽鄙矸蒡炞C是幾乎所有瀏覽器都支持的HTTP 1.1協(xié)議的一部分摘要式是證書否客戶端要求X.509證書Internet 方案Internet方案的基本假定條件是：用戶在服務(wù)器的域中或可由服務(wù)器訪問的受信任域中沒有Windows帳戶。用戶沒有客戶端證書。圖3.4顯示了一個為Internet方案選擇身份驗證機制的決策樹。Internet 方案/二二基本懾定條件：；開始/用戶沒有Windowsy循戶或證書.是否為交互冊望電卜應(yīng)用程序合尸使用 Passport身份驗證或表單身份險證非Web服務(wù)使用GXA VS安全身份物證

38、Insert figure: CH03 - Choosing an Internet Authentication Mechanism.gif 圖3.4為Internet應(yīng)用選擇身份驗證機制有關(guān)Web服務(wù)安全和 WS安全規(guī)范（全球 XML體系Z勾（GXA）倡議的一部 分）的詳細(xì)信息，請參見第10章Web服務(wù)安全性”。表單/Passport比較本節(jié)總結(jié)了表單和Passport身份驗證的相對優(yōu)點。表單身份驗證的優(yōu)點支持對照自定義數(shù)據(jù)存儲（通常為 SQL Server數(shù)據(jù)庫或 Active Directory ） 進行身份驗證。支持基于角色授權(quán)（包括從數(shù)據(jù)存儲中查找角色）。與 Web用戶界面平穩(wěn)集成。 ASP.NET提供結(jié)構(gòu)的大部分。與傳統(tǒng)的ASP相比，需要的自定義代碼相對較少。Passport 身份驗證的優(yōu)點 Passport是一個集中式解決方案。它消除了應(yīng)用程序中的憑據(jù)管理問題。它可以與基于角色授權(quán)方案一起使用。非常安全，因為它建立在加密技術(shù)之上。更多信息 有關(guān) Web服務(wù)身份驗證方法的詳細(xì)信息，請參見第10章“Web服務(wù)安全院有關(guān)在SQL Server中使用表單身份驗證的詳細(xì)信息，請參見本指南“參考” 部分的“如何做：將表單身份驗證用于SQL Server 2000”。Intranet / E