B端产品之权限设计(RBAC权限模型)

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了B端产品之权限设计(RBAC权限模型)相关的知识,希望对你有一定的参考价值。

参考技术A 一、前言

随着互联网的快速发展,B端行业也逐渐崛起,很多企业管理中使用的软件我们通常称其为B端管理系统,而在B端系统中“权限管理”是必不可少的功能,不同的系统中权限的应用复杂程度不一样,都是根据实际产品以及需求情况而设置合理的权限。而我们现在对于权限的设置基本上都是建立在RBAC权限模型上的、扩展的,下面我会通过介绍RBAC权限模型的概念以及结合实际业务情况列举权限设置的应用。

二、什么是RBAC权限模型?

RBAC是Role-BasedAccess Control的英文缩写,意思是基于角色的访问控制。RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中,who、what、how构成了访问权限三元组,也就是“Who对What进行How的操作,也就是“主体”对“客体”的操作。其中who是权限的拥有者或主体(例如:User、Role),what是资源或对象(Resource、Class)。

简单的理解其理念就是将“角色”这个概念赋予用户,在系统中用户与权限之间通过角色进行关联,以这样的方法来实现灵活配置。

RBAC其实是一种分析模型,主要分为:基本模型RBAC0、角色分层模型RBAC1、角色限制模型RBAC2和统一模型RBAC3。

RBAC权限模型是基于角色的权限控制。模型中有几个关键的术语:

用户:系统接口及访问的操作者

权限:能够访问某接口或者做某操作的授权资格

角色:具有一类相同操作权限的用户的总称

1)RBAC0

RBAC0是RBAC权限模型的核心思想,RBAC1、RBAC2、RBAC3都是在RBAC0上进行扩展的。RBAC0是由四部分构成:用户、角色、会话、许可。用户和角色的含义很简单,通过字面意思即可明白,会话:指用户被赋予角色的过程,称之为会话或者是说激活角色;许可: 就是角色拥有的权限(操作和和被控制的对象),简单的说就是用户可使用的功能或者可查看的数据。

用户与角色是多对多的关系,用户与会话是一对一的关系,会话与角色是一对多的关系,角色与许可是多对多的关系。

2)RBAC1

RBAC1是在RBAC0权限模型的基础上,在角色中加入了继承的概念,添加了继承发的概念后,角色就有了上下级或者等级关系。

举例:集团权责清单下包含的角色有:系统管理员、总部权责管理员、区域权责管理员、普通用户,当管理方式向下兼容时,就可以采用RBAC1的继承关系来实现权限的设置。上层角色拥有下层的所有角色的权限,且上层角色可拥有额外的权限

3)RBAC2

RBAC2是在RBAC0权限模型的基础上,在用户和角色以及会话和角色之间分别加入了约束的概念(职责分离),职责分离指的是同一个人不能拥有两种特定的权限(例如财务部的纳入和支出,或者运动员和裁判员等等)。

用户和角色的约束有以下几种形式:

互斥角色:同一个用户在两个互斥角色中只能选择一个(也会存在一个用户拥有多个角色情况,但是需要通过切换用户角色来实现对不同业务操作)

基数约束:一个用户拥有的角色是有限的,一个角色拥有的许可也是有限的

先决条件约束:用户想要获得高级角色,首先必须拥有低级角色

会话和角色之间的约束,可以动态的约束用户拥有的角色,例如一个用户可以拥有两个角色,但是运行时只能激活一个角色。

例如:iconfont和蓝湖的用户与角色就采用了约束的概念,超级管理员只允许只有一个

4)RBAC3

RBAC3是RBAC1与RBAC2的合集,所以RBAC3包含继承和约束。

二、为什么要引用RBAC权限模型?

RBAC中具有角色的概念,如果没有角色这个概念,那么在系统中,每个用户都需要单独设置权限,而系统中所涉及到的功能权限和数据权限都非常多,每个用户都单独设置权限对于维护权限的管理员来说无疑是一件繁琐且工作量巨大的任务。

而引入角色这个概念后,我们只需要给系统设置不同的角色, 给角色赋予权限,再将用户与角色关联,这样用户所关联的角色就直接拥有了该角色下的所有权限。

例如:用户1~用户8分别拥有以下权限,,不同用户具有相同权限的我用不同的颜色做了区分,如下图:

在没有引入RBAC权限模型的情况下,用户与权限的关系图可采用下图的杨叔叔展示,每个用户分别设置对应的权限,即便是具有相同权限的用户也需要多次设置权限。

引入RBAC权限模型及引入了角色的概念,根据上面表格的统计,用户1、用户3、用户5、用户8拥有的权限相同,用户2、用户6、用户7拥有相同的权限,用户4是独立的权限,所以我们这里可以根据数据统计,以及实际的需求情况,可以建立三个不同的角色,角色A、角色B、角色C,三个角色分别对应三组用户不同的权限,如下图所示:

