基于角色的訪問控制RBAC資料

1、今天在學(xué)習(xí)RBAC的時(shí)候在網(wǎng)上查了一些資料，本來想保存一個(gè)地址的，但是怕將來地址打不開，所以就復(fù)制過來吧，如有侵權(quán)之處，你來信告之，我會(huì)在第一時(shí)間刪除！RBAC初學(xué)筆記什么是RBAC？RBAC就是Role-Based Access Control，基于角色的訪問控制。角色訪問控制（RBAC）引入了Role的概念,目的是為了隔離User(即動(dòng)作主體，Subject)與Privilege(權(quán)限，表示對(duì)Resource的一個(gè)操作，即Operation+Resource) ，更符合企業(yè)的用戶、組織、數(shù)據(jù)和應(yīng)用特征。RBAC的關(guān)注點(diǎn)在于Role與user，Role與privilege的關(guān)系，也就是Use

2、r Assignment與Permission Assignment的關(guān)系。RBAC有以下優(yōu)點(diǎn)：1、 減少授權(quán)管理的復(fù)雜性，降低管理開銷2、 靈活的支持企業(yè)的安全策略，對(duì)企業(yè)的變化有很大的伸縮性 解決復(fù)雜的權(quán)限管理問題的過程可以抽象概括為：判斷【W(wǎng)ho是否可以對(duì)What進(jìn)行How的訪問操作（Operator）】這個(gè)邏輯表達(dá)式的值是否為True的求解過程。RBAC中的幾個(gè)重要概念：l         Who：權(quán)限的擁有者或主體。典型的有Principal、User、Group、Role、Actor等等。跟授

3、權(quán)有關(guān)系的實(shí)體就只有角色（Role）和用戶（User）。譬如：業(yè)務(wù)經(jīng)理（Role），張三（User）Role：作為一個(gè)用戶(User)與權(quán)限(Privilege)的代理層，解耦了權(quán)限和用戶的關(guān)系，所有的授權(quán)應(yīng)該給予Role而不是直接給User或Group?；诮巧脑L問控制方法的思想就是把對(duì)用戶的授權(quán)分成兩部份，用角色來充當(dāng)用戶行駛權(quán)限的中介。角色是一組訪問權(quán)限的集合，一個(gè)用戶可以是很多角色的成員，一個(gè)角色也可以有很多個(gè)權(quán)限，而一個(gè)權(quán)限也可以重復(fù)配置于多個(gè)角色。User：用戶就是一個(gè)可以獨(dú)立訪問計(jì)算機(jī)系統(tǒng)中的數(shù)據(jù)或者用數(shù)據(jù)表示的其它資源的主體，我們用USERS表示一個(gè)用戶集合。用戶在一般情況下

4、是指人。Group:是一組相關(guān)user的集合。User從group繼承出來，也就具有了該group的角色權(quán)限。個(gè)人覺得可以這么認(rèn)為，role是抽象化了的user或group。l         What：權(quán)限針對(duì)的資源（Resource）（包括資源類別（the type of Resource）和資源實(shí)例（the instance of Resource）。譬如：報(bào)表。粗粒度：表示類別級(jí)，即僅考慮對(duì)象的類別(the type of object)，不考慮對(duì)象的某個(gè)特定實(shí)例。比如，用戶管理中，創(chuàng)建、刪除，對(duì)所有的用戶

5、都一視同仁，并不區(qū)分操作的具體對(duì)象實(shí)例。細(xì)粒度：表示實(shí)例級(jí)，即需要考慮具體對(duì)象的實(shí)例(the instance of object)，當(dāng)然，細(xì)粒度是在考慮粗粒度的對(duì)象類別之后才再考慮特定實(shí)例。比如，合同管理中，列表、刪除，需要區(qū)分該合同實(shí)例是否為當(dāng)前用戶所創(chuàng)建。l         How：亦作action，表示某種訪問方法（亦請(qǐng)參考Operator條目解釋）。譬如：刪除。l Operator：操作。表示施加于What的How動(dòng)作。是一種Resource Related的概念，單獨(dú)的How動(dòng)作是沒有實(shí)際意義

