基于角色的访问控制

转载 2015年11月21日 14:29:26

RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限进行关联。简单地说,一个用户拥有若干角色,每一个角色拥有若干权限。这样,就构造成“用户-角色-权限”的授权模型。在这种模型中,用户与角色之间,角色与权限之间,一般者是多对多的关系。(如下图)



角色是什么?可以理解为一定数量的权限的集合,权限的载体。例如:一个论坛系统,“超级管理员”、“版主”都是角色。版主可管理版内的帖子、可管理版内的用户等,这些是权限。要给某个用户授予这些权限,不需要直接将权限授予用户,可将“版主”这个角色赋予该用户。 

 

当用户的数量非常大时,要给系统每个用户逐一授权(授角色),是件非常烦琐的事情。这时,就需要给用户分组,每个用户组内有多个用户。除了可给用户授权外,还可以给用户组授权。这样一来,用户拥有的所有权限,就是用户个人拥有的权限与该用户所在用户组拥有的权限之和。(下图为用户组、用户与角色三者的关联关系)

在应用系统中,权限表现成什么?对功能模块的操作,对上传文件的删改,菜单的访问,甚至页面上某个按钮、某个图片的可见性控制,都可属于权限的范畴。有些权限设计,会把功能操作作为一类,而把文件、菜单、页面元素等作为另一类,这样构成“用户-角色-权限-资源”的授权模型。而在做数据表建模时,可把功能操作和资源统一管理,也就是都直接与权限表进行关联,这样可能更具便捷性和易扩展性。(见下图)



请留意权限表中有一列“权限类型”,我们根据它的取值来区分是哪一类权限,如“MENU”表示菜单的访问权限、“OPERATION”表示功能模块的操作权限、“FILE”表示文件的修改权限、“ELEMENT”表示页面元素的可见性控制等。

 

这样设计的好处有二。其一,不需要区分哪些是权限操作,哪些是资源,(实际上,有时候也不好区分,如菜单,把它理解为资源呢还是功能模块权限呢?)。其二,方便扩展,当系统要对新的东西进行权限控制时,我只需要建立一个新的关联表“权限XX关联表”,并确定这类权限的权限类型字符串。

 

这里要注意的是,权限表与权限菜单关联表、权限菜单关联表与菜单表都是一对一的关系。(文件、页面权限点、功能操作等同理)。也就是每添加一个菜单,就得同时往这三个表中各插入一条记录。这样,可以不需要权限菜单关联表,让权限表与菜单表直接关联,此时,须在权限表中新增一列用来保存菜单的ID,权限表通过“权限类型”和这个ID来区分是种类型下的哪条记录。

 

到这里,RBAC权限模型的扩展模型的完整设计图如下:



随着系统的日益庞大,为了方便管理,可引入角色组对角色进行分类管理,跟用户组不同,角色组不参与授权。例如:某电网系统的权限管理模块中,角色就是挂在区局下,而区局在这里可当作角色组,它不参于权限分配。另外,为方便上面各主表自身的管理与查找,可采用树型结构,如菜单树、功能树等,当然这些可不需要参于权限分配。


另外一篇


名词解释:
RBAC:Role-Based Access Control,基于角色的访问控制
 
关键词:
RBAC,Java Shiro,Spring Security,
 
一. RBAC 要解决的常见问题
问题一:对某一个用户只授予一些特殊的权限
描述:既不希望扩大某一个角色的权限,也不希望因此创建出很多零碎的、只为一个用户而存在的角色。
 
问题二:性能问题
描述:B/S 下,菜单、页面、页面元素、dataset的列,这些层层权限判断过于复杂,容易造成系统访问非常缓慢。
 
问题三:如何减少 HardCode(硬编码)
描述:
 
问题四:系统上线后,某个页面增加一个新HTML控件或数据集,这种细粒度权限控制如何以最快速度添加?
描述:对一个 Resource 的 Privilege ,如何快速增加定义?如何快速分配权限?页面如何控制?
 
