基于角色的访问控制RBAC资料.doc

1、今天在学习 RBAC 的时候在网上查了一些资料，本来想保存一个地址的，但是怕将来地址打不开，所以就复制过来吧，如有侵权之处，你来信告之，我会在第一时间删除！RBAC 初学笔记什么是 RBAC？RBAC 就是 Role-Based Access Control，基于角色的访问控制。角色访问控制（RBAC）引入了 Role 的概念 ,目的是为了隔离 User(即动作主体，Subject)与Privilege(权限，表示对 Resource 的一个操作，即 Operation+Resource) ，更符合企业的用户、组织、数据和应用特征。RBAC 的关注点在于 Role 与 user，Role 与

2、privilege 的关系，也就是 User Assignment 与 Permission Assignment 的关系。RBAC 有以下优点：1、 减少授权管理的复杂性，降低管理开销2、 灵活的支持企业的安全策略，对企业的变化有很大的伸缩性解决复杂的权限管理问题的过程可以抽象概括为：判断【Who 是否可以对What 进行 How 的访问操作（Operator）】这个逻辑表达式的值是否为 True 的求解过程。RBAC 中的几个重要概念：l Who：权限的拥有者或主体。典型的有Principal、User、Group、Role、Actor 等等。跟授权有关系的实体就只有角色（Role）和用户

3、（User）。譬如：业务经理（Role），张三（User）Role：作为一个用户 (User)与权限(Privilege) 的代理层，解耦了权限和用户的关系，所有的授权应该给予 Role 而不是直接给 User 或 Group。基于角色的访问控制方法的思想就是把对用户的授权分成两部份，用角色来充当用户行驶权限的中介。角色是一组访问权限的集合，一个用户可以是很多角色的成员，一个角色也可以有很多个权限，而一个权限也可以重复配置于多个角色。User：用户就是一个可以独立访问计算机系统中的数据或者用数据表示的其它资源的主体，我们用 USERS 表示一个用户集合。用户在一般情况下是指人。Group:是一

4、组相关 user 的集合。User 从 group 继承出来，也就具有了该 group的角色权限。个人觉得可以这么认为，role 是抽象化了的 user 或 group。l What：权限针对的资源（Resource）（包括资源类别（the type of Resource）和资源实例（the instance of Resource）。譬如：报表。粗粒度：表示类别级，即仅考虑对象的类别(the type of object)，不考虑对象的某个特定实例。比如，用户管理中，创建、删除，对所有的用户都一视同仁，并不区分操作的具体对象实例。细粒度：表示实例级，即需要考虑具体对象的实例(the ins

5、tance of object)，当然，细粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。比如，合同管理中，列表、删除，需要区分该合同实例是否为当前用户所创建。l How：亦作 action，表示某种访问方法（亦请参考 Operator 条目解释）。譬如：删除。l Operator：操作。表示施加于 What 的 How 动作。是一种 Resource Related的概念，单独的 How 动作是没有实际意义的，譬如：删除；只有与具体资源结合在一起才有意义，譬如：删除报表。下面的图展示了 user,group,role,how 的关系权限系统的核心由以下三部分构成：1. 创造权限2. 分配权

6、限3. 使用权限系统各部分的主要参与者对照如下：1.创造权限 - Programer 创造，2.分配权限 - Administrator 分配，3.使用权限 User1. Programer 向权限系统提供 Operator = Privilege + Resource 2. Administrator 利用 Operator 这个基本元素，来创造他理想中的权限模型。如，创建角色，创建用户组，给用户组分配用户，将用户组与角色关联等等.这些操作都是由 Administrator 来完成的. 3. User 使用 Administrator 分配给的权限去使用各个系统。程序员只要回答一个问题，就是

7、, 什么权限可以访问什么资源，也就是前面说的 Operator。程序员提供 Operator 就意味着给系统穿上了盔甲。Administrator 就可以按照他的意愿来建立他所希望的权限框架。Operator 是这个系统中最关键的部分，它是一个纽带，一个系在Programmer，Administrator，User 之间的纽带。（转自：http:/www.1to2.us/RBAC-a156758.htm）RBAC 模型初探 访问控制背景 访问控制技术是由美国国防部（Department of Defense, DoD）资助的研究和开发成果演变而来的。这一研究导致两种基本类型访问控制的产生：自主