6、的，譬如：刪除；只有與具體資源結(jié)合在一起才有意義，譬如：刪除報(bào)表。下面的圖展示了user,group,role,how的關(guān)系  權(quán)限系統(tǒng)的核心由以下三部分構(gòu)成：1.      創(chuàng)造權(quán)限2.       分配權(quán)限3.       使用權(quán)限 系統(tǒng)各部分的主要參與者對(duì)照如下：1.創(chuàng)造權(quán)限 - Programer創(chuàng)造，2.分配權(quán)限 - Administrator 分配，3.使用權(quán)限 User &

7、#160;1. Programer 向權(quán)限系統(tǒng)提供 Operator = Privilege + Resource 2. Administrator 利用 Operator 這個(gè)基本元素，來創(chuàng)造他理想中的權(quán)限模型。如，創(chuàng)建角色，創(chuàng)建用戶組，給用戶組分配用戶，將用戶組與角色關(guān)聯(lián)等等.這些操作都是由 Administrator 來完成的. 3. User 使用 Administrator 分配給的權(quán)限去使用各個(gè)系統(tǒng)。程序員只要回答一個(gè)問題，就是, 什么權(quán)限可以訪問什么資源，也就是前面說的 Operator。程序員提供 Operator 就意味著給系統(tǒng)穿上了盔甲。Administrator 就可以按

8、照他的意愿來建立他所希望的權(quán)限框架。Operator是這個(gè)系統(tǒng)中最關(guān)鍵的部分，它是一個(gè)紐帶，一個(gè)系在Programmer，Administrator，User之間的紐帶。（轉(zhuǎn)自：http:/www.1to2.us/RBAC-a156758.htm）RBAC 模型初探 訪問控制背景     訪問控制技術(shù)是由美國(guó)國(guó)防部（Department of Defense, DoD）資助的研究和開發(fā)成果演變而來的。這一研究導(dǎo)致兩種基本類型訪問控制的產(chǎn)生：自主訪問控制（Discretionary Access Control, DAC）和強(qiáng)制訪問控制（Mandatory Acce

9、ss Control, MAC）。最初的研究和應(yīng)用主要是為了防止機(jī)密信息被未經(jīng)授權(quán)者訪問，近期的應(yīng)用主要是把這些策略應(yīng)用到為商業(yè)領(lǐng)域。    自主訪問控制，允許把訪問控制權(quán)的授予和取消留給個(gè)體用戶來判斷。為沒有訪問控制權(quán)的個(gè)體用戶授予和廢除許可。自主訪問控制機(jī)制允許用戶被授權(quán)和取 消訪問其控制之下的任何客體（object），換句話說，用戶就是他們控制下的客體的擁有者。然而，對(duì)于多數(shù)組織來說，最終用戶對(duì)所訪問的信息沒有擁有 權(quán)。對(duì)于這些組織，公司或代理機(jī)構(gòu)是事實(shí)上的系統(tǒng)客體和處理他們的程序的擁有者。訪問優(yōu)先權(quán)受組織控制，而且也常?；诠蛦T功能而不是數(shù)據(jù)所有權(quán)。

10、60;  強(qiáng)制訪問控制，在美國(guó)國(guó)防部 Trusted Computer Security Evaluation Criteria (TCSEC) 中定義如下：“一種限制訪問客體的手段，它以包含在這些客體中的信息敏感性和訪問這些敏感性信息的主體的正式授權(quán)信息（如清除）為基礎(chǔ)”。      以上訪問控制策略對(duì)于處理一些無需保密但又敏感的信息的政府和行業(yè)組織的需求并不是特別的適合。在這樣的環(huán)境下，安全目標(biāo)支持產(chǎn)生于現(xiàn)有法律、道德規(guī)范、 規(guī)章、或一般慣例的高端組織策略。這些環(huán)境通常需要控制個(gè)體行為的能力，而不僅僅是如何根據(jù)信息的敏感性為其設(shè)置標(biāo)簽從而訪

