做B端产品,权限是无法躲过的一类问题?

做B端产品,权限是无法躲过的一类问题?

做B端产品,权限是无法躲过的一类问题。比如,企业类软件,不同部门、不同职位的人的权限是不同的;再例如,一款软件,不同付费层级的用户,所使用的权限也是迥然不同的。

一、权限

1.什么是权限

权限是基于实际业务的需要,设计的一套系统使用关系。没有固定的方法,每个公司可能都是不一样的。权限分为:页面权限、操作权限、数据权限。

页面权限:谁可以访问页面。例如,财务可以访问财务报表,而销售不可访问财务报表页面;

操作权限:谁可以操作数据。例如:老板和财务都可以访问财务报表,但是财务可以增删查改,但是老板只能看,不可以改;

数据权限:谁可以看哪个范围的数据。例如:销售一分部的老板只能看销售一分部的数据,公司的老板可以看整个公司的数据;

2.遇到的问题

网上很多关于RBAC的资料,大多与如何用数据表实现RBCA相关游戏动态,并不容易理解。很多人看了很多文章来描述权限、RBAC等等,看了很多rbac角色权限表设计,还是搞不清楚权限和RBAC的关系;或者看了RBAC也不知道如何去使用;在实际设计中,往往根据自我感觉就搭建了用户和权限模型。自己想的模型可能会导致很多问题,例如权限管理不够灵活,权限覆盖能力弱,甚至操作混乱等。

3.解决方法

实际上,已经有成熟的RBAC模型可直接应用于权限设计,我们无需自己拍脑袋设置用户权限模型,正如牛顿所言,站在巨人的肩膀上才能看的更远。我们不妨去参照已有的比较成熟的权限模型RBAC(Role-Based Access Control)——基于角色的访问控制。我会以产品经理的角度去解析RBAC模型,并分别举例如何运用这套已得到验证的成熟模型。

二、RBAC模型

1.传统权限模型

在没有RBAC前,传统权限模型通过账号直接配置权限。每一个账号都需要勾选账号对应的每一个权限,如下图。可见非常繁琐,维护起来非常麻烦。

2.RBAC概念

RBAC增加了“角色”的概念,我们首先把权限赋予角色,再把角色赋予用户。这样,由于增加了角色,授权会更加灵活方便。在RBAC中,根据权限的复杂程度,又可分为RBAC0、RBAC1、RBAC2、RBAC3,RBAC4。其中,RBAC0是基础,RBAC1、RBAC2、RBAC3、RBAC4都是以RBAC0为基础的升级。我们可以根据自家产品权限的复杂程度,选取适合的权限模型。

3.RBAC0:基本模型

解析:RBAC0是RBAC模型中最基本的模型,很多产品只需基于RBAC0就可以搭建权限模型了。用户与角色可为多对一或多对多的关系,当一个用户的角色为多对多时,当前用户的权限是多个角色的并集。

举例:譬如我们做一款企业管理产品,如果按传统权限模型,给每一个用户赋予权限则会非常麻烦,并且做不到批量修改用户权限。这时候,可以抽象出几个角色,譬如销售经理、财务经理、市场经理等,然后把权限分配给这些角色,再把角色赋予用户。这样无论是分配权限还是以后的修改权限,只需要修改用户和角色的关系,或角色和权限的关系即可,更加灵活方便。此外,如果一个用户有多个角色,譬如王先生既负责销售部也负责市场部,那么可以给王先生赋予两个角色,即销售经理+市场经理,这样他就拥有这两个角色的所有权限。

4.RABC1:用户组/权限组模型

解析:在RABC0的基础上,加入了用户组的概念。账号既可以通过角色来配置权限,也可以通过用户组来配置权限。这样做的好处是,若存在多个角色具有统一的权限,无需对每一个角色的共同权限进行配置。仅需将共同权限配置在用户组,使账号归属于用户组即可;(此级别,也可同时存在权限组,类似于用户组,这里就不细讲了)

一个账号可以既存在用户组也存在角色,权限范围为其的并集;