8、访问控制（Discretionary Access Control, DAC）和强制访问控制（Mandatory Access Control, MAC）。最初的研究和应用主要是为了防止机密信息被未经授权者访问，近期的应用主要是把这些策略应用到为商业领域。自主访问控制，允许把访问控制权的授予和取消留给个体用户来判断。为没有访问控制权的个体用户授予和废除许可。自主访问控制机制允许用户被授权和取 消访问其控制之下的任何客体（object），换句话说，用户就是他们控制下的客体的拥有者。然而，对于多数组织来说，最终用户对所访问的信息没有拥有 权。对于这些组织，公司或代理机构是事实上的系统客体和处理他们

9、的程序的拥有者。访问优先权受组织控制，而且也常常基于雇员功能而不是数据所有权。强制访问控制，在美国国防部 Trusted Computer Security Evaluation Criteria (TCSEC) 中定义如下：“一种限制访问客体的手段，它以包含在这些客体中的信息敏感性和访问这些敏感性信息的主体的正式授权信息（如清除）为基础”。以上访问控制策略对于处理一些无需保密但又敏感的信息的政府和行业组织的需求并不是特别的适合。在这样的环境下，安全目标支持产生于现有法律、道德规范、 规章、或一般惯例的高端组织策略。这些环境通常需要控制个体行为的能力，而不仅仅是如何根据信息的敏感性为其设置标签

10、从而访问这一信息的个人能力。什么是基于角色访问控制（Role-Based Access Control, RBAC）？NIST 有如下定义。访问是一种利用计算机资源去做某件事情的的能力，访问控制是一种手段，通过它这种能力在某些情况下被允许或者受限制（通常是通过物理上和基于系统的控 制）。基于计算机的访问控制不仅可规定是“谁”或某个操作有权使用特定系统资源，而且也能规定被允许的访问类型。这些控制方式可在计算机系统或者外部设备 中实现。就基于角色访问控制而言，访问决策是基于角色的，个体用户是某个组织的一部分。用户具有指派的角色（比如医生、护士、出纳、经理）。定义角色的过程应该基于对组织运转的彻底分

11、析，应该包括来自一个组织中更广范围用户的输入。访问权按角色名分组，资源的使用受限于授权给假定关联角色的个体。例如，在一个医院系统中，医生角色可能包括进行诊断、开据处方、指示实验室化验等；而研究员的角色则被限制在收集用于研究的匿名临床信息工作上。控制访问角色的运用可能是一种开发和加强企业特殊安全策略，进行安全管理过程流程化的有效手段。用户（User）和角色（Role） 用户指访问系统中的资源的主体，一般为人，也可为 Agent 等智能程序。角色指应用领域内一种权力和责任的语义综合体，可以是一个抽象概念，也可以是对应于实际系统中的特定语义体，比如组织内部的职务等。针对角色 属性的不同，某些模型中将

12、角色进一步细分为普通角色和管理员角色（可理解为全局角色）。许可（Permissions）和权限（Permission） 许可描述了角色对计算机资源的访问和操作所具有的权限，其反映的是授权的结果。比如授予某个角色对计算机资源有读的权限，则代表了一个许可的存在，这个许 可表示：角色获取了对计算机资源的读许可。针对操作来说，其描述的是许可和操作之间的一种关联关系，而这层关系则表示了某一角色对某一操作所具有的权限及 权限状态。角色和指派（Assignment）指派包含两个方面，用户指派和许可指派。用户指派表示的是，将用户指派给特定的角色。许可指派表示的是为角色指派计算机资源的访问和操作许可。会话（se