11、問這一信息的個(gè)人能力。     什么是基于角色訪問控制（Role-Based Access Control, RBAC）？NIST 有如下定義。      訪問是一種利用計(jì)算機(jī)資源去做某件事情的的能力，訪問控制是一種手段，通過它這種能力在某些情況下被允許或者受限制（通常是通過物理上和基于系統(tǒng)的控 制）?；谟?jì)算機(jī)的訪問控制不僅可規(guī)定是“誰(shuí)”或某個(gè)操作有權(quán)使用特定系統(tǒng)資源，而且也能規(guī)定被允許的訪問類型。這些控制方式可在計(jì)算機(jī)系統(tǒng)或者外部設(shè)備 中實(shí)現(xiàn)。       就基

12、于角色訪問控制而言，訪問決策是基于角色的，個(gè)體用戶是某個(gè)組織的一部分。用戶具有指派的角色（比如醫(yī)生、護(hù)士、出納、經(jīng)理）。定義角色的過程應(yīng)該基于對(duì)組織運(yùn)轉(zhuǎn)的徹底分析，應(yīng)該包括來自一個(gè)組織中更廣范圍用戶的輸入。        訪問權(quán)按角色名分組，資源的使用受限于授權(quán)給假定關(guān)聯(lián)角色的個(gè)體。例如，在一個(gè)醫(yī)院系統(tǒng)中，醫(yī)生角色可能包括進(jìn)行診斷、開據(jù)處方、指示實(shí)驗(yàn)室化驗(yàn)等；而研究員的角色則被限制在收集用于研究的匿名臨床信息工作上。        控制訪問角色的運(yùn)用可能是一種開發(fā)和加強(qiáng)企業(yè)特

13、殊安全策略，進(jìn)行安全管理過程流程化的有效手段。      用戶（User）和角色（Role）     用戶指訪問系統(tǒng)中的資源的主體，一般為人，也可為 Agent 等智能程序。角色指應(yīng)用領(lǐng)域內(nèi)一種權(quán)力和責(zé)任的語(yǔ)義綜合體，可以是一個(gè)抽象概念，也可以是對(duì)應(yīng)于實(shí)際系統(tǒng)中的特定語(yǔ)義體，比如組織內(nèi)部的職務(wù)等。針對(duì)角色 屬性的不同，某些模型中將角色進(jìn)一步細(xì)分為普通角色和管理員角色（可理解為全局角色）。 許可（Permissions）和權(quán)限（Permission）     許可描述了角色對(duì)計(jì)

14、算機(jī)資源的訪問和操作所具有的權(quán)限，其反映的是授權(quán)的結(jié)果。比如授予某個(gè)角色對(duì)計(jì)算機(jī)資源有讀的權(quán)限，則代表了一個(gè)許可的存在，這個(gè)許 可表示：角色獲取了對(duì)計(jì)算機(jī)資源的讀許可。針對(duì)操作來說，其描述的是許可和操作之間的一種關(guān)聯(lián)關(guān)系，而這層關(guān)系則表示了某一角色對(duì)某一操作所具有的權(quán)限及 權(quán)限狀態(tài)。      角色和指派（Assignment）    指派包含兩個(gè)方面，用戶指派和許可指派。用戶指派表示的是，將用戶指派給特定的角色。許可指派表示的是為角色指派計(jì)算機(jī)資源的訪問和操作許可。 會(huì)話（session）  

15、   會(huì)話表示的是用戶和角色之間的關(guān)系。用戶每次必須通過建立會(huì)話來激活角色，得到相應(yīng)的訪問權(quán)限。 角色和角色等級(jí)（Role Hierarchies）     角色本身僅僅只是一個(gè)名詞，其本身并不能代表權(quán)限的大小。比如，我們可以定一個(gè)“Director”的角色，也可以定一個(gè)“Project Leader”的角色。對(duì)于現(xiàn)實(shí)中我們來說，看到這樣兩個(gè)角色，就清楚 DIR 的權(quán)限要比一個(gè) PL 的權(quán)限級(jí)別高。但是對(duì)計(jì)算機(jī)來說，這兩個(gè)角色僅僅是兩個(gè)“詞語(yǔ)”，是等同的?？梢圆捎梅值燃?jí)角色，在角色上實(shí)現(xiàn)層次化來解決這些問題。也可以采用復(fù)合角色 （其表