问题五:系统上线后,增加一个新细粒度权限控制,运营部门如何最快速度将其应用到已存在角色和帐号上?
描述:对于系统中已存在的成百上千角色、成千上万帐号甚至于无数用户组,一个运营部门的管理人员,如何能以最小代价,通过界面,将此权限分配出去。
 
二. 一个在权限逻辑和业务逻辑之间做切割的设计原则
2.1.细粒度是否算权限系统的范畴
先解释两个概念:
  • 粗粒度:表示类别级。即仅考虑对象的类别,不考虑对象的某个特定实例。譬如,用户管理中,增删改查,对所有的用户都一视同仁,并不区分操作的具体对象实例。
  • 细粒度:表示实例级。即需要考虑具体对象的实例,当然,细粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。譬如,合同管理中,列表、删除,需要区分该合同实例是否为当前用户所创建。
权限逻辑配合业务逻辑。
譬如,需求方给出了一个场景:“合同资源只能被它的创建者删除,与创建者同组的用户可以修改,所有的用户能够浏览”,那么这既可以认为是一个细粒度的权限问题,也可以认为是一个业务逻辑问题
如果认为这是一个业务逻辑问题,那么设计权限系统时就不需要过多考虑这种场景。
当然,权限系统也必须能支持这样的控制判断,或者说,权限系统提供足够多但不是完全的控制能力。
此时,设计原则归结为:“系统只提供粗粒度的权限,细粒度的权限被认为是业务逻辑的职责”。
这也是复杂问题简单化的一种思路。
 
这些对具体 Resource Instance 的细粒度权限问题,被留给业务逻辑来解决,这样的考虑基于以下两点:
  1. 细粒度的权限判断必须要在资源上建模权限分配的支持信息才可能得以实现。这样,又引入了 Owner 概念。
    • 譬如,如果要求创建者和普通用户看到不同的信息内容,那么资源本身应该有其创建者的信息。如同 Unix 的每一个文件(资源),都定义了对 Owner, Group, All 的不同操作属性。
  2. 细粒度的权限常常具有相当大的业务逻辑相关性。
    • 对不同的业务逻辑,常常意味着完全不同的权限判定原则和策略。相比之下,粗粒度的权限更具通用性,将其实现为一个架构,更有重用价值;而将细粒度的权限判断实现为一个架构级别的东西就显得繁琐,而且不是那么的有必要,用定制的代码来实现就更简洁,更灵活。
当然,郑昀说,权限系统不可能做成通用,必须就事论事,所以往往在设计时,还是既照顾粗粒度也照顾细粒度。这里只是提一下有这种一刀切的思路。
 
2.1.数据集的列权限是否算权限系统的范畴
页面需要展示一个数据集(dataset),那么对某些列的展示、可读、可写的控制,是否要放在权限系统中解决?
答案是,为了简化,为了避免过度侵入业务逻辑,列权限不在权限系统范畴内。
 
三. RBAC 是什么
RBAC 认为权限授权实际上是 WhoWhatHow 的问题,即可简单表述为:判断“Who 对 What(Which) 进行 How 的操作”的逻辑表达式是否为真
 