13、ssion） 会话表示的是用户和角色之间的关系。用户每次必须通过建立会话来激活角色，得到相应的访问权限。角色和角色等级（Role Hierarchies） 角色本身仅仅只是一个名词，其本身并不能代表权限的大小。比如，我们可以定一个“Director”的角色，也可以定一个“Project Leader”的角色。对于现实中我们来说，看到这样两个角色，就清楚 DIR 的权限要比一个 PL 的权限级别高。但是对计算机来说，这两个角色仅仅是两个“词语”，是等同的。可以采用分等级角色，在角色上实现层次化来解决这些问题。也可以采用复合角色 （其表示的就是一个角色组的概念），对角色实现一定的分组和复合，以便于

14、权限指派。在一些 OA 产品中经常出现分等级角色。限制（Constraints） 模型中的职责分离关系（Separation of Duty），用于控制冲突（Conflict）。静态职责分离（Static SD）指定角色的互斥关系，用于用户指派阶段。避免同一用户拥有互斥的角色。实现简单，角色互斥语义关系清楚，便于管理不够灵活，不能处理某些实际情况。 动态职责分离（Dynamic SD）指定角色的互斥关系，用于角色激活阶段。允许同一用户拥有某些互斥的角色，但是不允许该用户同时激活互斥的角色。更灵活，直接与会话挂钩，适应实际 管理需要，实现复杂，不易管理。利用 AOP 实现 .NET 上完整的基于

15、角色的访问控制（RBAC）模型 作者:admin 日期:2006-11-30一. 背景1. .NET 平台上没有完整的 RBAC 机制，.NET 中的安全模型（代码访问安全性：CAS）只是实现到 Role 层次，没有细化到 Task 层次，ASP.NET 2.0 中的诸多安全机制，如 Membership、Web.Config 的安全配置，都只能针对 Role 进行设置，大家在利用这些安全机制，往往需要在程序/代码硬编码（HardCode ）角色，这样就无法实现在运行期自定义角色的功能 2. Windows 2000/2003 中自带的 Authorization Manager 虽然实现了较

16、为完整的RBAC 模型，但一般只适用于 Windows 用户，而且也需要手动去进行权限检查（调用 AccessCheck 方法） 3. 权限检查是一个通用操作，最好的实现方式就是面向方面的编程（AOP） 二、相关主题介绍1. RBAC 模型的要素：三个实体：用户、角色、任务（或操作） （User 、Role、Task） ，其稳定性逐渐增强，两个关系，UserRole 、RoleTask，其中： o User 是日常管理运行时建立 o Role 是部署/交付建立 o Task 是开发时确定 o UserRole 是日常管理运行时建立 o RoleTask 是部署/交付时建立 2. 一般来说，Ta

17、sk 是固定的，是和应用程序紧密绑定的，即使对之进行硬编码，也没有关系 3. User/Role 部分比较容易实现，例如 ASP.NET 2.0 中 Membership 的实现 三、具体实现注：本文中实现 AOP 的思路主要来自于如下文章：Aspect oriented Programming using .NET - AOP in C# (http:/www.developerfusion.co.uk/show/5307/3/) ，这是我看到的、在.NET 上实现 AOP 最简捷/方便的方法，它不便提供了原理介绍，也提供了 Visual Studio 2005 的 Sample Proje

18、ct ，其中有 Security Check 和 Logging 的 AOP 功能。它的优点在于，在实现 AOP 的同时，不需要再去建立接口（这是很多人的做法），直接在原有类上进行少量改动，即可实现完整的 AOP 功能。1. 定义描述“Task”（任务）的 Attributeusing System;namespace BusinessLogic.Security/ / 用于定义系统中的操作/ AttributeUsage(AttributeTargets.All,AllowMultiple=false,Inherited=true)public sealed class Task : Att

19、ributeprivate string _name,_description;public string Nameget return _name; set _name = value; public string Descriptionget return _description; set _description = value; public Task(string name,string description)_name = name;_description = description;public Task()2. 编写权限检查的 AOP 类 SecurityAspect，完

20、成权限检查的功能using System;using System.Diagnostics;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/内部变量private IMessageSink m_

21、next;/构造方法internal SecurityAspect(IMessageSink next)m_next = next;IMessageSink 实现自定义的 AOP 方法public class PermissionCheckProperty : IContextProperty, IContributeObjectSinkIContributeObjectSink 实现，将 AOP 类加入消息处理链IContextProperty 实现/特性定义，用于 ConsumerAttributeUsage(AttributeTargets.Class)public class Perm