16、示的就是一個(gè)角色組的概念），對(duì)角色實(shí)現(xiàn)一定的分組和復(fù)合，以便于權(quán)限指派。在一些 OA 產(chǎn)品中經(jīng)常出現(xiàn)分等級(jí)角色。    限制（Constraints）         模型中的職責(zé)分離關(guān)系（Separation of Duty），用于控制沖突（Conflict）。靜態(tài)職責(zé)分離（Static SD）指定角色的互斥關(guān)系，用于用戶指派階段。避免同一用戶擁有互斥的角色。實(shí)現(xiàn)簡(jiǎn)單，角色互斥語(yǔ)義關(guān)系清楚，便于管理不夠靈活，不能處理某些實(shí)際情況。 動(dòng)態(tài)職責(zé)分離（Dynamic SD）指定角色的互斥關(guān)系，用于角色激活階段

17、。允許同一用戶擁有某些互斥的角色，但是不允許該用戶同時(shí)激活互斥的角色。更靈活，直接與會(huì)話掛鉤，適應(yīng)實(shí)際 管理需要，實(shí)現(xiàn)復(fù)雜，不易管理。               利用 AOP 實(shí)現(xiàn) .NET 上完整的基于角色的訪問控制（RBAC）模型 作者:admin 日期:2006-11-30一. 背景1. .NET 平臺(tái)上沒有完整的 RBAC 機(jī)制，.NET 中的安全模型（代碼訪問安全性：CAS）只是實(shí)現(xiàn)到

18、 Role 層次，沒有細(xì)化到 Task 層次，ASP.NET 2.0 中的諸多安全機(jī)制，如 Membership、Web.Config 的安全配置，都只能針對(duì) Role 進(jìn)行設(shè)置，大家在利用這些安全機(jī)制，往往需要在程序/代碼硬編碼（HardCode）角色，這樣就無法實(shí)現(xiàn)在運(yùn)行期自定義角色的功能 2. Windows 2000/2003 中自帶的 Authorization Manager 雖然實(shí)現(xiàn)了較為完整的RBAC模型，但一般只適用于 Windows 用戶，而且也需要手動(dòng)去進(jìn)行權(quán)限檢查（調(diào)用 AccessCheck方法） 3. 權(quán)限檢查是一個(gè)通用操作，最好的實(shí)現(xiàn)方式就是面向方面的編程（AOP

19、） 二、相關(guān)主題介紹1. RBAC模型的要素：三個(gè)實(shí)體：用戶、角色、任務(wù)（或操作）（User、Role、Task），其穩(wěn)定性逐漸增強(qiáng)，兩個(gè)關(guān)系，User<->Role、Role<->Task，其中： o User 是日常管理運(yùn)行時(shí)建立 o Role 是部署/交付建立 o Task 是開發(fā)時(shí)確定 o User<->Role 是日常管理運(yùn)行時(shí)建立 o Role<->Task 是部署/交付時(shí)建立 2. 一般來說，Task是固定的，是和應(yīng)用程序緊密綁定的，即使對(duì)之進(jìn)行硬編碼，也沒有關(guān)系 3. User/Role 部分比較容易實(shí)現(xiàn)，例如ASP.NET 2.

20、0中 Membership 的實(shí)現(xiàn) 三、具體實(shí)現(xiàn)注：本文中實(shí)現(xiàn) AOP 的思路主要來自于如下文章：Aspect oriented Programming using .NET - AOP in C# (http:/www.developerfusion.co.uk/show/5307/3/) ，這是我看到的、在.NET 上實(shí)現(xiàn) AOP最簡(jiǎn)捷/方便的方法，它不便提供了原理介紹，也提供了 Visual Studio 2005 的 Sample Project ，其中有 Security Check 和 Logging 的 AOP 功能。它的優(yōu)點(diǎn)在于，在實(shí)現(xiàn) AOP 的同時(shí)，不需要再去建立接口（這是