对应的上面的案例表格我们就可以调整为含有角色列的数据表,这样便可以清楚的知道每个用户所对应的角色及权限。

通过引用RBAC权限模型后,对于系统中大量的用户的权限设置可以更好的建立管理,角色的引入让具有相同权限的用户可以统一关联到相同的的角色中,这样只需要在系统中设置一次角色的权限,后续的用户便可以直接关联这些角色,这样就省去了重复设置权限的过程,对于大型平台的应用上,用户的数量成千上万,这样就可避免在设置权限这项工作上浪费大量的时间。

三、引入用户组的概念

我们依旧拿上面表格案例举例,虽然前面我们应用的RBAC权限模型的概念,但是对于大量用户拥有相同权限的用户,我们同样的也需要对每个用户设置对应的角色,如果一个部门上万人,那么我们就需要给这个部门上万人分别设置角色,而这上万其实是具有相同的权限的,如果直接采用基础的RBAC权限模型的话,那么面对这样的情况,无疑也是具有一个庞大的重复的工作量,并且也不利于后期用户变更的维护管理,那么针对相同用户具有相同的权限的情况,我们便可以引入用户组的概念。

什么是用户组呢? 用户组:把具有相同角色的用户进行分类。

上面我们的数据表格案例中的用户1、用户3、用户5、用户8具有相同的角色A,用户2、用户6、用户7也拥有相同的角色B,那么我们就可以将这些具有相同角色的用户建立用户组的关系,拿上面的案例,我们分别对相同角色的用户建立组关系,如下:

用户1、用户3、用户5、用户8→建立用户组1

用户2、用户6、用户7→建立用户组2

因为用户4只有一个用户,所以直接还是单独建立用户与角色的关系,不需要建立用户组,当然尽管只有一个用户也是可以建立用户组的关系,这样有利于后期其他用户与用于4具有相同的角色时,就可以直接将其他用户添加到这个用户组下即可,根据业务的实际情况而选择适合的方案即可。

通过案例表格的变化我们就可以直观的看出权限设置变得清晰简洁了,通过第用户组赋予角色,可以减少大量的重复的工作,我们常见的企业组织、部门下经常会出现不同用户具有相同角色的情况,所以采用用户组的方式,便可以很好的解决这个问题,给具有相同权限的用户建立用户组,将用户组关联到对应的角色下,此用户组就拥有了此角色下的所有权限,而用户是属于用户组的,所以用户组下的所有用户也就同样的拥有了此角色下的所有权限。一个用户可以属于多个用户组,一个用户组也可以包括多个用户,所以用户与用户组是多对多的关系。

四、引入权限组的概念

权限组与用户组的原理差不多,是将一些相对固定的功能或者权限建立组的关系,然后再给此权限组赋予角色,目前我所接触的B端项目中使用权限组的概念的比较少,可简单的看一下关系图

四、功能权限和数据权限

B端系统中一般产品的权限由页面、操作和数据构成。页面与操作相互关联,必须拥有页面权限,才能分配该页面下对应的操作权限,数据可被增删改查。所以将权限管理分为 功能权限管理和数据权限管理。

功能权限管理:指的是用户可看到那些模块,能操作那些按钮,因为企业中的用户拥有不同的角色,拥有的职责也是不同的。

数据权限管理:指的是用户可看到哪些模块的哪些数据。

例如:一个系统中包含多个权责清单(清单1、清单2、清单3),系统管理员能对整个系统操作维护。。。。。

完整内容请查看公众号原文链接

原文链接:B端产品之权限设计(RBAC权限模型)

来源公众号《设计小余》

后台基于RBAC模型的用户与权限设计

加关注,带你看世界

本文作者结合实际经验,跟大家谈谈后台基于RBAC模型的用户与权限是如何设计的,一起来看看~

后台基于RBAC模型的用户与权限设计

一、项目背景

1.1 需求来源

前段时间,笔者所在公司收到了多个客户对后台权限和角色的需求。讨论发现,现有的产品后台架构并不能很好的满足用户需求,所以为了满足这些客户的需求并为之后可能存在的业务拓展打下基础,我们决定对现有产品的后台用户体系进行迭代。

1.2 需求的拆解

通过过滤需求,我们发现其实用户的需求主要是两类:

  • 是要求我们的用户体系可以承载用户多级分销的业务模式并满足各级分销之间数据权限的要求;

  • 是要求我们完善对用户权限的控制。

后台基于RBAC模型的用户与权限设计

二、理论依据

涉及到后台用户管理系统,绕不开的概念就是权限,任何一个账号都会有自己的用例。但是多数情况下,我们对部分账号的用例会做一些限制,如果直接将这种限制加在账号上,就会产生二个问题:

  • 每个账号都要配置很麻烦;

  • 无法批量修改一类用户的权限。