22、issionCheckAttribute : ContextAttributepublic PermissionCheckAttribute() : base(“PermissionCheck“) public override void GetPropertiesForNewContext(IConstructionCallMessage ccm)ccm.ContextProperties.Add(new PermissionCheckProperty();?3. 定义用于权限检查的两个类：AzMan、AzHelper这两个类的功能是从 XML 配置文件中读入 Role 和 Task 的映射

23、关系，以确定 Role 中是否包含 Task 的引用，从而确定当前 Role 是否具有对此 Task 的权限。注：这里可根据项目的实际情况，如果你的 Role 和 Task 的映射关系是存放在 Windows 的授权管理器（Authorizatiom Manager）或数据库中，你可以使用自已的方法来替换下列类。在本例中，我的 Role 和 Task 的关系是存放在 XML 文件中，XML 文件的格式如下所示：AzMan.cs 完成角色/任务映射关系的检查using System;using System.Collections.Generic;using System.Text;using

24、System.Xml;namespace BusinessLogic.Securitypublic class AzManpublic static bool AccessCheck(string taskName, string roles, XmlDocument aclDoc)XmlNode rootNode = aclDoc.DocumentElement;XmlNodeList roleNodes,taskNodes;bool IsPermissiable = false;for (int i = 0; i Task 的 XML 配置文件进行缓存：using System;using

25、 System.Collections.Generic;using System.Text;using System.Xml;using System.Web;using System.Web.Security;using System.Diagnostics;using System.Reflection;using System.Web.Caching;namespace BusinessLogic.Securitypublic class AzHelper/ / 检查当前用户是否具有执行当前任务的权限，如果有权限，则不做任何处理/ 如果不具有权限，则引发异常/ public static

26、 void PermissionCheck(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 = Roles.GetRolesForUser();if (!AzMan.AccessCheck(taskName, roles

27、, aclDoc)throw new UnauthorizedAccessException(“访问被拒绝，当前用户不具有操作此功能的权限！“);/ / 检查当前用户是否具有执行指定任务的权限/ / 任务名称/ True/False 是否允许执行public static bool IsPermissible(string taskName)if (HttpContext.Current != null)XmlDocument aclDoc = (XmlDocument)HttpContext.Current.Cache“ACLDoc“;if (aclDoc = null)CacheXml()

28、;aclDoc = (XmlDocument)HttpContext.Current.Cache“ACLDoc“;string roles = Roles.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 = HttpCo

29、ntext.Current.Server.MapPath(“/App_Data/ACL.xml“);XmlDocument aclDoc = new XmlDocument();aclDoc.Load(fileName);HttpContext.Current.Cache.Insert(“ACLDoc“, aclDoc, new CacheDependency(fileName);4. 业务逻辑类的实现由于大多数工作都在 AOP 中实现了，所以业务逻辑类的实现较为简单，主要分为以下几个步骤： 在类的层次定义要求 AOP 方式权限检查的 Attribute: PermissionCheck()

30、使类继承自 ContextBoundObject 对象 在方法层次上利用 Task Attribute 来定义其对应的操作（注：多个方法可以定义为同一个 Task） 例如：ItemManager.csnamespace BusinessLogicPermissionCheck()public class ItemManager : ContextBoundObjectTask(“AddItem“,“增加“)public void AddItem(Item item)/.这样就可以了，CLR 会在运行时检查类的 PermissionCheck?Attribute，然后寻找方法上的 Task ，取

31、出当前用户对应的 Role ，再去进行匹配检查，如果不能执行此操作，会抛出 UnauthorizedAccessException 的异常，在外部进行处理即可（如在 ASP.NET 中增加 ErrorPage 等）5. 其他相关功能的实现Q：如果我写程序时，在各个业务逻辑类定义了大量的 Task ，如果统一提取出来？A：利用反射可取出程序集中定义的所有 Task ，代码如下：List dic = new List();StringBuilder sXml = new StringBuilder(“);string curDir = this.GetCurrentPath();Assembly

32、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(false);if (attrs.Length 0)foreach (object attr in attrs)if (attr.GetType().ToString().IndexOf(“Task“

33、) = 0)Task ta = (Task)attr;/检查重复的 Taskif (dic.IndexOf(ta.Name) expressionBuildersconfiguration3）直接在页面控件的相应属性上绑定表达式，如： 如果能执行此操作则显示，否则则隐藏 如果能执行此操作则启用，否则则禁止 4）如果想在代码中自行检查权限，可以直接调用相应方法，如：protected void Button1_Click(object sender, EventArgs e)AzHelper.PermissionCheck(“AddItem“);/其他操作5）如何建立 UserRole 的映射，

34、RoleTask 的映射前者较为简单，ASP.NET 2.0 中就已经具有此功能，当然你也可以利用其 API 来实现自己的定义界面。对于 Role-Task 的映射来说，首先利用上面的代码从程序集中取出所有 Task ，保存在 XML 文件中，然后在进行配置时，可以显示 Role 和 Task ，来进行映射。如下图所示：角色与任务的映射用户与角色的映射用户权限设计(一) ASP.NET 系统用户权限设计与实现引言电子商务系统对安全问题有较高的要求，传统的访问控制方法DAC（Discretionary Access Control，自主访问控制模型）、MAC（Mandatory Access C

35、ontrol，强制访问控制模型）难以满足复杂的企业环境需求。因此，NIST（National Institute of Standards and Technology，美国国家标准化和技术委员会）于 90 年代初提出了基于角色的访问控制方法，实现了用户与访问权限的逻辑分离，更符合企业的用户、组 织、数据和应用特征。ASP.NET 是微软为了抗衡 JSP 而推出的新一代 ASP（Active Server Pages）脚本语言，它借鉴了 JSP 的优点，同时它又具有自身的一些新特点。本文将首先介绍 ASP.NET 的基本情况和 RBAC（Role Based Access Control）的基

36、本思想，在此基础上，给出电子商务系统中实现用户权限控制的一种具体方法。ASP.NET 概述1、ASP.NETASP.NET 是微软流行的动态 WEB 编程技术活动服务器网页（ASP）的最新版本，但它远不是传统 ASP 简单升级。ASP.NET 和 ASP 的最大区别在 于编程思维的转换，ASP.NET 是真正的面向对象（Object-oriented），而不仅仅在于功能的增强。在 ASP.NET 中，Web 窗体页由两部分组成：视觉元素（HTML、服务器控件和静态文本）和该页的编程逻辑。其中每一部分都存储在一个单独的文件中。可视元素在一个扩展名为 .aspx 文件中创建，而代码位于一个单独的类

37、文件中，该文件称作代码隐藏类文件扩展名为.aspx.vb 或 .aspx.cs。这样，.aspx 文件中存放所有要显示的元素，aspx.vb 或.aspx.cs 文件中存放逻辑。2、用户控件（UserControl）为了使用户能够根据需要方便地定义控件，ASP.NET 引入了 Web 窗体用户控件的概念。实际上，只要将.aspx 稍作修改即可转换为 Web 用户控件，扩展名为 .ascx，.ascx 和.aspx 文件一样也有一个存放逻辑的代码隐藏类文件，扩展名为.ascx.vb 或.ascx.cs，只是它不能作为独立 Web 窗体页来运行，只有当被包含在 .aspx 文件中时，用户控件才能工

38、作。通过以下两个步骤在 WEB 窗体页中设置用户控件：（1）使用 Register 指令在.aspx 文件中注册用户控件。如要注册在放在相对路径“/UserControl/”下的头文件 headinner.ascx 的方法为：% Register TagPrefix=“Acme“ TagName=“Head“ Src=“/UserControl/headinner.ascx“ %（2）在服务器控件的开始标记和结束标记之间(form runat=server /form) 声明该用户控件元素。例如要声明上面所导入的控件的语法为：Acme: Head runat=“server“/这样，该控件就成

39、为页的一部分，并将在处理该页时呈现出来。并且，该控件的公共属性、事件和方法将向 Web 窗体页公开并且可以通过编程来使用。根据这个原理，就可以将每个页面初始化时所要执行的操作（如登录验证，角色验证）封装在用户控件当中。RBAC 的基本思想RBAC（角色访问控制）的基本思想可简单地用图 1 来表示，即把整个访问控制过程分成两步：访问权限与角色相关联，角色再与用户关联，从而实现了用户与访问权限的逻辑分离。由于 RBAC 实现了用户与访问权限的逻辑分离，因此它极大的方便了权限管理。例如，如果一个用户的职位发生变化，只要将用户当前的角色去掉，加入代表新职 务或新任务的角色即可，角色/权限之间的变化比角

40、色/用户关系之间的变化相对要慢得多，并且委派用户到角色不需要很多技术，可以由行政管理人员来执行，而 配置权限到角色的工作比较复杂，需要一定的技术，可以由专门的技术人员来承担，但是不给他们委派用户的权限，这与现实中情况正好一致。用户权限在.NET 中的设计与实现利用.NET 中的用户控件实现权限控制的基本思想是：根据角色访问控制（RBAC）的基本原理，给用户分配一个角色，每个角色对应一些权限，然后利用 ASP.NET 中的用户控件（UserControl）来判断该用户对应的角色是否对访问页面有访问的权力。下面将从数据库设计、添加角色和用户控件的使用等三方面来阐述具体实现过程。1、数据库中表的设计

41、首先，在数据库中设计功能模块表、功能表和角色表等三个表。（1） 功能模块表 为了管理好用户的权限，首先要组织好系统的模块，为此设计了一个功能模块表。见表 1。（2） 功能表每个功能模块所具有的子功能称为功能，如商品管理模块 goods（属于功能模块的范畴）包含商品信息查询、商品信息更新、商品信息删除、商品定价信息查询以及商品定价信息更新五种功能，功能表的设计见表 2。上面提到的例子可以作为这样几条记录分别插入功能模块表和功能表。insert into TModule values(0， 商品管理模块， goods ，5);insert into Tfunction values(0， 商品信息

42、查询， selectgoods ，0);insert into Tfunction values(1， 商品信息更新， updategoods ，0);insert into Tfunction values(2， 商品信息删除， deletegoods ，0);insert into Tfunction values(3， 商品定价信息查询 ， selectgoodsprice ，0);insert into Tfunction values(4， 商品定价信息更新 ， updategoodsprice ，0);（3） 角色表角色表的设计关键在于角色值的定义，它是一个由 0 和 1 组成的类

43、似二进制数的字符串。而功能表中的 funcNo (功能编号)字段表示该功能在角色表的roleValue (角色值)字段中的位置，如果该位置对应的数值是 0，表示该角色无此权限，如果值为 1，则表示该角色拥有此权限。如角色普通会员的角色值为 100100 00（共 100 位），如上所示，商品信息查询的功能编号为 0，角色值 10010000 的第 0 位为 1，所以该普通会员角色拥有商品信息查询的功能；相反， 该角色值的第 1 位为 0，而功能编号为 1 的功能为商品信息更新，所以该普通会员角色没有商品信息更新的权限。它们的关系可由图 2 来表示。2、角色的添加有了上面几个表，角色页面的功能模

44、块以及其对应的功能都可以从功能模块表和功能表中读出，如图 3 所示。在将新角色普通会员插入数据库时，先将角色值的所有位都置为 0，然后利用.NET Framework 类库中的 Replace 函数将角色值中的打上勾的功能相应的功能编号位的值改为 1。 例如，新添加一个角色名为普通会员的角色，它拥有的功能为商品信息查询（功能编号 0）和商品定价信息查询（功能编号 3）两项，则角色值应为100100000（100 位），即角色值中第 0 位和第 3 位的值为 1，其余为 0。3、利用用户控件实现访问权限在定义好用户控件.ascx 文件（head.ascx）及.ascx.cs（head.ascx，cs）文件时，接下去只要在.aspx 文件中注册和声明它就可以了。(1) 注册% Regis