电商入门 (5):权限系统
随着使用者类型越来越丰富,导致权限系统必可不少。本文详细的跟大家说说,为什么会有权限系统?或者换个说法,为什么需要权限系统?
权限系统其实不只是应用于电商领域,各个领域都有可能用到。一旦公司系统做大,系统使用者的类型越来越丰富,权限系统就必不可少了。也就是说,小公司可能会没有权限系统,一般用一个admin账号供所有成员使用。
这里需要注意,我说的使用者类型越来越丰富,导致权限系统必可不少。很简单,假设一个系统只有一类使用者,这一类人必然有相同的使用权限,那就无所谓有没有权限系统了。
如果抽象一下,你可以看到:使用者 – 某一类使用者– 权限,如果某一类使用者唯一,我可以直接抽象为:使用者– 权限。这算是提前剧透,权限系统的经典模型:RBAC模型,即用户– 角色– 权限。上文就是将用户这个维度向上抽象出角色,某一类使用者对应一种角色。
看权限两个字,可以通俗的理解为权力限制,即不同的人由于拥有不同权力,他所看到的、能使用的可能不一样。对应到一个应用系统,其实就是一个用户可能拥有不同的数据权限(看到的)和操作权限(使用的)。或者大家可以把权限看成资源获取权,B/S结构里,你通过浏览器有没有向服务器请求某项资源的权力。
很多公司喜欢做用户白名单这种事,其实道理和权限系统一致,给白名单用户开方便之门,让他们访问非白名单用户访问不到的资源。总结来说就是,我需要通过权限决定谁可以访问我的资源。
另外,现在大部分文章没有把数据权限和操作权限说明白,我会试图在本文中讲明白这个问题。
更多的铺垫就不说了,全文将会以这个节奏进行:
- 权限系统的背景,从这一部分你会知道为什么需要诞生权限系统。
- 权限系统经典模型,这一部分我会简单介绍一下RBAC模型。
- 操作和数据权限,在这一部分,我会把大部分文章没有讲清楚的数据权限和操作权限讲明白。
- 权限系统实操,在这一部分我会简单说下做一个权限系统的底层逻辑,让你很快能”复制”一个权限系统。
二、权限系统的背景
为什么会有权限系统?或者换个说法,为什么需要权限系统?
正如前文说的,某些小公司不需要权限系统,原因也提到了使用者类型唯一,那么,是不是说当我使用者类型丰富的时候,我就需要考虑权限问题了呢?答案是肯定的!
权限系统起源是提供企业级应用软件解决方案的公司,如SAP、PeopleSoft等,也是这类公司最早开始探索高内聚低耦合系统。
举个可能不恰当的例子:当客户只想要WMS的时候,你说OMS和WMS不可分割,想买WMS就必须买OMS,显然是不合理的。
这和权限系统有什么关系呢?
OMS和WMS,一个是订单管理系统,一个是仓库管理系统。假设OMS的使用者是公司客服,WMS的使用者是公司仓库管理员。这里出现了两个系统,两类使用者,客服应该看到并使用WMS么?
最早的一批提供企业级应用软件服务的公司,也面临着同样的问题,随着客户公司的业务拓展,首先是客户公司对各子系统的需求量增大,可能不仅仅只需要一个HRMS,其次是对系统的使用安全、保密性,系统操作人员的权责关系界定上越来越严格,最后是B/S结构出现后带来的便捷性(需要注意的是这一点并不是初期探索权限系统的原因)。
关于这一点简单画了一个图来说明,如下:
从图中可以看出来,所有资源都统一存放在一处,当用户需要请求资源的时候,先经过资源表判断该用户是否有对应权限,如果有则返回结果。
没有B/S结构,一个软件服务公司可能需要为客户组装各种本地化的系统(如sys1和sys2打一个包,sys1单独打一个包,……),这就是B/S结构带来的便捷性,而权限系统在这中间起了至关重要的作用。
三、权限系统经典模型
需要先说明一点,在权限系统文章里强调RBAC模型,只是为了让大家对这个经典模型重视起来,再强调一下RBAC模型的基本结构:用户- 角色- 权限,却不仅限于此,更多细节需要大家亲自去摸索。
RBAC模型可以分为:RBAC 0、RBAC 1、RBAC 2、RBAC 3 四个阶段,一般公司使用RBAC0的模型就可以。另外,RBAC 0相当于底层逻辑,后三者都是在RBAC 0模型上的拔高。
我先简单介绍下这四个RBAC模型:
RBAC 0模型:用户和角色、角色和权限多对多关系。
简单来说就是一个用户拥有多个角色,一个角色可以被多个用户拥有,这是用户和角色的多对多关系;同样的,角色和权限也是如此。
RBAC 0模型如下图:没有画太多线,但是已经能够看出多对多关系。
RBAC 1模型:相对于RBAC 0模型,增加了角色分级的逻辑,类似于树形结构,下一节点继承上一节点的所有权限,如role1根节点下有role1.1和role1.2两个子节点。
角色分级的逻辑可以有效的规范角色创建(主要得益于权限继承逻辑),我之前做过BD工具(类CRM),BD之间就有分级(经理、主管、专员),如果采用RBAC 0模型做权限系统,我可能需要为经理、主管、专员分别创建一个角色(角色之间权限无继承性),极有可能出现一个问题,由于权限配置错误,主管拥有经理都没有权限。
而RBAC 1模型就很好解决了这个问题,创建完经理角色并配置好权限后,主管角色的权限继承经理角色的权限,并且支持针对性删减主管权限。
RBAC 1模型如下图:多对多关系仍旧没有改变,只增加角色分级逻辑。
RBAC 2模型:基于RBAC 0模型,对角色增加了更多约束条件。
如角色互斥,比较经典的案例是财务系统中出纳不得兼管稽核,那么在赋予财务系统操作人员角色时,同一个操作员不能同时拥有出纳和稽核两个角色。
如角色数量限制,例如:一个角色专门为公司CEO创建的,最后发现公司有10个人拥有CEO角色,一个公司有10个CEO?
这就是对角色数量的限制,它指的是有多少用户能拥有这个角色。
RBAC 2 模型主要是为了增加角色赋予的限制条件,这也符合权限系统的目标:权责明确,系统使用安全、保密。
RBAC 3模型:同样是基于RBAC0模型,但是综合了RBAC 1和RBAC 2的所有特点。这里就不在多描述,读者返回去看RBAC 1和RBAC 2模型的描述即可。
四、操作和数据权限
写在之前,这一部分,我主要是讲自己的理解,读者们需要辩证的去看这一部分。
用户在使用操作系统时能进行的增删改查我都归为操作权限,有很多人将增删改归为数据权限,因为这是在更改数据库某张表里的记录,必然是数据权限,真的是这样么?例如:商品中心里新增加一个商品,这到底是操作权限还是数据权限?
在我看来,凡是在操作系统中的任何动作、交互以及结果都是操作权限。那么,我说的数据权限是什么呢?
上文提到过我做的BD工具,再用这个例子:
先简单介绍我们的业务模式:BD专员负责拓展客户,BD主管直接管理推动专员作业,主管上级是经理,经理负责组织管理主管作业,这条业务线基本上如下图:
从上图很容易能看出来我说的数据权限是什么了,如果以客户作为最小数据单元往上看,你会发现:客户2.1.1和客户2.1.2只属于专员2.1,只属于主管2,再往上就是经理。
这个属于关系换另外一句话就是:我的客户只有我和我的直属上级以及直属上级的领导能看到,这也就是我说的数据权限。为什么这么说呢?
我们在作业过程中,销售数据是客户这个最小单元产生的,没有客户就没有销售数据,那么我的客户产生的销售数据谁可见呢?
这就是我说的数据权限。
简单说下,在实现数据权限时至少有两种方式:
- 一种上文提到了,利用RBAC 1模型,角色分级来实现,我们需要的就是角色分级带来的角色树,利用树形结构去控制数据输出。
- 另外一种方式,也就是我的实现方式,雷同于RBAC 1模型的角色树,我利用HRMS中的人事组织架构来实现数据输出,也即是打通HRMS系统和对应需要数据权限控制的系统,当涉及到数据输出时,会调用HRMS系统中的组织结构树,从而确定数据输出范围。当然我们在开发过程中,也可以直接把组织结构树置于权限系统之中,这种方式适用于组织架构相对固化的组织(如国企),但一般不建议这样做,系统的灵活配置、高可拓展性是开发想要的,也是产品需要考虑的。
这就是我理解的操作权限和数据权限,再次希望大家辩证的去看,自己多思考。
五、权限系统实操
到这一部分,我相信绝大部分产品同学已经有自己对权限系统的认知了,特别是看到RBAC模型后,做一个简单的权限系统应该没任何问题。
我说的实操的底层逻辑其实也是基于RBAC模型,再次强调下RBAC模型:用户– 角色– 权限。
那么,一个简单的权限系统应该具备哪几块呢?
首先考虑一个问题,用户从哪儿来?
很多权限系统直接在权限系统内创建一个用户,也可以打通HRMS系统,员工即用户,省去专门创建用户的一步。我想说的是后者,即打通HRMS系统。多说一句,这种设计一般需要在员工入职的时候为其选择相应角色。
用户已经有了,在这个前提下,就可以考虑其他问题了。
在RBAC模型下,给这样一个场景,创建一个角色,并为这个角色赋予相应权限,最后将角色赋予用户。那么,这个用户就拥有了该角色所拥有的权限。
抽象一下这个问题:开始》创建角色》为角色赋予权限》添加用户(调用HRMS)》将角色赋予用户》结束。
底层逻辑已经抽象出来了,那么该如何设计呢?
- 第一步,需要角色管理列表,在角色管理列表能快速创建一个角色;
- 第二步,角色管列表中能跳转至为角色配置权限的页面,也就是说有一个权限配置页;
- 第三步,需要有用户管理列表,在用户管理列表能快速添加一个用户,添加用户的这一页至少有让用户关联角色的功能。
简单来说权限系统设计至少有这三步,这样就完成了之前场景预定的全部内容,即:创建一个角色,并为这个角色赋予相应权限,最后将角色赋予用户。
到这里权限系统也算是讲完了,希望大家能喜欢,欢迎大家一起交流!
相关阅读
电商入门(4):如果我来负责搜狗云表情的搜索功能,会怎样去优化?
作者:QJQ,微信公众号:倔牛的人生
本文由 @QJQ 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自 Pixabay,基于 CC0 协议
终极模型:资源 ➡️ 权限 ➡️ 版本;版本 ➡️ 角色 ➡️ 权限;用户 ➡️ 角色 ➡️权限,好好想想
作者的归纳总结能力很强,做过类似的权限系统,感同身受
随着工作的深入,你会有不同的感受。关于权限系统,我又有了更进一步的认识。