所以角色的诞生就呼之欲出了,我们通过对权限集的抽象,创立了角色,通过修改角色,来达到控制拥有该角色的账号的权限修改的目的。

权限可以分为数据权限和功能权限两大类:

  • 数据权限顾名思义,就是账号能查看多少数据,如何实现A部门与B部门之间相互不能查看业务数据,这个就涉及到数据权限;

  • 功能权限按照范围以大致菜单权限和按钮权限,按照操作可以大致分为查看和编辑权限。

2.1 RBAC-0模型

2.1.1 简述

RBAC-0 模型的特点就是用户和角色是多对多的关系,同一个用户拥有多个角色的属性,我们通过组织这个概念来构建组织架构,从而实现对角色数据权限的分配。这样单个用户账号拥有的全部权限就是他所在组织的权限的累加。

后台基于RBAC模型的用户与权限设计

2.1.2 举例

在RBAC-0模型中,A用户负责X组织的业务,B用户负责Y组织的财务工作。正常情况下,A和B自然不能查看对方的数据,但是如果有天,B由于业务需要需要协助处理X组织的财务,那我们就可以通过为B用户添加X组织的“财务”角色来实现这种需求。在业务结束后,也可以通过暂停/删除操作来管理B在X组织下的权限。

2.2 RBAC-1模型

基于RBAC-0模型,针对角色引人继承的概念,子角色可以对父角色的权限进行继承,但是子角色的权限一定小于父角色。

后台基于RBAC模型的用户与权限设计

2.3 RBAC-2模型

相较RBAC-0系统,RBAC-2系统在用户与角色间和角色与角色之间加入了一些规则。

后台基于RBAC模型的用户与权限设计

  • 单个角色允许分配的用户数限制,例如一个公司不可能有多无限个“董事会”角色;

  • 单个用户允许授予的角色数限制,例如单个用户不允许在一个公组织或多个组织担任无限多个职务;

  • 角色与角色有层级关系,例如想新增一个部门经理,不能用一个部门职员的账号去创建吧?

  • 角色与角色存在互斥关系,这个根据实际业务需要来做限制,例如销售不能兼任会计。

2.4 RBAC-3模型

RBAC-3模型也叫统一模型,它基于了RBAC-0,并包含了RBAC-1和RBAC-2模型的全部特点。

后台基于RBAC模型的用户与权限设计

三、设计过程

3.1 新增账号的属性

新增账号是用户体系的最基本的功能,新增账号时需要获取账号的哪些参数决定了整个用户体系的数据维度。

后台基于RBAC模型的用户与权限设计

这里不得不提的就是USER_ID,登录账号,昵称的概念。

USER_ID:对应的是账号在系统中唯一标识,可以不展示给用户,例如微信的open_id和union_id,一般在新增账号时由系统生成,且不可修改;

昵称:昵称是用户可以自由编辑操作的,由用户输入,且允许修改。

3.2 功能权限的处理方式

功能权限通过对角色的权限树进行修改来实现。在权限树种我们可以将页面权限,菜单权限和按钮权限罗列,通过筛选对应权限完成对角色功能权限的控制。

后台基于RBAC模型的用户与权限设计

需要注意的一个问题是,权限控制的最小粒度。如果要实现每一个权限的控制,相当于每一个权限对应功能都需要做封装。大的页面和菜单权限是必备的,但是哪些按钮权限是可以封装在一起的,(比如“启用”和“暂停”一般都是成对出现的),这些是需要产品考虑的。

3.3 数据权限的处理方式

数据权限其实是角色权限的重要属性,但是由于数据范围太灵活,如果在角色加入“数据权限”tab,如果账号下的数据量较大,用户编辑数据权限的操作会很繁琐。因此,因此现在主流的后台设计都会使用“组织结构”来对应数据权限。

后台基于RBAC模型的用户与权限设计

在系统中,我们使用了【新增组织】的方式,来处理数据权限。

3.4 对老用户的兼容

在做用户体系的重构时,老用户的账号兼容问题是产品必须考虑的部分。兼容问题也是从功能和数据两个维度去验证新的体系是否对老用户是否有影响。

后台基于RBAC模型的用户与权限设计

四、总结

文章的内容主要是本次迭代中实际的使用场景,抱着他山之石可以攻玉的想法,参考了现有的资料,结合自己系统的实际情况,对用户体系设计做了一次小结。若有不足之处,还请大家多多沟通,共同进步。

#声明#


以上是关于B端产品之权限设计(RBAC权限模型)的主要内容,如果未能解决你的问题,请参考以下文章

后台产品基本功:RBAC权限后台角色与权限设计

用户权限系统设计与RBAC模型

后台基于RBAC模型的用户与权限设计

后台设计的基石:用户权限管理(RBAC)及工作流(workflow)模型(转自人人都是产品经理)

基于RBAC权限控制模型的管理系统的设计与实现

基于RBAC权限控制模型的管理系统的设计与实现