基于RBAC模型的通用权限管理系统的设计(数据模型)的扩展
1 RBAC模型
访问控制是针对越权使用资源的防御措施。基本目标是为了限制访问主体(用户、进程、服务等)对访问客体(文件、系统等)的访问权限,从而使计算机系统在合法范围内使用;决定用户能做什么,也决定代表一定用户利益的程序能做什么[1]。
企业环境中的访问控制策略一般有三种:自主型访问控制方法、强制型访问控制方法和基于角色的访问控制方法(RBAC)。其中,自主式太弱,强制式太强,二者工作量大,不便于管理[1]。基于角色的访问控制方法是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是:1.减小授权管理的复杂性,降低管理开销;2.灵活地支持企业的安全策略,并对企业的变化有很大的伸缩性。
NIST(The National Institute of Standards and Technology,美国国家标准与技术研究院)标准RBAC模型由4个部件模型组成,这4个部件模型分别是基本模型RBAC0(Core RBAC)、角色分级模型RBAC1(Hierarchal RBAC)、角色限制模型RBAC2(Constraint RBAC)和统一模型RBAC3(Combines RBAC)[1]。RBAC0模型如图1所示。
a. RBAC0定义了能构成一个RBAC控制系统的最小的元素集合。在RBAC之中,包含用户users(USERS)、角色roles(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素,权限被赋予角色,而不是用户,当一个角色被指定给一个用户时,此用户就拥有了该角色所包含的权限。会话sessions是用户与激活的角色集合之间的映射。RBAC0与传统访问控制的差别在于增加一层间接性带来了灵活性,RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。
b. RBAC1引入角色间的继承关系,角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系,允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构。
c. RBAC2模型中添加了责任分离关系。RBAC2的约束规定了权限被赋予角色时,或角色被赋予用户时,以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可。
d. RBAC3包含了RBAC1和RBAC2,既提供了角色间的继承关系,又提供了责任分离关系。
2核心对象模型设计
根据RBAC模型的权限设计思想,建立权限管理系统的核心对象模型.对象模型中包含的基本元素主要有:用户(Users)、用户组(Group)、角色(Role)、目标(Objects)、访问模式(Access Mode)、操作(Operator)。主要的关系有:分配角色权限PA(Permission Assignment)、分配用户角色UA(Users Assignmen描述如下:
a .控制对象:是系统所要保护的资源(Resource),可以被访问的对象。资源的定义需要注意以下两个问题:
1.资源具有层次关系和包含关系。例如,网页是资源,网页上的按钮、文本框等对象也是资源,是网页节点的子节点,如可以访问按钮,则必须能够访问页面。
2.这里提及的资源概念是指资源的类别(Resource Class),不是某个特定资源的实例(Resource Instance)。资源的类别和资源的实例的区分,以及资源的粒度的细分,有利于确定权限管理系统和应用系统之间的管理边界,权限管理系统需要对于资源的类别进行权限管理,而应用系统需要对特定资源的实例进行权限管理。两者的区分主要是基于以下两点考虑:一方面,资源实例的权限常具有资源的相关性。即根据资源实例和访问资源的主体之间的关联关系,才可能进行资源的实例权限判断。例如,在管理信息系统中,需要按照营业区域划分不同部门的客户,A区和B区都具有修改客户资料这一受控的资源,这里“客户档案资料”是属于资源的类别的范畴。如果规定A区只能修改A区管理的客户资料,就必须要区分出资料的归属,这里的资源是属于资源实例的范畴。客户档案(资源)本身应该有其使用者的信息(客户资料可能就含有营业区域这一属性),才能区分特定资源的实例操作,可以修改属于自己管辖的信息内容。
另一方面,资源的实例权限常具有相当大的业务逻辑相关性。对不同的业务逻辑,常常意味着完全不同的权限判定原则和策略。
b.权限:对受保护的资源操作的访问许可(Access Permission),是绑定在特定的资源实例上的。对应地,访问策略(Access Strategy)和资源类别相关,不同的资源类别可能采用不同的访问模式(Access Mode)。例如,页面具有能打开、不能打开的访问模式,按钮具有可用、不可用的访问模式,文本编辑框具有可编辑、不可编辑的访问模式。同一资源的访问策略可能存在排斥和包含关系。例如,某个数据集的可修改访问模式就包含了可查询访问模式。
c.用户:是权限的拥有者或主体。用户和权限实现分离,通过授权管理进行绑定。
d.用户组:一组用户的集合。在业务逻辑的判断中,可以实现基于个人身份或组的身份进行判断。系统弱化了用户组的概念,主要实现用户(个人的身份)的方式。
e.角色:权限分配的单位与载体。角色通过继承关系支持分级的权限实现。例如,科长角色同时具有科长角色、科内不同业务人员角色。
f.操作:完成资源的类别和访问策略之间的绑定。
g.分配角色权限PA:实现操作和角色之间的关联关系映射。
h.分配用户角色UA:实现用户和角色之间的关联关系映射。
该对象模型最终将访问控制模型转化为访问矩阵形式。访问矩阵中的行对应于用户,列对应于操作,每个矩阵元素规定了相应的角色,对应于相应的目标被准予的访问许可、实施行为。按访问矩阵中的行看,是访问能力表CL(Access Capabilities)的内容;按访问矩阵中的列看,是访问控制表ACL(Access Control Lists)的内容。
数据模型图如下:
OA系统权限管理设计方案 l 不同职责的人员,对于系统操作的权限应该是不同的。优秀的业务系统,这是最基本的功能。 l 可以对“组”进行权限分配。对于一个大企业的业务系统来说,如果要求管理员为其下员工逐一分配系统操作权限的话,是件耗时且不够方便的事情。所以,系统中就提出了对“组”进行操作的概念,将权限一致的人员编入同一组,然后对该组进行权限分配。 l 权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用,而不是每开发一套管理系统,就要针对权限管理部分进行重新开发。 l 满足业务系统中的功能权限。传统业务系统中,存在着两种权限管理,其一是功能权限的管理,而另外一种则是资源权限的管理,在不同系统之间,功能权限是可以重用的,而资源权限则不能。 针对OA系统的特点,权限说明: 权限 在系统中,权限通过模块+动作来产生,模块就是整个系统中的一个子模块,可能对应一个菜单,动作也就是整个模块中(在B/S系统中也就是一个页面的所有操作,比如“浏览、添加、修改、删除”等)。将模块与之组合可以产生此模块下的所有权限。 权限组 为了更方便的权限的管理,另将一个模块下的所有权限组合一起,组成一个“权限组”,也就是一个模块管理权限,包括所有基本权限操作。比如一个权限组(用户管理),包括用户的浏览、添加、删除、修改、审核等操作权限,一个权限组也是一个权限。
角色 权限的集合,角色与角色之间属于平级关系,可以将基本权限或权限组添加到一个角色中,用于方便权限的分配。 用户组 将某一类型的人、具有相同特征人组合一起的集合体。通过对组授予权限(角色),快速使一类人具有相同的权限,来简化对用户授予权限的繁琐性、耗时性。用户组的划分,可以按职位、项目或其它来实现。用户可以属于某一个组或多个组。 通过给某个人赋予权限,有4种方式(参考飞思办公系统) A. 通过职位 a) 在职位中,职位成员的权限继承当前所在职位的权限,对于下级职位拥有的权限不可继承。 b) 实例中:如前台这个职位,对于考勤查询有权限,则可以通过对前台这个职位设置考勤查询的浏览权,使他们有使用这个对象的权限,然后再设置个,考勤查询权(当然也可以不设置,默认能进此模块的就能查询),则所有前台人员都拥有考勤查询的权利。 B. 通过项目 a) 在项目中,项目成员的权限来自于所在项目的权限,他们同样不能继承下级项目的权限,而对于项目组长,他对项目有全权,对下级项目也一样。 b) 实例中:在项目中,项目成员可以对项目中上传文档,查看本项目的文档,可以通过对项目设置一个对于本项目的浏览权来实现进口,这样每个成员能访问这个项目了,再加上项目文档的上传权和查看文档权即可。
一种通用权限管理方案的设计方案 分析了权限管理的概念和一些与权限管理容易混淆的概念。提出了一种目前可以应用到绝大多数与权限有关的系统设计中的通用权限管理方案。该方案以角色对用户进行分组,通过用户数据库、角色数据库、权限数据库、用户-权限数据库以及角色-权限数据库来实现权限的分层管理。该设计方案能够由管理员方便的对权限进行设置。通过对角色的权限设置可以达到快速设置权限。通过对用户的权限设置可以达到权限的精确控制。文章最后以某项目为基础对该权限设计方案进行了实现。通过测试,该方案能够很好的对用户权限进行控制,从而提高整个系统的安全性。 标签:权限系统角色数据库 1 权限管理的概念 权限管理是软件系统中最常见的功能之一。所谓权限管理,一般指根据系统设置的安全规则或者安全策略,用户可以访问而且只能访问自己被授权的资源,不多不少。权限管理几乎出现在任何系统里面,只要有用户和密码的系统。尤其是在B/S机构的系统中,由于没有专门的客户端软件系统,所以权限管理就显的尤为重要。如果一个B/S系统的权限管理设计的不好,那么一个“非法用户”就可以轻而易举的获取整个系统的所有本能,包括超级管理员的功能。那么这样的系统还有谁敢使用。 很多人,常将“用户身份认证”、“密码加密”、“系统管理”等概念与权限管理概念混淆。用户身份认证,根本就不属于权限管理范畴。用户身份认证,是要解决这样的问题:用户告诉系统“我是谁”,系统就问用户凭什么证明你就是“谁”呢?对于采用用户名、密码验证的系统,那么就是出示密码。当用户名和密码匹配,则证明当前用户是谁;对于采用指纹等系统,则出示指纹;对于硬件Key 等刷卡系统,则需要刷卡。密码加密,是隶属用户身份认证领域,不属于权限管理范畴。 2 权限管理的设计 2.1 权限管理的对象在一般的系统设计中,权限管理的参于对象包括用户对象、角色(或分组)对象、功能模块对象。角色是为了完成各种工作而创造,用户则依据它的责任和资格来被指派相应的角色。功能模块则对不同的系统来说各不相同,一般在系统设计中最终将其以图形界元素的形式表现出来(比如软件界面上的各个功能按钮)。 2.2 权限管理举例下面我们举例说明2.1中提到的用户、角色、功能三个对象在权限管理中具体应用。表1中列出了某文档管理项目中权限管理的一部分设计表。从中我们可以清晰的区别出这三个对象以及它们的各自作用。
关键字: 用户权限管理 B/S系统中的权限比C/S中的更显的重要,C/S系统因为具有特殊的客户端,所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现,而B/S中,浏览器是每一台计算机都已具备的,如果不建立一个完整的权限检测,那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功能。因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测,让经过授权的用户可以正常合法的使用已授权功能,而对那些未经授权的“非法用户”将会将他们彻底的“拒之门外”。下面就让我们一起了解一下如何设计可以满足大部分B/S系统中对用户功能权限控制的权限系统。 需求陈述 ?不同职责的人员,对于系统操作的权限应该是不同的。优秀的业务系统,这是最基本的功能。 ?可以对“组”进行权限分配。对于一个大企业的业务系统来说,如果要求管理员为其下员工逐一分配系统操作权限的话,是件耗时且不够方便的 事情。所以,系统中就提出了对“组”进行操作的概念,将权限一致的 人员编入同一组,然后对该组进行权限分配。 ?权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用,而不是每开发一套管 理系统,就要针对权限管理部分进行重新开发。 ?满足业务系统中的功能权限。传统业务系统中,存在着两种权限管理,其一是功能权限的管理,而另外一种则是资源权限的管理,在不同系统之 间,功能权限是可以重用的,而资源权限则不能。 关于设计 借助NoahWeb的动作编程理念,在设计阶段,系统设计人员无须考虑程序结构的设计,而是从程序流程以及数据库结构开始入手。为了实现需求,数据库的设计可谓及其重要,无论是“组”操作的概念,还是整套权限管理系统的重用性,都在于数据库的设计。 我们先来分析一下数据库结构:
实现业务系统中的用户权限管理--设计篇 B/S系统中的权限比C/S中的更显的重要,C/S系统因为具有特殊的客户端,所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现,而B/S中,浏览器是每一台计算机都已具备的,如果不建立一个完整的权限检测,那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功能。因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测,让经过授权的用户可以正常合法的使用已授权功能,而对那些未经授权的“非法用户”将会将他们彻底的“拒之门外”。下面就让我们一起了解一下如何设计可以满足大部分B/S系统中对用户功能权限控制的权限系统。 需求陈述 ?不同职责的人员,对于系统操作的权限应该是不同的。优秀的业务系统,这是最基本的功能。 ?可以对“组”进行权限分配。对于一个大企业的业务系统来说,如果要求管理员为其下员工逐一分配系统操作权限的话,是件耗时且不够方便 的事情。所以,系统中就提出了对“组”进行操作的概念,将权限一致 的人员编入同一组,然后对该组进行权限分配。 ?权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用,而不是每开发一套 管理系统,就要针对权限管理部分进行重新开发。 ?满足业务系统中的功能权限。传统业务系统中,存在着两种权限管理,其一是功能权限的管理,而另外一种则是资源权限的管理,在不同系统 之间,功能权限是可以重用的,而资源权限则不能。 关于设计 借助NoahWeb的动作编程理念,在设计阶段,系统设计人员无须考虑程序结构的设计,而是从程序流程以及数据库结构开始入手。为了实现需求,数据库的设计可谓及其重要,无论是“组”操作的概念,还是整套权限管理系统的重用性,都在于数据库的设计。 我们先来分析一下数据库结构: 首先,action表(以下简称为“权限表”),gorupmanager表(以下简称为“管理组表”),以及master表(以下简称为“人员表”),是三张实体表,它们依次记录着“权限”的信息,“管理组”的信息和“人员”的信息。如下图:
收稿日期:2000-10-09 基金项目:国家863/CIMS 并行工程主题资助项目(863-511-930-009) 一种通用的应用系统权限管理的实现方法! 朱建江,王宁生 (南京航空航天大学CIMS 工程研究中心,江苏南京210016) 摘要:从数据库访问权限和应用层各个子系统访问权限两个方面,介绍了一种用于管理信息系统的通用权限管理 方法,并给出了相应的功能模型(DFD ) 和信息模型(ER 图)及部分程序设计代码。关键词:系统权限管理;管理信息系统 中图分类号:TP309.2文献标识码:A 文章编号:1001-3695(2001)07-0062-02 A General Method for the Right Management of Application System ZHU Jian-jiang ,WANG Ning-sheng (CIMS Research Center ,Nanjing Uniuersity of Aeronautics and Astro nautics ,Nanjing Jiangsu 210016,China ) Abstract :From the two aspect of the accessing right of database and sub-system ,a generaI right management method for management information sys-tem is presented ,and the correspondent function modeI (DFD ),information modeI (ER diagram )and a part of program code are aIso given .Key words :System right management ;Management information system !前言一套管理信息系统设计、开发的最后一个步骤就是应用系统的权限管理。所谓权限管理就是应用系统的不同用户,拥有与其角色相配的对特定几个应用子系统(或模块)的不同的操作权限,如对于某模块,系统超级用户拥有“插入、修改、删除、查询”等权限,而对于普通用户仅拥有“查询”权限。应用系统的权限管理从功能模型和信息模型的角度可分为两个层次,即功能层的访问权限管理和数据库访问层的权限管理。目前多数管理软件仅做到应用系统功能层上的权限控制,而没有做到数据库访问层的权限控制。功能层上的权限管理主要有两种,一种是仅控制到应用子系统,即不同的用户可以访问不同的应用子系统的“窗体”,而没有控制到“窗体”上的各个功能菜单。这种做法比较简单,仅在管理信息系统技术发展的初期或非常简单的应用系统中采用,目前多数已经弃之不用。另一种是控制到应用子系统“窗体”上的菜单层,即拥有不同角色的不同用户可以访问不同的应用子系统“窗体”,而且对于窗体上的不同功能菜单拥有不同的权限。这种处理方式是当前系统权限管理技术的主流。然而这种处理方式并没有控制到后台数据库基本表;即什么角色的用户可以对哪些基本表拥有哪几种操作权限。由于仅控制到功能层,并没有给软件用户的系统管理员来说提供一个分配数据库基本表的访问控制界面,系统管理员设置角色权限,给系统用户分配 角色等操作不得不通过手工写SOL 语句来实现, 因此对于系统管理员来说很不方便,尤其是当系统管理员需要分配多个角色、用户时。本文提出一种通用的管理到应用系统功能层和数据库访问层的权限管理方法,对于功能层管理到“窗体”的菜单层,对于数据库访问层管理到基本表和基本表的“增加、删除、修改、查询”等基本操作权限。 " 应用系统权限管理的功能模型设计 [1] 功能模型的表达采用数据流程图—Data FIow Diagram (DFD )。应用系统的权限管理从功能上可分为权限管理基本信息维护、角色管理和用户管理三个处理过程,其相关的数据流、数据存储以及输入、输出关系如图1 所示。 图1应用系统权限管理功能模型(DFD 图) #应用系统权限管理的信息模型设计 信息模型的表达采用“实体—关系图(ER 图)”。在工程 领域,信息模型的设计应满足“三范式”,即非键属性既不函数 依赖于主键,也不传递依赖于主键[2]。在权限管理的信息模 型设计之前首先进行实体的标识。对应用系统功能层和数据库访问层进行权限管理的信息模型应包含以下实体:用户、角色、数据库访问权限、基本表、应用子系统、功能模块访问权限、模块菜单。 系统权限管理信息模型分为两个部分(见图2):对数据库访问权限的管理和对应用系统功能层的访问权限管理。数据库访问权限的管理包括用户表、角色表、数据库访问权限表、数据库基本表。其中用户表用于存储应用系统的所有用户;角色表用于存储所有角色;数据库基本表用于存储应用系统中的所有数据库基本表;对于一个特定的角色可访问多个应用系统的数据库基本表;一个数据库基本表可被多个角色访问,即角色与数据库基本表之间是“多对多”的关系。在数据库设计中这种“多对多”关系是“非确定的”,必须 予以消除,因此引入“中间实体”、“数据库访问权限表”进行处理。给一个角色分配了权限后,就可将这个角色分配给多个用户,角色表和用户表之间是“一对多”的关系。
对EMS权限管理模块设计 1.权限设计概述 引言 随着Web服务的复杂度增加以及用户数量和种类的增多,安全问题在理论及工程上都是一个必须考虑的问题,而权限管理是安全问题中一个很重要的方面。因此本文针对权限做了一个分析。 权限可简单表述为这样的逻辑表达式:判断“Who对What(Which)进行How的操作”的逻辑表达式是否为真。 意义 用户管理及权限管理一直是应用系统中不可缺少的一个部分 系统用户很多,系统功能也很多 不同用户对系统功能的需求不同 出于安全等考虑,关键的、重要的系统功能需限制部分用户的使用 出于方便性考虑,系统功能需要根据不同的用户而定制 目标 直观,因为系统最终会由最终用户来维护,权限分配的直观和容易理解,显得比较重要,除了功能的必须,更主要的就是因为它足够直观。
简单,包括概念数量上的简单和意义上的简单还有功能上的简单。想用一个权限系统解决所有的权限问题是不现实的。设计中将变化的“定制”特点比较强的部分判断为业务逻辑,而将相同的“通用”特点比较强的部分判断为权限逻辑就是基于这样的思路。 扩展,采用可继承的方式解决了权限在扩展上的困难。引进Group概念在支持权限以组方式定义的同时有效避免了权限的重复定义。 2.基于角色的权限管理设计(Role-Based Access Control ,RBAC) 权限管理用例图 用例图描述 超级管理员:系统中默认的角色,它是系统中拥有最高权限的角色,它不仅能够管理其他的管理员和用户,而且还可以对系统中每个模块的任一功能进行操作、维护。 普通管理员:它是由超级管理员创建的,并授予权限,它能够管理系统中大部分的功能,它可以查看所有普通管理员、普通用户的信息,它只能对由它自己创建的用户进行编辑、删除操作,和管理拥有权限的模块。 普通用户:它是系统中最低权限的角色,它只能对自己拥有的权限进行操作,一般情况下,它的权限是对信息的浏览和对自己信息的录入,修改。 登陆系统:根据用户拥有的权限不同,用户所能操作的功能多少就不同,所以在登陆系统的时候就要对用户的权限进行判断。 用户管理:这里对本系统的登录用户进行维护。包括,新建、删除、编辑、注销等;系统初始化的时候,用户管理中默认只有一个拥有超级管理员角色的用户,因此在初始化登陆的时候,只能用这个用户登陆,其他的用户由这个用户创建并授予角色。
OA系统权限管理设计方案7 OA系统权限管理设计方案 数据库2010-02-2310:09:25阅读13评论0字号:大中小 OA系统权限管理设计方案 l不同职责的人员,对于系统操作的权限应该是不同的。优秀的业务系统,这是最基本的功能。 l可以对“组”进行权限分配。对于一个大企业的业务系统来说,如果要求管理员为其下员工逐一分配系统操作权限的话,是件耗时且不够方便的事情。所以,系统中就提出了对“组”进行操作的概念,将权限一致的人员编入同一组,然后对该组进行权限分配。 l权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用,而不是每开发一套管理系统,就要针对权限管理部分进行重新开发。 l满足业务系统中的功能权限。传统业务系统中,存在着两种权限管理,其一是功能权限的管理,而另外一种则是资源权限的管理,在不同系统之间,功能权限是可以重用的,而资源权限则不能。 针对OA系统的特点,权限说明: 权限
在系统中,权限通过模块+动作来产生,模块就是整个系统中的一个子模块,可能对应一个菜单,动作也就是整个模块中(在B/S系统中也就是一个页面的所有操作,比如“浏览、添加、修改、删除”等)。将模块与之组合可以产生此模块下的所有权限。 权限组 为了更方便的权限的管理,另将一个模块下的所有权限组合一起,组成一个“权限组”,也就是一个模块管理权限,包括所有基本权限操作。比如一个权限组(用户管理),包括用户的浏览、添加、删除、修改、审核等操作权限,一个权限组也是一个权限。 角色 权限的集合,角色与角色之间属于平级关系,可以将基本权限或权限组添加到一个角色中,用于方便权限的分配。 用户组 将某一类型的人、具有相同特征人组合一起的集合体。通过对组授予权限(角色),快速使一类人具有相同的权限,来简化对用户授予权限的繁琐性、耗时性。用户组的划分,可以按职位、项目或其它来实现。用户可以属于某一个组或多个组。 通过给某个人赋予权限,有4种方式(参考飞思办公系统) A.通过职位 a)在职位中,职位成员的权限继承当前所在职位的权限,对
多系统权限设计 1.多系统基于角色的权限设计 这种方案是最常见也是比较简单的方案,不过通常有这种设计已经够了,这种方案对于每一个操作不做控制,只是在程序中根据角色对是否具有操作的权限进行控制;这里我们就不做详述.此处采用角色关联模块的方式。 2.多系统基于操作的权限设计 这种模式下每一个操作都在数据库中有记录,用户是否拥有该操作的权限也在数据库中有记录,结构如下:
但是如果直接使用上面的设计,会导致数据库中的_SysUserFuncOperate这张表数据量非常大,所以我们需要进一步设计提高效率,请看方案3 3.多系统基于角色和操作的权限设计
如上图所示,我们通过采用角色分配操作的方式,这样子就可以减少操作权限表(_SysRole FuncOperate)中的记录,并且使设计更灵活一点。 但是这种方案在用户需求的考验之下也可能显得不够灵活够用,例如当用户要求临时给某位普通员工某操作权限时,我们就需要新增加一种新的用户角色,但是这种用户角色是不必要的,因为它只是一种临时的角色,如果添加一种角色还需要在收回此普通员工权限时删除此角色,我们需要设计一种更合适的结构来满足用户对权限设置的要求。 4.2,3组合的权限设计,其结构如下: 我们可以看到在上图中添加了_SysUserFunc和_SysUserFuncOperate表,使用此表来添加特殊用户的权限。这样在应用程序中我们就需要通过_SysUserFuncOperate和_SysRoleFuncOperat e两张表中的记录判断权限。 当然,有可能用户还会给出这样的需求:对于某一种Operate所操作的对象某一些记录会有权限,而对于其他的记录没有权限,比如说一个内容管理系统,对于某一些频道某个用户有
通用数据权限管理系统设计(一) 作者:逸云 前言: 本文提供一种集成功能权限和数据权限的解决方法,以满足多层次组织中权限管理方面的集中控制。本方法是RBAC(基于角色的访问控制方法)的进一步扩展和延伸,即在功能权限的基础上增加数据权限的管理,实现数据权限和功能权限的集中处理。 解释: 功能权限:能做什么的问题,如增加销售订单; 数据权限:能在哪里干什么的问题,如察看北京分公司海淀销售部张三的销售订单; 术语: 资源:系统中的资源,主要是各种业务对象,如销售单、付款单等; 操作类型:对资源可能的访问方法,如增加、删除、修改等; 功能:对资源的操作,是资源与操作类型的二元组,如增加销售单、修改销售单等; 数据类型:业务系统中常用的数据权限类型,如公司、部门、项目、个人等; 数据对象:具体的业务对象,如甲公司、乙部门等等,包括所有涉及到数据权限的对象值;权限:角色可使用的功能,分角色的功能权限和角色的数据权限; 角色:特定权限的集合; 用户:参与系统活动的主体,如人,系统等。 通用数据权限管理系统设计(二) 方法说明: 在实际应用中,数据权限的控制点一般相对固定,如针对公司、部门、个人、客户、供应商等,也就是说数据权限一般针对指定数据类型下的一些数据对象。 本方法中,数据权限的依赖于功能权限,是对功能权限的进一步描述,说明角色在指定的功能点上的数据控制权限。 本方法中采用“没有明确规定即视为有效”的原则,如果没有定义功能的数据权限,则说明该角色具有该功能的全部的权限。如果定义了功能的某种类型的数据权限,则该用户只具有该类型下指定数据的数据权限。 这段话比较绕口,下面举个例子实际例子。 某公司有北京销售部、上海销售部和广州销售部三个销售部,现在需要定义几种角色:销售总监-- 能察看所有销售部的销售订单; 北京销售经理-- 只能察看北京销售部的所有销售订单; 上海销售经理-- 只能察看上海销售部的所有销售订单; 广州销售经理-- 只能察看广州销售部的所有销售订单;
高级软件工程课程设计 基于web的通用权限管理系统的设计与实现 1 研究现状 权限管理技术的理论研究开始于20世纪60年代末70年代初,所权限管理,就是通过某种途径显示地准许或限制访问能力及范围,从而限制对关键资源的访问,防止非法用户的侵入或者合法用户的不慎操作造成破坏。随着计算机技术和应用的发展,特别是互联网的发展,应用系统对于权限管理的需求开始迅速增加。在随后40年的发展历程中,人们在权限管理技术的研究方面取得了很大的成果,先后出现过多种权限管理访问控制技术。20世纪80年代到90年代初,自主权限管理自主访问控制技术、强制访问控制技术得到了美国国防部制定的橘皮书-可信计算机评估准则的认证。但是,近几年来,人们普遍感到DAC和MAC的权限管理技术无法满足现今日趋复杂的应用系统的安全需求。因此,基于角色的权限管理(RBAC),便成为人们研究访问控制技术的重点和热点。 2 可行性研究 可行性研究是对项目进行可行性调研和论证,确定项目开发的价值和意义以及是否可以付诸实施。其目的是在对比投入和产出的基础上考虑利用目前的资源、成本等因素能否实现一个系统以及是否会创造价值或带来实际的意义。 可行性分析 可行性分析一般可定义为,可行性分析是在建设的前期对工程项目的一种考察和鉴定,对拟议中的项目进行全面与综合的技术、经济能力的调查,判断它是否可行。 2.1社会可行性分析 通用权限管理系统的开发符合国家法律,能够与社会大系统实现良好的对接。 2.2 技术可行性分析 开发通用权限管理系统具备所需要的条件。开发通用权限管理系统使用的MS Visual Studio 2008系统开发工具。Windows系列操作系统已经是普遍使用的系统,所以在技术上是成熟的。
一个用户权限管理模块的设计思路: 1. 权限资源(功能资源) 系统的所有权限信息。权限具有上下级关系,是一个树状的结构。如下: 系统管理 单位管理 查看单位 添加单位 修改单位 删除单位 部门管理 查看部门 添加部门 修改单位 删除单位 对于每个权限,又存在两种情况:1可访问;2可授权,部分表中采用拥有类型做判断(0可访问,1即可访问也可授权) 2. 用户 系统的具体操作者,用户可以自己拥有权限信息,可以归属于0~n个角色,可属于0~n 个组。他的权限集是自身具有的权限+所属的各角色具有的权限+所属的各组具有的权限的合集。它与权限、角色、组之间的关系都是n对n的关系。 3. 角色 为了对拥有相似权限的用户进行分类管理,因此定义角色,例如:超级管理员,一般管理员、一般用户等角色。在这里同时也让角色具有上下级关系,形成树状视图,父级角色的权限是自身及它的所有子角色的权限的综合。 4. 组 为了更好地管理用户,对用户进行分组归类,简称为用户分组。组也具有上下级关系,可以形成树状视图。在实际应用中,我们知道,组也可以具有自己的角色信息、权限信息。 就好比是javaeye中的圈子,一个圈子可以拥有多个会员,同时一个会员也可以加入多个圈子,对于不同的圈子又有不同的权限信息。(组的解释:例如一个公司中,不同的部门即可划分不同的组来进行权限的分配) 针对以上描述,结构关系如下: 整个模块分为组权限管理、角色权限管理、用户权限管理。 其中组权限管理:组权限 = 所属角色的权限合集 + 组自身的权限。
角色权限管理:角色权限 = 角色自身权限。 用户权限管理:用户权限 = 所属角色权限合集 + 所属组权限合集 + 用户自身权限。 注意:因为组和角色都具有上下级关系,所以下级的组或角色的权限只能在自己的直属上级的权限中选择,下级的组或者角色的总的权限都不能大于直属上级的总权限。 欢迎大家拍砖,给点建议。
OA系统权限管理设计方案 不同职责的人员,对于系统操作的权限应该是不同的。优秀的业务系统,这是最基本的 功能。 可以对“组”进行权限分配。对于一个大企业的业务系统来说,如果要求管理员为其下员工逐一分配系统操作权限的话,是件耗时且不够方便的事情。所以,系统中就提出了对“组” 进行操作的概念,将权限一致的人员编入同一组,然后对该组进行权限分配。 权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用,而不是每开发一套管理系统,就要针对权限管理部分进 行重新开发。 满足业务系统中的功能权限。传统业务系统中,存在着两种权限管理,其一是功能权限的管理,而另外一种则是资源权限的管理,在不同系统之间,功能权限是可以重用的,而资源 权限则不能。 针对OA系统的特点,权限说明: 权限 在系统中,权限通过模块+动作来产生,模块就是整个系统中的一个子模块,可能对应一个菜单,动作也就是整个模块中(在B/S系统中也就是一个页面的所有操作,比如“浏览、添加、修改、删除”等)。将模块与之组合可以产生此模块下的所有权限。 权限组 为了更方便的权限的管理,另将一个模块下的所有权限组合一起,组成一个“权限组”,也就是一个模块管理权限,包括所有基本权限操作。比如一个权限组(用户管理),包括用户的浏览、添加、删除、修改、审核等操作权限,一个权限组也是一个权限。 角色 权限的集合,角色与角色之间属于平级关系,可以将基本权限或权限组添加到一个角色中, 用于方便权限的分配。 用户组 将某一类型的人、具有相同特征人组合一起的集合体。通过对组授予权限(角色),快速使一类人具有相同的权限,来简化对用户授予权限的繁琐性、耗时性。用户组的划分,可以按职位、项目或其它来实现。用户可以属于某一个组或多个组。
OA权限管理设计的实现 任何系统都离不开权限的管理,有一个好的权限管理模块,不仅使我们的系统操作自如,管理方便,也为系统添加亮点。 不同职责的人员,对于系统操作的权限应该是不同的。优秀的业务系统,这是最基本的功能。 可以对“组”进行权限分配。对于一个大企业的业务系统来说,如果要求管理员为其下员工逐一分配系统操作权限的话,是件耗时且不够方便的事情。所以,系统中就提出了对“组”进行操作的概念,将权限一致的人员编入同一组,然后对该组进行权限分配。 权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用,而不是每开发一套管理系统,就要针对权限管理部分进行重新开发。 满足业务系统中的功能权限。传统业务系统中,存在着两种权限管理,其一是功能权限的管理,而另外一种则是资源权限的管理,在不同系统之间,功能权限是可以重用的,而资源权限则不能。 针对OA系统的特点,权限说明: 权限 在系统中,权限通过模块+动作来产生,模块就是整个系统中的一个子模块,可能对应一个菜单,动作也就是整个模块中(在B/S系统中也就是一个页面的所有操作,比如“浏览、添加、修改、删除”等)。将模块与之组合可以产生此模块下的所有权限。 权限组 为了更方便的权限的管理,另将一个模块下的所有权限组合一起,组成一个“权限组”,也就是一个模块管理权限,包括所有基本权限操作。比如一个权限组(用户管理),包括用户的浏览、添加、删除、修改、审核等操作权限,一个权限组也是一个权限。 角色 权限的集合,角色与角色之间属于平级关系,可以将基本权限或权限组添加到一个角色中,用于方便权限的分配。 用户组 将某一类型的人、具有相同特征人组合一起的集合体。通过对组授予权限(角色),快速使一类人具有相同的权限,来简化对用户授予权限的繁琐性、耗时性。用户组的划分,可以按职位、项目或其它来实现。用户可以属于某一个组或多个组。 通过给某个人赋予权限,有4种方式(参考飞思办公系统) A.通过职位 a)在职位中,职位成员的权限继承当前所在职位的权限,对于下级职位拥有的权限 不可继承。
通用权限管理系统开发文档 部门:地理信息部 作者:王立彪 版本: 时间:2017-01-13
目录 1. 简单模型描述..............................................错误!未定义书签。 . E-R图..............................................错误!未定义书签。 . 表格清单............................................错误!未定义书签。 . 外键清单............................................错误!未定义书签。 . 视图清单............................................错误!未定义书签。 . 序列清单............................................错误!未定义书签。 2. 完全模型描述..............................................错误!未定义书签。 . E-R图..............................................错误!未定义书签。 . 表格清单............................................错误!未定义书签。 表格shiro_user(系统用户表).................错误!未定义书签。 表格shiro_role(系统角色表).................错误!未定义书签。 表格shiro_dept(系统部门表).................错误!未定义书签。 表格shiro_resource(系统资源表).............错误!未定义书签。 表格shiro_permission(系统权限表)...........错误!未定义书签。 表格shiro_group(系统组表)..................错误!未定义书签。 表格shiro_user_role(系统用户与角色关系表) ..错误!未定义书签。 表格shiro_role_resource(系统角色与资源关系表)错误!未定义书签。 表格shiro_role_permission(系统角色与权限关系表)错误!未定义书签。 表格shiro_group_user(系统组与用户关系表) ...错误!未定义书签。 表格shiro_reource_permission(系统资源与权限关系表)错误!未定义书签。 表格shiro_group_role(系统组与角色关系表) ...错误!未定义书签。
系统权限设计 需求陈述 ?不同职责的人员,对于系统操作的权限应该是不同的。可以对“组”进行权限分配。 ?对于一个大企业的业务系统来说,如果要求管理员为其下员工逐一分配系统操作权限的话,是件耗时且不够方便的 事情。所以,系统中就提出了对“组”进行操作的概念, 将权限一致的人员编入同一组,然后对该组进行权限分配。 ?权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断 的重用,而不是每开发一套管理系统,就要针对权限管理 部分进行重新开发。 ?满足业务系统中的功能权限。传统业务系统中,存在着两种权限管理,其一是功能权限的管理,而另外一种则是资 源权限的管理,在不同系统之间,功能权限是可以重用的,而资源权限则不能 (以后可以加入权限分配管理的功能,目前暂不考虑) 首先,action表(以下简称为“权限表”),gorupmanager表(以
下简称为“管理组表”),以及master表(以下简称为“人员表”),是三张实体表,它们依次记录着“权限”的信息,“管理组”的信息和“人员”的信息。如下图: 首先,action表(以下简称为“权限表”),gorupmanager 表(以下简称为“管理组表”),以及master表(以下简称为“人员表”),是三张实体表,它们依次记录着“权限”的信息,“管理组”的信息和“人员”的信息。如下图: 这三个表之间的关系是多对多的,一个权限可能同时属于多个管理组,一个管理组中也可能同时包含多个权限。同样的道理,一个人员可能同时属于多个管理组,而一个管理组中也可能同时包含多个人员。如下图:
由于这三张表之间存在着多对多的关系,那么它们之间的交互,最好使用另外两张表来完成。而这两张表起着映射的作用,分别是“actiongroup”表(以下简称“权限映射表”)和“mastergroup”表(以下简称“人员映射表”),前者映射了权限表与管理组表之间的交互。后者映射了人员表与管理组表之间的交互。如下图:
第一章引言 1.1 编写目的 系统详细设计说明书在概要设计的基础上,对统一权限管理系统的各模块、数据等分别进行了实现层面上的要求和说明。 本文档读者为系统设计人员、软件实现人员等(编码人员、测试人员),为程序的开发提供依据。 1.2 背景 石家庄大学有办公自动化系统、图书管理系统、教务系统、排课系统、宿舍管理系统等等系统。每个系统都有独立的系统管理权限模块,不便于学校系统管理员的统一管理,而且管理成本也比较高。 统一权限管理系统实现以上软件的统一权限管理,实现系统管理、用户管理等功能,是实现单点登录的基础。 1、项目名称是《统一权限管理系统》; 2、本项目的委托单位是石家庄大学,开发单位是安全一班和二班的全体同学,主管部 门信息工程系。 1.3 定义 权限: 角色 数据库建模: 统一权限管理: 三层架构:
1.4 参考文献 用到的参考资料如下表1.1所示: 表1.1 参考资料表
第二章总体设计 2.1 系统功能概述 通过此权限软件来统一管理我们学校所有或大部分系统软件的用户权限,降低整个学校系统的权限分配复杂性、提高可维护性、降低系统管理员的管理成本。为二期的统一用户单点登录工程项目打下了良好的基础。 通过系统概要设计说明书可知,此统一权限管理系统主要实现系统管理、权限管理、用户管理、日志管理等功能。系统功能结构如图2.1所示。 图2.1 系统功能结构图 2.2 系统软件结构 统一权限管理系统的软件结构如图2.2所示。
图2.2 系统软件结构图
第三章数据设计 3.1 静态数据 初始状态下,统一权限管理系统的测试用户,设置初始超级管理员,其登录用户名为admin,密码为123456。 初始测试用户如表3.1所示。 表3.1 初始测试用户表 3.2 动态数据 统一权限管理系统涉及到的基本数据信息有系统信息、系统模块信息、角色信息、划分权限信息、用户信息、分配角色信息、部门信息等。 一、系统信息 系统信息应包含系统编号、系统名称、系统描述信息、显示顺序等,如表3.2所示。 表3.2 系统信息表 二、系统模块信息 系统模块信息应包含模块编号、模块名称、模块描述、模块地址、显示顺序、显示图标等,如表3.3所示。 表3.3 系统模块信息表
基于RBAC模型的通用权限管理系统的设计(数据模型)的扩展 1 RBAC模型 访问控制是针对越权使用资源的防御措施。基本目标是为了限制访问主体(用户、进程、服务等)对访问客体(文件、系统等)的访问权限,从而使计算机系统在合法范围内使用;决定用户能做什么,也决定代表一定用户利益的程序能做什么[1]。 企业环境中的访问控制策略一般有三种:自主型访问控制方法、强制型访问控制方法和基于角色的访问控制方法(RBAC)。其中,自主式太弱,强制式太强,二者工作量大,不便于管理[1]。基于角色的访问控制方法是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是:1.减小授权管理的复杂性,降低管理开销;2.灵活地支持企业的安全策略,并对企业的变化有很大的伸缩性。 NIST(The National Institute of Standards and Technology,美国国家标准与技术研究院)标准RBAC模型由4个部件模型组成,这4个部件模型分别是基本模型RBAC0(Core RBAC)、角色分级模型RBAC1(Hierarchal RBAC)、角色限制模型RBAC2(Constraint RBAC)和统一模型RBAC3(Combines RBAC)[1]。RBAC0模型如图1所示。 a. RBAC0定义了能构成一个RBAC控制系统的最小的元素集合。在RBAC之中,包含用户users(USERS)、角色roles(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素,权限被赋予角色,而不是用户,当一个角色被指定给一个用户时,此用户就拥有了该角色所包含的权限。会话sessions是用户与激活的角色集合之间的映射。RBAC0与传统访问控制的差别在于增加一层间接性带来了灵活性,RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。 b. RBAC1引入角色间的继承关系,角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系,允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构。 c. RBAC2模型中添加了责任分离关系。RBAC2的约束规定了权限被赋予角色时,或角色被赋予用户时,以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可。 d. RBAC3包含了RBAC1和RBAC2,既提供了角色间的继承关系,又提供了责任分离关系。 2核心对象模型设计
权限管理模块设计说明书 摘要 权限管理分为两个部分,操作权限管理和资源权限管理。针对我们的系统,分别进行说明。 一、操作权限管理即为允许用户使用那些功能,进行哪些操作。有两个地方需要处理, 1、对用户隐藏没有授权的功能。如“LOG管理”功能没有对用户A授权,则用户A是看不见“LOG 管理”这个功能菜单的。 2、在功能所在的页面进行权限验证,防止没有授权的用户通过输入URL进入功能所在页面。 如“LOG管理”功能没有对用户A授权,则用户A是即使是手动输入“LOG管理”功能所在的页面,他也无法使用这个功能。 在实现方式上可以通过”角色”和”功能”来实现,一个”角色”对应多个”功能”,”用户”与”角色”是多对多的关系。当用户登录时通过 (用户->角色->功能)查询出该用户可以使用的功能列表并显示,无权使用的功能将被隐藏。并且在功能所在页面进行权限验证,避免没有权限的用户通过特殊方法进入页面。 二、资源权限管理的意思是限制用户对资源的访问和操作。 1、省级的用户可以查看和操作全省的数据。但不能查看和操作外省的数据。 2、市级的用户可以查看和操作全市的数据,但不能查看和操作该市以外的数据。 3、全国级的用户可以查看和操作全国的数据。
目录 1概述 (3) 1.1目的 (3) 2模块结构描述 (3) 3模块功能描述 (3) 3.1权限管理 (3) 3.1.1功能菜单管理 (3) 3.1.2用户管理 (4) 3.1.3角色管理 (4) 3.2操作权限验证 (4) 3.2.1登录验证 (5) 3.2.2页面载入验证 (5) 3.2.3页面操作权限验证 (5) 3.3资源权限验证 (6) 4数据库设计ER图 (6)
用户权限管理设计方案 用户认证管理设计方案 1 设计思路 为了设计一套具有较强可扩展性的用户认证管理,需要建立用户、角色和权限等数据库表,并且建立之间的关系,具体实现如下。 1.1 用户 用户仅仅是纯粹的用户,用来记录用户相关信息,如用户名、密码等,权限是被分离出去了的。用户(User)要拥有对某种资源的权限,必须通过角色(Role)去关联。 用户通常具有以下属性: 编号,在系统中唯一。 名称,在系统中唯一。 用户口令。 注释,描述用户或角色的信息。 1.2 角色 角色是使用权限的基本单位,拥有一定数量的权限,通过角色赋予用户权限,通常具有以下属性: 编号,在系统中唯一。 名称,在系统中唯一。 注释,描述角色信息
1.3 权限 权限指用户根据角色获得对程序某些功能的操作,例如对文件的读、写、修改和删除功能,通常具有以下属性: 编号,在系统中唯一。 名称,在系统中唯一。 注释,描述权限信息 1.4 用户与角色的关系 一个用户(User)可以隶属于多个角色(Role),一个角色组也可拥有多个用户,用户角色就是用来描述他们之间隶属关系的对象。用户(User)通过角色(Role)关联所拥有对某种资源的权限,例如 用户(User): UserID UserName UserPwd 1 张三xxxxxx 2 李四xxxxxx …… 角色(Role): RoleID RoleName RoleNote 01 系统管理员监控系统维护管理员 02 监控人员在线监控人员 03 调度人员调度工作人员 04 一般工作人员工作人员
…… 用户角色(User_Role): UserRoleID UserID RoleID UserRoleNote 1 1 01 用户“张三”被分配到角色 “系统管理员” 2 2 02 用户“李四”被分配到角 色“监控人员” 3 2 03 用户“李四”被分配到角色 “调度人员” …… 从该关系表可以看出,用户所拥有的特定资源可以通过用户角色来关联。 1.5 权限与角色的关系 一个角色(Role)可以拥有多个权限(Permission),同样一个权限可分配给多个角色。例如: 角色(Role): RoleID RoleName RoleNote 01 系统管理员监控系统维护管理员 02 监控人员在线监控人员 03 调度人员调度工作人员 04 一般工作人员工作人员 ……