21、很多人的做法），直接在原有類上進(jìn)行少量改動(dòng)，即可實(shí)現(xiàn)完整的 AOP 功能。1. 定義描述“Task”（任務(wù)）的 Attributeusing System;namespace BusinessLogic.Security. /*/ / 用于定義系統(tǒng)中的操作 / AttributeUsage(AttributeTargets.All,AllowMultiple=false,Inherited=true) public sealed class Task : Attribute . private string _name,_description; public string Name . ge

22、t . return _name; set . _name = value; public string Description . get . return _description; set . _description = value; public Task(string name,string description) . _name = name; _description = description; public Task() . 2. 編寫權(quán)限檢查的 AOP 類 SecurityAspect，完成權(quán)限檢查的功能using System;using System.Diagnos

23、tics;using System.Reflection;using System.Runtime.Remoting.Messaging;using System.Runtime.Remoting.Contexts;using System.Runtime.Remoting.Activation;namespace BusinessLogic.Security. /消息接收器 internal class SecurityAspect : IMessageSink . /內(nèi)部變量 private IMessageSink m_next; /構(gòu)造方法 internal SecurityAspec

24、t(IMessageSink next) . m_next = next; IMessageSink 實(shí)現(xiàn)#region IMessageSink 實(shí)現(xiàn) public IMessageSink NextSink . get . return m_next; /同步處理消息 public IMessage SyncProcessMessage(IMessage msg) . Preprocess(msg); IMessage returnMethod = m_next.SyncProcessMessage(msg); return returnMethod; /異步處理消息（不實(shí)現(xiàn)） publi

25、c IMessageCtrl AsyncProcessMessage(IMessage msg, IMessageSink replySink) . throw new InvalidOperationException(); #endregion 自定義的 AOP 方法#region 自定義的 AOP 方法 private void Preprocess(IMessage msg) . /只處理方法調(diào)用 if (!(msg is IMethodMessage) return; /獲取方法中定義的 Task 屬性，交給權(quán)限檢查類去檢查 IMethodMessage call = msg as

26、IMethodMessage; MethodBase mb = call.MethodBase; object attrObj = mb.GetCustomAttributes(typeof(Task), false); if (attrObj != null) . Task attr = (Task)attrObj0; if(!string.IsNullOrEmpty(attr.Name) AzHelper.PermissionCheck(attr.Name); / Type type = Type.GetType(call.TypeName); #endregion public clas

27、s PermissionCheckProperty : IContextProperty, IContributeObjectSink . IContributeObjectSink 實(shí)現(xiàn)，將 AOP 類加入消息處理鏈#region IContributeObjectSink 實(shí)現(xiàn)，將 AOP 類加入消息處理鏈 public IMessageSink GetObjectSink(MarshalByRefObject o, IMessageSink next) . return new SecurityAspect(next); #endregion IContextProperty 實(shí)現(xiàn)#re

28、gion IContextProperty 實(shí)現(xiàn) public string Name . get . return "PermissionCheckProperty" public void Freeze(Context newContext) . public bool IsNewContextOK(Context newCtx) . return true; #endregion /特性定義，用于 Consumer AttributeUsage(AttributeTargets.Class) public class PermissionCheckAttribute

29、: ContextAttribute . public PermissionCheckAttribute() : base("PermissionCheck") . public override void GetPropertiesForNewContext(IConstructionCallMessage ccm) . ccm.ContextProperties.Add(new PermissionCheckProperty(); ?3. 定義用于權(quán)限檢查的兩個(gè)類：AzMan、AzHelper這兩個(gè)類的功能是從 XML 配置文件中讀入 Role 和 Task 的映射關(guān)系

30、，以確定 Role 中是否包含 Task 的引用，從而確定當(dāng)前 Role 是否具有對(duì)此 Task 的權(quán)限。注：這里可根據(jù)項(xiàng)目的實(shí)際情況，如果你的 Role 和 Task 的映射關(guān)系是存放在 Windows 的授權(quán)管理器（Authorizatiom Manager）或數(shù)據(jù)庫(kù)中，你可以使用自已的方法來替換下列類。在本例中，我的 Role 和 Task 的關(guān)系是存放在 XML 文件中，XML文件的格式如下所示：<?xml version="1.0" encoding="utf-8"?><ACL> <Tasks> <Ta

31、sk Name="AddItem" Description="增加" /> <Task Name="ModifyItem" Description="修改" /> <Task Name="RemoveItem" Description="刪除" /> <Task Name="ListItem" Description="獲取列表" /> </Tasks> <Roles>

32、<Role Name="Manager"> <Task Name="AddItem" /> <Task Name="ModifyItem" /> <Task Name="RemoveItem" /> <Task Name="ListItem" /> </Role> </Roles></ACL>AzMan.cs 完成角色/任務(wù)映射關(guān)系的檢查using System;using System.Collec

33、tions.Generic;using System.Text;using System.Xml;namespace BusinessLogic.Security. public class AzMan . public static bool AccessCheck(string taskName, string roles, XmlDocument aclDoc) . XmlNode rootNode = aclDoc.DocumentElement; XmlNodeList roleNodes,taskNodes; bool IsPermissiable = false; for (in

34、t i = 0; i < roles.Length; i+) . roleNodes = rootNode.SelectNodes("Roles/RoleName='" + rolesi + "'"); if (roleNodes != null) . taskNodes = roleNodes.Item(0).SelectNodes("TaskName='" + taskName + "'"); if (taskNodes.Count != 0) . IsPermissiab

35、le = true; break; return IsPermissiable; AzHelper.cs 助手類，協(xié)助其他類，更好地調(diào)用 AzMan 類的方法，以及基于性能考慮，對(duì)Role<->Task的XML配置文件進(jìn)行緩存：using System;using System.Collections.Generic;using System.Text;using System.Xml;using System.Web;using System.Web.Security;using System.Diagnostics;using System.Reflection;using S

36、ystem.Web.Caching;namespace BusinessLogic.Security. public class AzHelper . /*/ / 檢查當(dāng)前用戶是否具有執(zhí)行當(dāng)前任務(wù)的權(quán)限，如果有權(quán)限，則不做任何處理 / 如果不具有權(quán)限，則引發(fā)異常 / public static void PermissionCheck(string taskName) . if (HttpContext.Current != null) . XmlDocument aclDoc = (XmlDocument)HttpContext.Current.Cache"ACLDoc"