RBAC 涉及的概念有:
  • Who:权限的拥用者或主体(如 UserGroupRole 等);
  • What:权限针对的对象或资源(ResourceClass);
  • How:具体的权限(Privilege)。
    • 正向授权在开始时假定主体没有任何权限,然后根据需要授予权限,适合于权限要求严格的系统。
    • 负向授权在开始时假定主体有所有权限,然后将某些特殊权限收回。
  • Operator:操作。表明对 What 的 How 操作。
    • 也就是 Privilege+Resource ;
    • 注意,这里的 Resource 仅包括 Resource Type 不表示 Resource Instance;
    • 之所以将 What 和 How 绑在一起作为一个 Operator 概念,而不是分开建模再建立关联,这是因为很多的 How 对于某个具体 What 才有意义。譬如,发布操作对新闻对象才有意义,对用户对象则没有意义。
  • Role:角色,一定数量的权限的集合。权限分配的单位与载体,目的是隔离 User 与 Privilege 的逻辑关系;
  • Group:用户组,权限分配的单位与载体。权限不考虑分配给特定的用户而给组。组可以包括组(以实现权限的继承),也可以包含用户,组内用户继承组的权限。User 与 Group 是多对多的关系。Group 可以层次化,以满足不同层级权限控制的要求。
  • Session: 会话是用户与激活的角色集合之间的映射。每个 Session 和单个的 User 关联,每个 User 可以关联到一或多个 Session 。
 
RBAC 支持三个安全原则:
  1. 最小权限原则(即细粒度控制原则):
    • RBAC 可将其角色配置成其完成任务所需要的最小权限集;
  2. 责任分离原则
    • 通过调用相互独立互斥的角色来共同完成敏感的任务而体现,如要求一个计帐员和财务管理员一起参与同一个过帐;
  3. 数据抽象原则
    • 通过权限的抽象来体现,如财务操作用借款、存款等抽象权限。
 
四. 标准 RBAC 模型
NIST (美国国家标准与技术研究院)标准 RBAC 模型由4个部件模型组成,分别是基本模型RBAC0Core RBAC)、角色分级模型RBAC1Hierarchal RBAC)、角色限制模型RBAC2Constraint RBAC)和统一模型RBAC3Combines RBAC)。
RBAC0 模型如图1所示:
http://images.cnblogs.com/cnblogs_com/zhengyun_ustc/255879/o_clipboard39.png
图1 RBAC 0 模型
RBAC0 定义了能构成一个 RBAC 控制系统的最小的元素集合:
  • RBAC 定义了 五个基本数据元素:
    1. 用户 users(USERS)
    2. 角色 roles(ROLES)
    3. 目标 objects(OBS)
    4. 操作 operations(OPS)
    5. 许可权 permissions(PRMS)
  • RBAC0 业务规则有:
    • 一个用户可以对应多个角色,一个角色也可以分配给多个用户;
    • 一个角色可以有多个许可权,一种许可权则只与一个角色对应;
    • 用户可以发起会话,会话中可以激活多个角色来获取许可权;
    • 用户、角色、许可权全部由超级管理员创建与指派;
    • 一个用户拥有多个角色时,高优先级的角色权限覆盖低优先级的角色权限。
RBAC1(引入角色继承关系)、RBAC2(引入责任分离关系)、RBAC3 (角色继承+责任分离)都是先后在 RBAC0 上的扩展。
 
五. RBAC 核心对象模型
授权模型:用户-角色-权限
 
核心动作:
  • 创造权限
  • 分配权限
  • 使用权限
 
核心动作的主要参与者:
  • Creator 创造权限:这里完成的是 Privilege 与 Resource 的对象声明;
  • Administrator 分配权限:把 Privilege 与 Resource Instance 真正关联到一起,产生了 Operator (Privilege Instance)。Administrator 利用 Operator 这个基本元素,来创造他理想中的权限模型,如创建角色,创建用户组,给用户组分配用户,将用户组与角色关联等;
  • User 使用权限

相关文章推荐

RBAC(Role-Based Access Control,基于角色的访问控制)

转: RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限进行关联。简单地说,一个用户拥有若干角色,每一个角色拥有若干权限。...

基于角色管理的系统访问控制

引言(Introduction) 1.1. 关键词定义(Definitions) 有关定义说明如下: 安全管理:计算机技术安全管理的范围很广,可以包括网络安全性、数据安全性、操作系统安全性以及应用程序...

YII framework下基于角色的访问控制(RBAC)

yii下,filters()和accessControl()是YII基本的访问控制体系, public function filters(){     return array(        ...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)