转:rbac权限控制

月是故乡明95 月是故乡明95     2022-08-14     120

关键词:

名词解释:
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 认为权限授权实际上是 Who、What、How 的问题,即可简单表述为:判断“Who 对 What(Which) 进行 How 的操作”的逻辑表达式是否为真
 
RBAC 涉及的概念有:
  • Who:权限的拥用者或主体(如 User、Group、Role 等);
  • What:权限针对的对象或资源(Resource、Class);
  • 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个部件模型组成,分别是基本模型RBAC0(Core RBAC)、角色分级模型RBAC1(Hierarchal RBAC)、角色限制模型RBAC2(Constraint RBAC)和统一模型RBAC3(Combines 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 使用权限
 
 

参考资料:

1)iteye编辑总结,权限控制讨论
3) jackyz@jdon,2002,关于权限系统的设计

转:rbac如何设计一个权限系统

前言权限管理是所有后台系统的都会涉及的一个重要组成部分,主要目的是对不同的人访问资源进行权限的控制,避免因权限控制缺失或操作不当引发的风险问题,如操作错误,隐私数据泄露等问题。目前在公司负责权限这块,... 查看详情

yii2权限控制rbac之rule详细讲解(转)

...会竹篮打水,这部分讲解的内容少之又少啊!对于一般的权限系统而言,我们之前做的rbac一般情况下是足够的,即时没有rule,相信你也能实现我们用rule实现的功能。我们就以官网的例子给出一个具体 查看详情

rbac权限控制

RBAC的控制,大致是通过将角色的权限控制,来控制用户的权限.需要构建的表为用户表(user),角色表(role),节点表(node),三张主表,节点表内记录的是所有的权限和方法.2张关联表,是为了关联3张数据表的,分别未角色用户表(user_role),角色... 查看详情

rbac基于角色的权限访问控制

多对多,用中间表  查看详情

基于rbac的权限控制浅析(结合springsecurity)

 嗯,昨天面试让讲我的项目,让我讲讲项目里权限控制那一块的,讲的很烂。所以整理一下。按照面试官的提问流程来讲:一、RBAC是个啥东西了?RBAC(Role-BasedAccessControl),即基于角色的访问控制模型,我的项目是基于RBAC0... 查看详情

简单的rbac用户角色权限控制

...目中,无论项目是大是小,或多或少都会涉及到用户访问权限的控制,权限管理总体的设计思路就是,不该看的不看,不该做的不做!据我目前的了解,我所知道的几种实现访问权限控制的方式有:JQuery的zTree设计权限树; ... 查看详情

rabc--权限控制解读

...AC(Role-BasedAccessControl)基于角色的访问控制。2、RBAC认为权限的过程可以抽象概括为:判断【Who是否可以对What进行How的访问操作(Operator)】这个逻辑表达式的值是否为True的求解过程。即将权限问题转换为Who、What、How的问题。w... 查看详情

rbac基于角色的权限控制组件目录

   权限组件之表设计 权限组件之录入数据 权限组件之获取登入用户的所有权限 权限组件之将登录用户权限写入到session中 session源码 权限组件之粒度到按钮级别1 权限组件之粒度到按钮级别2 ... 查看详情

rbac基于角色的访问控制

...ccessControl,基于角色的访问控制),就是用户通过角色与权限进行关联。简单地说,一个用户拥有若干角色,每一个角色拥有若干权限。这样,就构造成“用户-角色-权限”的授权模型。在这种模型中,用户与角色之间,角色与... 查看详情

rbac基于角色的访问控制

...ccessControl,基于角色的访问控制),就是用户通过角色与权限进行关联。简单地说,一个用户拥有若干角色,每一个角色拥有若干权限。这样,就构造成“用户-角色-权限”的授权模型。在这种模型中,用户与角色之间,角色与... 查看详情

springsecurity----rbac权限控制模型,和权限相关知识点整理(代码片段)

SpringSecurity----RBAC权限控制模型RBAC权限模型简介RBAC的演化进程用户与权限直接关联一个用户拥有一个角色一个用户一个或多个角色页面访问权限与操作权限数据权限动态加载用户角色权限数据UserDetails与UserDetailsService接口实现User... 查看详情

rbac模型整合数据权限(代码片段)

...部分数据。控制一个用户能访问哪些资源我们有很成熟的权限管理模型即RBAC,但是控制用户只能访问某部分资源(即我们常说的数据权限)使用RBAC模型是不够的,本文我们尝试在RBAC模型的基础上融入数据权限的... 查看详情

rbac:基于角色的权限访问控制(代码片段)

...RBAC96模型最具有代表,并得到了普遍的公认。RBAC认为权限授权的过程可以抽象地概括为:Who是否可以对What进行How的访问操作,并对这个逻辑表达式进行判断是否为True的求解过程,也即是将权限问题转换为What、How... 查看详情

rbac权限控制(代码片段)

1、什么是RBAC权限模型rity2、RBAC权限模型表设计3、整合Mybatis数据库4、UserDetailsService5、动态查询数据库登陆6、动态权限角色拦截  什么是RBAC权限模型r基于角色的权限访问控制(Role-BasedAccessControl)作为传统访问控制(自... 查看详情

rbac基于权限的访问控制

1.Role,RoleBinding的作用对象都是namespace。2.通过RoleRef,可以看到,RoleBinding对象通过名字,直接引用前面定义的Role,实现subject(user)和Role的绑定role--namespace--RoleBinding--mynamespace        &nbs 查看详情

权限设计系统——rbac

权限设计系统——RBAC​权限系统是针对与用户设计,不同的用户进入拥有不同的身份,而不同的身份则会导致他们能够使用到系统中的功能出现不同。这些功能即需要前端展示时的控制,也需要后端权限的校验。1.RBA... 查看详情

rbac基于角色的访问控制演示

...天理一理RBAC,话不多说,直接切入主题 功能需求:权限管理(无限极)角色管理(可以分配权限)管理员管理(管理员属于哪些角色)后台左侧显示当前登录用户所拥有的权限超级管理员拥有所有权限实现建表(我们需要... 查看详情

thinkphp中rbac权限控制求助

参考技术A权限配置文件://超级管理员'RBAC_SUPERADMIN'=>'admin',//超级管理名称'ADMIN_AUTH_KEY'=>'superadmin',//超级管理识别'USER_AUTH_ON'=>true,//开启验证'USER_AUTH_TYPE'=>1,//验证类型(1登录验证,2实时... 查看详情