37、 if (aclDoc = null) . CacheXml(); aclDoc = (XmlDocument)HttpContext.Current.Cache"ACLDoc" string roles = Roles.GetRolesForUser(); if (!AzMan.AccessCheck(taskName, roles, aclDoc) throw new UnauthorizedAccessException("訪問被拒絕，當(dāng)前用戶不具有操作此功能的權(quán)限！"); /*/ / 檢查當(dāng)前用戶是否具有執(zhí)行指定任務(wù)的權(quán)限 / / 任務(wù)名稱 /

38、True/False 是否允許執(zhí)行 public static bool IsPermissible(string taskName) . if (HttpContext.Current != null) . XmlDocument aclDoc = (XmlDocument)HttpContext.Current.Cache"ACLDoc" if (aclDoc = null) . CacheXml(); aclDoc = (XmlDocument)HttpContext.Current.Cache"ACLDoc" string roles = Rol

39、es.GetRolesForUser(); aclDoc.Load(HttpContext.Current.Server.MapPath("/App_Data/ACL.xml"); return AzMan.AccessCheck(taskName, roles, aclDoc); else return true; /*/ / 緩存 XML 文件 / private static void CacheXml() . string fileName = HttpContext.Current.Server.MapPath("/App_Data/ACL.xml&qu

40、ot;); XmlDocument aclDoc = new XmlDocument(); aclDoc.Load(fileName); HttpContext.Current.Cache.Insert("ACLDoc", aclDoc, new CacheDependency(fileName); 4. 業(yè)務(wù)邏輯類的實(shí)現(xiàn)由于大多數(shù)工作都在 AOP 中實(shí)現(xiàn)了，所以業(yè)務(wù)邏輯類的實(shí)現(xiàn)較為簡(jiǎn)單，主要分為以下幾個(gè)步驟： · 在類的層次定義要求 AOP 方式權(quán)限檢查的 Attribute: PermissionCheck() · · 使類繼承自 Cont

41、extBoundObject 對(duì)象 · · 在方法層次上利用 Task Attribute 來定義其對(duì)應(yīng)的操作（注：多個(gè)方法可以定義為同一個(gè) Task）· 例如：ItemManager.csnamespace BusinessLogic. PermissionCheck() public class ItemManager : ContextBoundObject . Task("AddItem","增加") public void AddItem(Item item) . /. 這樣就可以了，CLR 會(huì)在運(yùn)行時(shí)檢查類的 P

42、ermissionCheck?Attribute，然后尋找方法上的 Task ，取出當(dāng)前用戶對(duì)應(yīng)的 Role ，再去進(jìn)行匹配檢查，如果不能執(zhí)行此操作，會(huì)拋出 UnauthorizedAccessException 的異常，在外部進(jìn)行處理即可（如在 ASP.NET 中增加 ErrorPage 等）5. 其他相關(guān)功能的實(shí)現(xiàn)Q：如果我寫程序時(shí)，在各個(gè)業(yè)務(wù)邏輯類定義了大量的 Task ，如果統(tǒng)一提取出來？A：利用反射可取出程序集中定義的所有 Task ，代碼如下：List<string> dic = new List<string>();StringBuilder sXml =

43、 new StringBuilder("");string curDir = this.GetCurrentPath();Assembly ass = Assembly.LoadFile(curDir + "AppFramework.BusinessLogic.dll"); foreach (Type t in ass.GetTypes() . MethodInfo mis = t.GetMethods(); foreach (MethodInfo mi in mis) . object attrs = mi.GetCustomAttributes(fa

44、lse); if (attrs.Length > 0) . foreach (object attr in attrs) . if (attr.GetType().ToString().IndexOf("Task") >= 0) . Task ta = (Task)attr; /檢查重復(fù)的 Task if (dic.IndexOf(ta.Name) < 0) . dic.Add(ta.Name); sXml.Append(string.Format("rn ", ta.Name, ta.Description); /這就是所有的 Tas

45、k 定義 sXml.Append("rn");此段代碼是將 Task 定義保存到 XML 文件中，如果你想保存到 SQL Server/Authorzatiom Manager 中，對(duì)代碼稍加修改即可。Q：程序中的 Role 如何實(shí)現(xiàn)？A：如果是 ASP.NET 應(yīng)用程序，可以直接利用其中的 MemberShip Role 機(jī)制，還是比較簡(jiǎn)單的Q：如果我想在界面上預(yù)先實(shí)現(xiàn)一些控制，如某用戶不能進(jìn)行某項(xiàng)操作，則直接將其對(duì)應(yīng)的 Button 禁止或隱藏（Disable/Invisible）掉，如何做？A：這可以利用 ASP.NET 2.0 中的表達(dá)式功能，直接檢查當(dāng)前用戶的角色

46、是否可以執(zhí)行 Task ，如果不行，則利用返回的 Bool 值直接設(shè)置 Button 等控件的屬性，做法如下：1）在 App_Code 下定義表達(dá)式類 PermissionCheckExpressionBuilder.csExpressionEditor(typeof(PermissionCheckExpressionBuilderEditor)ExpressionPrefix("PermissionCheck")public class PermissionCheckExpressionBuilder : ExpressionBuilder. public overrid

47、e CodeExpression GetCodeExpression(BoundPropertyEntry entry, object parsedData, ExpressionBuilderContext context) . string taskName = entry.Expression; return new CodePrimitiveExpression(AzHelper.IsPermissible(taskName); public class PermissionCheckExpressionBuilderEditor : System.Web.UI.Design.Expr

48、essionEditor. public override object EvaluateExpression(string expression, object parseTimeData, Type propertyType, IServiceProvider serviceProvider) . /return expression + ":" + parseTimeData + ":" + propertyType + ":" + serviceProvider; string taskName = expression; r

49、eturn AzHelper.IsPermissible(taskName); 2）在 Web.Config 中加入上述表達(dá)式定義，以便可以直接在頁(yè)面上引用<configuration xmlns=" <expressionBuilders> <add expressionPrefix="PermissionCheck" type="PermissionCheckExpressionBuilder"/> expressionBuilders>configuration>3）直接在頁(yè)面控件的相應(yīng)屬性上綁定

50、表達(dá)式，如： · 如果能執(zhí)行此操作則顯示，否則則隱藏· <asp:Button ID="Button1" runat="server" Text="AddItem" Visible="" /> · 如果能執(zhí)行此操作則啟用，否則則禁止· <asp:Button ID="Button2" runat="server" Text="AddItem" Enabled="" /> 4

51、）如果想在代碼中自行檢查權(quán)限，可以直接調(diào)用相應(yīng)方法，如：protected void Button1_Click(object sender, EventArgs e). AzHelper.PermissionCheck("AddItem"); /.其他操作5）如何建立 User<->Role 的映射，Role<->Task的映射前者較為簡(jiǎn)單，ASP.NET 2.0 中就已經(jīng)具有此功能，當(dāng)然你也可以利用其 API 來實(shí)現(xiàn)自己的定義界面。對(duì)于 Role-Task 的映射來說，首先利用上面的代碼從程序集中取出所有 Task ，保存在 XML 文件中，然后

52、在進(jìn)行配置時(shí)，可以顯示 Role 和 Task ，來進(jìn)行映射。如下圖所示：角色與任務(wù)的映射 用戶與角色的映射用戶權(quán)限設(shè)計(jì)(一)ASP.NET系統(tǒng)用戶權(quán)限設(shè)計(jì)與實(shí)現(xiàn)引言    電子商務(wù)系統(tǒng)對(duì)安全問題有較高的要求，傳統(tǒng)的訪問控制方法DAC（Discretionary Access Control，自主訪問控制模型）、MAC（Mandatory Access Control，強(qiáng)制訪問控制模型）難以滿足復(fù)雜的企業(yè)環(huán)境需求。因此，NIST（National Institute of Standards and Technology，美國(guó)國(guó)家標(biāo)準(zhǔn)化和技術(shù)委員會(huì)）于90年代初提

53、出了基于角色的訪問控制方法，實(shí)現(xiàn)了用戶與訪問權(quán)限的邏輯分離，更符合企業(yè)的用戶、組 織、數(shù)據(jù)和應(yīng)用特征。ASP.NET是微軟為了抗衡JSP而推出的新一代ASP（Active Server Pages）腳本語(yǔ)言，它借鑒了JSP的優(yōu)點(diǎn)，同時(shí)它又具有自身的一些新特點(diǎn)。    本文將首先介紹ASP.NET的基本情況和RBAC（Role Based Access Control）的基本思想，在此基礎(chǔ)上，給出電子商務(wù)系統(tǒng)中實(shí)現(xiàn)用戶權(quán)限控制的一種具體方法。    ASP.NET概述    1、ASP.NET    ASP.NET是微軟流行的動(dòng)態(tài)WEB編程技術(shù)活動(dòng)服務(wù)器網(wǎng)頁(yè)（ASP）的最新版本，但它遠(yuǎn)不是傳統(tǒng)ASP簡(jiǎn)單升級(jí)。ASP.NET和ASP的最大區(qū)別在 于編程思維的轉(zhuǎn)換，ASP.NET是真正的面向?qū)ο螅∣bject-oriented），而不僅僅在于功能的增強(qiáng)。    在ASP.NET中，Web 窗體頁(yè)由兩部分組成：視覺元素（HTML、服務(wù)器控件和靜態(tài)文本）和該頁(yè)的編程邏輯。其中每一部分都存儲(chǔ)在一個(gè)單獨(dú)的文件中?？梢曉卦谝粋€(gè)擴(kuò)展名為 .aspx 文件中創(chuàng)建