RBAC权限管理模型:基本模型及角色模型解析及举例
站在巨人的肩膀上我们可以看得更远,而不是再造一个轮子。
我们在做任何一款产品的时候,或多或少都会涉及到用户和权限的问题。譬如,做企业类软件,不同部门、不同职位的人的权限是不同的;做论坛类产品的时候,版主和访客权限也是不一样的;再例如一款产品的收费用户和免费用户权限也是迥然不同的。
但在设计产品的用户和权限的关系的时候,很多产品经理可能按照感觉来,在并不清楚用户和权限是否存在优秀的理论模型的时候,就按照自我推理搭建了产品的用户和权限模型。而这种基于感觉和推理的模型肯定是有诸多问题的,譬如写死了关系导致权限不够灵活、考虑不周导致权限覆盖能力弱等等。
正如牛顿所言,站在巨人的肩膀上才能看的更远。我们不妨去参照已有的比较成熟的权限模型,如:RBAC(Role-Based Access Control)——基于角色的访问控制。我搜集了网上很多关于RBAC的资料,大多与如何用数据表实现RBCA相关,并不容易理解。所以,我会以产品经理的角度去解析RBAC模型,并分别举例如何运用这套已得到验证的成熟模型。
一、RBAC模型是什么?
RBAC是一套成熟的权限模型。在传统权限模型中,我们直接把权限赋予用户。而在RBAC中,增加了“角色”的概念,我们首先把权限赋予角色,再把角色赋予用户。这样,由于增加了角色,授权会更加灵活方便。在RBAC中,根据权限的复杂程度,又可分为RBAC0、RBAC1、RBAC2、RBAC3。其中,RBAC0是基础,RBAC1、RBAC2、RBAC3都是以RBAC0为基础的升级。我们可以根据自家产品权限的复杂程度,选取适合的权限模型。
二、基本模型RBAC0
解析:
RBAC0是基础,很多产品只需基于RBAC0就可以搭建权限模型了。在这个模型中,我们把权限赋予角色,再把角色赋予用户。用户和角色,角色和权限都是多对多的关系。用户拥有的权限等于他所有的角色持有权限之和。
举例:
譬如我们做一款企业管理产品,如果按传统权限模型,给每一个用户赋予权限则会非常麻烦,并且做不到批量修改用户权限。这时候,可以抽象出几个角色,譬如销售经理、财务经理、市场经理等,然后把权限分配给这些角色,再把角色赋予用户。这样无论是分配权限还是以后的修改权限,只需要修改用户和角色的关系,或角色和权限的关系即可,更加灵活方便。此外,如果一个用户有多个角色,譬如王先生既负责销售部也负责市场部,那么可以给王先生赋予两个角色,即销售经理+市场经理,这样他就拥有这两个角色的所有权限。
三、角色分层模型RBAC1
解析:
RBAC1建立在RBAC0基础之上,在角色中引入了继承的概念。简单理解就是,给角色可以分成几个等级,每个等级权限不同,从而实现更细粒度的权限管理。
举例:
基于之前RBAC0的例子,我们又发现一个公司的销售经理可能是分几个等级的,譬如除了销售经理,还有销售副经理,而销售副经理只有销售经理的部分权限。这时候,我们就可以采用RBAC1的分级模型,把销售经理这个角色分成多个等级,给销售副经理赋予较低的等级即可。
四、角色限制模型RBAC2
解析:
RBAC2同样建立在RBAC0基础之上,仅是对用户、角色和权限三者之间增加了一些限制。这些限制可以分成两类,即静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。具体限制如下图:
举例:
还是基于之前RBAC0的例子,我们又发现有些角色之间是需要互斥的,譬如给一个用户分配了销售经理的角色,就不能给他再赋予财务经理的角色了,否则他即可以录入合同又能自己审核合同;再譬如,有些公司对角色的升级十分看重,一个销售员要想升级到销售经理,必须先升级到销售主管,这时候就要采用先决条件限制了。
五、统一模型RBAC3
解析:
RBAC3是RBAC1和RBAC2的合集,所以RBAC3既有角色分层,也包括可以增加各种限制。
举例:
这个就不举例了,统一模型RBAC3可以解决上面三个例子的所有问题。当然,只有在系统对权限要求非常复杂时,才考虑使用此权限模型。
六、基于RBAC的延展——用户组
解析:
基于RBAC模型,还可以适当延展,使其更适合我们的产品。譬如增加用户组概念,直接给用户组分配角色,再把用户加入用户组。这样用户除了拥有自身的权限外,还拥有了所属用户组的所有权限。
举例:
譬如,我们可以把一个部门看成一个用户组,如销售部,财务部,再给这个部门直接赋予角色,使部门拥有部门权限,这样这个部门的所有用户都有了部门权限。用户组概念可以更方便的给群体用户授权,且不影响用户本来就拥有的角色权限。
七、最后的话
无论是本次的权限模型,还是其他产品相关实现方案,很多都已经被前人所总结提炼,我们应深度掌握这些成熟的知识和经验,而不是绞尽脑汁自我推理。还是文章开头那句话,站在巨人的肩膀上我们可以看得更远,而不是再造一个轮子。
作者:Monster,小满科技产品经理,公众号:PM怪物Monster
本文由 @Monster 原创发布于人人都是产品经理。未经许可,禁止转载。
用户组的举例,建议改成销售组织(或者省级业务中心)
之前所在的产品项目也是b端,有很多类似模块感觉应该是有经验积累下来的轮子的,但是又不知道去哪找,求教 😯
我已经很久没找轮子了。。一般是百度搜一下。。
学到了!!多了解轮子真的蛮重要的,请问作者平时是通过哪些渠道来了解到产品设计中的轮子的呢?
大神,想请教一下关于集团性公司部门组织架构建立,一个集团下包含总分子公司,如果总公司有一个体系,这个体系下既有总公司的部门a,又有分公司的部门b,在创建组织架构的时候,分公司那个部门b应该创建在分公司的架构下吗?
我考虑了这两种情况:
1.如果这个b部门创建在总公司下,可能从业务上来讲,负责这个体系的领导查看整个体系的数据没有问题,但是从职能上来讲,分公司财务需要能看到这个b部门的数据,但是架构设置在总部
2.如果b部门创建在分公司架构下,那负责这个体系的领导还要单独给他这只b部门的权限
如果有其他大神有解,欢迎探讨
不是大神,产品小白,根据你说的内容,个人认为一般情况是第二种情况符合;特殊情况为集团直属控制部门,例如总公司财务部门要特殊处理,培训部门特殊处理;
基于RBAC的延展——用户组.我们可以把一个部门看成一个用户组,如销售部,财务部,再给这个部门直接赋予角色,使部门拥有部门权限,这样这个部门的所有用户都有了部门权限。这个部门销售部、财务部所有人的权限都是一样的吗?
是的,先可以有简单的、共有的部门权限,然后部门职员还可以有自己岗位特殊的角色权限。
这个让我想到一个案例: 一个平台里面要管理多个店的管理员和类目商品管理,类目商品有多个以上的上级进行汇报工作(例如洗涤用品的要管理多个店的洗涤区域,饮料类的要管理多个店的饮料区域),同时要和单店管理员 和公司商品经理双线汇报公司,这样的的账号,角色,权限就用这个模型对应关联起来;
会员体系的搭建是不是也可以用这个模型?
会员体系好像不是后台系统的范畴
对于RBAC1,角色的等级不是确定的,需要用户自己去配置等级权限,这种该怎么设计呢
大神,我们的系统终于实现了这个巨人的理论了 ➡
恭喜你,理论是一回事,落地又是一回事,你能推动落地非常棒!
我的文章真是棒棒的鸭鸭鸭!!!!!!!!!!!!!!!
每看一字都收益良多,佩服大神,到这里瞬间出戏 ➡
哈哈哈哈哈哈哈哈哈哈哈哈
确实很棒,受益匪浅
关于权限的分配感谢指教,但是我还想请问你数据权限和功能权限如何区分?在配置功能权限时,有粗有细,大到功能模块,小到每一个页面的小按钮,那这种分法都在什么场景下使用呢?关于数据权限我现在还是没有想清楚怎么设计,麻烦大神指点一下
1、数据权限和功能权限分开配置;
2、场景太多了,按照你实际需求来;
3、数据权限类似,你和你老板都能使用组织架构功能,但是你只看到你团队的人,你老板看到全公司的人。组织架构算一个功能,需要赋予你和你老板,看到哪些人算数据权限,你看到的和你老板看到的范围就不一样了,也是需要设置的。
作者您好,就你所说的组织架构算一个功能,需要赋予你和你老板,看到哪些人算数据权限,你看到的和你老板看到的范围就不一样了,也是需要设置的。怎么设置呢?可以具体在举例说明吗?目前我也遇到数据范围权限的设置,还是不特别清楚。麻烦指点一下哦。非常感谢
在你数据本身做文章。例如你是销售部经理,老板是总经理。那么员工本身有归属于某个部门,此时数据权限可分为,1.你看到的是部门时销售部的所有员工。2.老板看到的是所有部门的员工。这样数据权限不就区分开了吗
是要把所有的人都要分组展示,然后做成可勾选吗?
比如,看到:我的订单,我所在部门下的订单,我所在部门及下级部门的订单,全部订单。。等等。
需要把职员分部门分负责人这样去设计,才能够进行数据的区分(区分的前提是用户跟数据本身是有关联的)
站在巨人的肩膀上我们可以看得更远……同意。
三克油~
你好,受教了,但个人对于“用户组”和“角色”之间的关系和应用场景还是有点模糊,盼举例指点一二,感激!
临时组建一个项目部,给项目部分配权限,但是每个人在自己原先的岗位上还有角色和岗位
举个例子,现在为公司的500名客服部门员工设置权限,这些员工的角色都属于“客服”,我如果每一个客服都去设置一下,为什么不创建一个客服组,给这个组匹配“客服”这个角色,之后就是往里面添加员工即可,效率是不是提高了;这还是只是一个角色的情况下,如果公司有一批相同岗位的员工都具有N种相同的角色,此时会不会觉得角色组更好用呢?
这个时候不是用部门麼,
还有就是用组的话,要报超级的用户添加到组里也是一件不少的工作量呵,对吧?
请问一般来说,一个用户会归属于多个用户组吗?
可以归属多个用户组
用户权限有RBAC……,有什么其他比较成熟的业务模式么?
棒棒棒!!!
求教RBAC3模型???
不教鸭!
非常棒,讲得深入浅出条理清晰。
谢谢哈~
目前只用到了RBAC0,保持最大的灵活度,没想到B端产品有这么多专业名词,感谢分享
感谢分享,非常受用
大多时候做的都是后台型产品,感觉有些隔阂,终于!发现了新世界的大门
谢谢哈,加油
又重新看了一篇,看懂了但是实际使用时怎么用呢?
我举了例子哈,也不是很清楚你具体场景,但是你可以理解逻辑后,自己针对具体业务梳理哈
RBAC1模型角色分等级,角色不同等级看成不同角色,是不是与RBAC0相同了,在实际使用中,与RBAC0有什么具体区别?
感谢分享~
不客气哈
看了几遍后终于看懂了,产品之路还得好好修炼 小白 😥
嗯嗯,加油
感谢分享~
不客气~
干货!正好对我现在遇到的问题很有帮助,感谢!
不客气哈,加油
用户组的概念从操作层面可以理解为用户的集合,从背后权限分配的层面可以理解为对于一组用户固定分配的一个角色,不知道可否这样去理解
可以这样理解,棒棒哒
那是不是相当于组里面的人有两个角色?只是不互斥?
最后的用户组,通常情况下是不是可以等同于通讯录的部门。因为大多数情况下,每个部门是有独特的权限的,比如市场部可以看报表,财务部可以看报销,人事部可以看请假…
你提到的这种场景可以用用户组满足哈,一般情况下的确可能按部门来设置用户组,然后给部门授权~棒棒哒
说的好
谢谢哈
如果一个用户组下面又分组长和组员,
q1:组长和组员的权限是不同的要怎么分
q2:组长可以创建组员(用户管理),但给组员分配权限既不能高于他自己,又和他自己有区别,这个时候就矛盾了,怎么细分
这里创建用户组的目的只是为了方便群体授权(该部门所有人都有的权限),权限并不能包含用户管理。而你说的分等级应该在角色划分时确定
站在巨人的肩膀上我们可以看得更远,而不是再造一个轮子
对!对!对!