举例:会计、出纳、公司老板均可以查看公司的财务报表,但是操作不同,会计审核,出纳付款,老板仅查看;此时只需要抽象出一个报表查看用户组,用户组配置所需查看的报表,再将会计、出纳、公司老板都加入用户组;这样,加入用户组的用户都可以查看报表;再将会计和出纳角色配置单独的操作权限,一并赋予,这样会计和出纳就既拥有了用户组的权限(可查看报表)3D角色,以及独特的操作权限(审核/付款)

5.RBAC2:角色继承模型

解析:角色继承,讲一个角色分为多个级别,高级别的角色可继承低级别角色的权限,上层角色继承下层角色的全部权限,且可额外赋予权限。

举例:

基于之前RBAC0的例子,我们又发现一个公司的财务经理可能是分三个等级的,财务经理、财务组长、财务员工。财务组长只有财务经理的部分权限。这时候,我们就可以采用RBAC1的分级模型,把财务这个角色分成多个等级,给财务组长赋予较低的等级即可。

6.RBAC3:角色限制模型

解析:角色限制的RBAC模型,指的是当用户可以存在多个角色时,多个角色质检存在限制条件。例如,一个人不能既是裁判rbac角色权限表设计,又是运动员;这些限制可以分成两类,即静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。

举例:

基于之前RBAC0的例子,我们又发现有些角色之间是需要互斥的,譬如给一个用户分配了财务经理的角色,就不能给他再赋予审计经理的角色了,否则他即可以录入账单又能自己审核账单;再譬如,有些公司对角色的升级十分看重,一个财务员工要想升级到财务经理,必须先升级到财务主管,这时候就要采用先决条件限制了。

7.RBAC4:统一模型

RBAC4是RBAC2和RBAC3的合集,所以RBAC3既有角色分层,也包括可以增加各种限制。

举例:

这个就不举例了,统一模型RBAC3可以解决上面三个例子的所有问题。当然,只有在系统对权限要求非常复杂时,才考虑使用此权限模型。

8.扩展案例

①公司架构如图,共有三种职能:前沿销售、前台、销售、老板,各职能角色分别如上图。前沿销售需要查看和操作客户列表、订单列表,销售需要查看和操作客户列表、订单列表,前台需要查看和操作客户列表,老板需查看所有的页面,但不可操作。

②权限说明:

1.页面权限:前沿销售——客户列表、订单列表;销售员工——客户列表、订单列表;销售主管——客户列表、订单列表、销售报表;前台——客户列表;老板——所有页面;

2.操作权限:前沿销售——客户列表(新增、删除)、订单列表(新增);销售员工——客户列表(新增、删除)、订单列表(新增);销售主管——客户列表(新增、删除)、订单列表(新增)、销售报表(导出);前台——客户列表(新增);老板——所有页面(无);

3.数据权限:前沿销售——客户列表(本人)、订单列表(本人);销售员工——客户列表(本人)、订单列表(本人);销售主管——客户列表(本人及本人下属)、订单列表(本人及本人下属)、销售报表(本人及本人下属);前台——客户列表(本人);老板——所有页面(全部);

③运用RBAC0

1.页面&操作权限:新建角色,勾选对应的页面以及操作

2.数据权限:新建数据权限,勾选对应查看数据的范围

但此时不要忘记,系统当前对账号之间的关系并不清楚,也就是系统并不知道账号的上下级关系;所以数据权限还需要搭配部门上下级的功能。

这样系统就知道,账号所处的部门,也就可以配置销售主管查看下属的数据了,如下;

此时,该账号已具备,1.查看本人及下属的数据权限 2.查看客户列表、操作客户列表的功能

9.最后的话

无论是本次的权限模型,还是其他产品相关实现方案,很多都已经被前人所总结提炼,我们应深度掌握这些成熟的知识和经验,而不是绞尽脑汁自我推理。我们只需要使用轮子,不需要自己创造轮子。(本文部分借鉴其他文章,如有雷同,是我抄你【偷懒了,还请谅解】)

文章来源:https://www.jianshu.com/p/7fdd4b6bdbd9