B端平台权限体系设计:RBAC模型的技术实现逻辑
编辑导语:这篇文章基于B端平台的权限体系设计,细致地阐述了作者对于RBAC模型的理解,并向我们展示了RBAC模型的具体应用和逻辑实现过程。感兴趣的话就一起看一下吧。
在以往多个0~1大型数字中台项目中,底层权限体系是我最关心的,也要求产品经理和开发同学、尤其是后端开发必须熟悉后方可进入产品开发项目。
RBAC模型给了B端产品非常容易理解的权限方法,平台中也有很多RBAC相关的文章介绍。本篇重点介绍实际的技术实现过程,供大家参考,方便B端产品经理与开发同学的沟通,避免走弯路(曾经3个项目在此处折损颇多)。
一、权限体系的基础介绍
权限体系的要素有:业务组织、角色、用户和权限、页面、视图。
- 组织、角色、用户是基于业务变化可即时调整的。
- 权限是最底层属性,由开发人员基于业务需求开发实现。权限约束的对象是后台的具体实例。根据数据接口安全需要,可设计专用的接口权限。权限分功能权限(含菜单权限)、组织权限、数据权限。
- 页面、视图是系统按照业务配置、给对应用户呈现的内容。
详细的权限体系说明,可参考 《成熟CRM系统的权限体系解析》 一文。
二、对RBAC模型的深度理解
RBAC(基于角色的权限控制)模型的核心是在用户和权限之间引入了角色的概念。取消了用户和权限的直接关联,改为通过用户关联角色、角色关联权限的方法来间接地赋予用户权限(如下图),从而达到用户和权限解耦的目的。
RBAC模型强调了用户、角色、权限间的关系,但在B端业务应用中是不能脱离业务部门存在的,因此4者必须建立关系。除了以上4张表外,后台还需记录用户、业务部门、角色的关系表,如下图:
1. 成熟业务平台中对业务记录的基础要求
成熟ERP、CRM平台中权限体系非常严密,对业务记录有严格的要求:即单条业务记录中必须有业务记录的Owner和Owner所属的业务部门。因此,业务记录必须有7个基本字段:创建人、创建时间、最后修改人、最后修改时间、Owner、Owner所在的业务部门+状态(启用/停用),当Owner发生变化时,Owner所在的业务部门同步更新。
只有如此,才能保障组织权限的严格控制,其实现逻辑:按照当前用户所在的组织和角色的数据范围来从数据记录中的Owner所在的业务组织来获取的。加载可见数据后,再根据当前用户的编辑等权限进行前端的功能按钮控制。
举例:张三是销售经理,查询权限是看见部门所有销售顾问的客户数据,修改权限是个人的。在获取客户列表时,部分客户的修改按钮是高亮的(他个人的客户)、部分客户的修改按钮是置灰的(不是他的客户,是其他销售顾问的)。上图中,客户数据在线索中心中,其他业务中心的业务数据类似处理。
2. 权限体系如何配置和逻辑实现的呢?
权限配置属于基础设置部分,一般由超管用户设定不同角色的权限,示例:
这样的权限配置实际上需要前后端约定的,采用统一的权限码来协同控制,使用excel表等其他方式约定菜单/功能权限、数据权限和对应的权限代码。示例:
留3个需要大家思考的问题:
- 组织权限是个人级、全部和本部、本部及以下的处理方式一样吗?
- 如果一个人拥有多个角色、且不同角色的组织权限的级别不同,怎么处理?
- 有功能权限就一定可以处理业务记录吗?
三、更复杂应用:房产销售中的业务组织+项目组织
在房产销售业务中,会有业务组织,也会有项目组织及项目相关的业务数据,如:一个楼盘就是一个项目,这个项目上产生的线索归属于项目,客户归属于整个体系,发展的渠道公司也是归属于整个体系。
业务人员会在充当不同业务角色和项目角色,复杂的如一个人同时在多个业务组织中、多个项目组织中,比如张三在BJ城市小区中任项目助理(拥有整个小区中的线索数据查看权限),同时在A项目任销售一组经理,B项目(非BJ城市小区)中任销售二组的案场顾问。此用户在点击线索列表时(项目外),看到的是BJ城市组织下的线索+A项目销售一组的线索数据+B项目中归属自己的线索。
这样的结果,就需要业务记录中既要有业务组织ID、还要有项目组织ID。
四、扩展知识:各类平台中的组织
- 行政组织:HR、OA等使用的行政组织,组织架构清晰。
- 财务组织:财务预决算使用的组织,比如行政组织中有1~5级,但在财务体系内直到3级,那4、5级组织对应的财务组织就是3级。
- 业务组织:业务运营的组织架构,与行政、财务组织类似,但会不同。举例:董事长下CEO、CEO下CMO+CFO,但业务系统中会将董事长、CEO、CMO、CFO均放在公司顶级组织里,甚至财务会计、BP均会放在公司这层。
- 虚拟组织:常用于区域管理组织或职能组织,比如与华南大区平行的华南虚拟组织中,会有财务、HR等职能共享组织,也会有负责市场物料集中采购的采购专员等。同一个财务会监管2个大区,即在2个大区虚拟组织中,数据范围是按照平行的华南大区业务组织的权限。
作者:王建儒,MBA,科技公司CPO,18年业务运营、运营平台规划与建设经验。微信公众号:王建儒的B星球
本文由 @王建儒 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议
专栏作家
王建儒,微信公众号:王建儒的B星球,人人都是产品经理专栏作家。18年业务运营、运营平台规划与建设经验,熟悉S2B2C业务模式的业务+数字双中台规划和落地,聚焦汽车、房产等行业的营/销/服/客户运营与数字转型。甲方IT负责人、乙方业务专家/产品团队负责人。
本文原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。
订阅了
厉害!
受教
1.组织权限是个人级、全部和本部、本部及以下的处理方式一样吗?
答:【不确定】处理方式是指?
2.如果一个人拥有多个角色、且不同角色的组织权限的级别不同,怎么处理?
答:会拥有所有角色的权限之和。
3.有功能权限就一定可以处理业务记录吗?
答:不一定,还要判断是否有组织权限、数据权限。
第二个问题,如果两个角色互斥,是否需要考虑让用户只能选择一个角色?
是的,这是必须的。比如出纳和会计就不可以为同一人。
1-处理方式不同:1)个人级权限,直接找owner;2)全部:直接给所有数据;3)本部:给owner所在组织的ID、用此ID返回记录中有此ID的数据;4)本部及以下:owner所在组织的ID及以下所有组织的组织ID,用这些ID返回记录中有这些ID的数据。
2-从数据查看角度,取最高级别的权限;但部分业务数据敏感,就会取最小级别的权限。避免因角色权限配置错误,而造成数据泄露。
3-一般的有组织和数据权限才会涉及到功能权限,即先看到了数据记录,才可以修改、删除。而且功能权限用户中心都会同步给业务中心的。这里想强调的是业务逻辑控制,如订单状态对功能权限的影响,举例:订单关闭后,只有查看按钮、归档按钮,其他按钮全部置灰。
超赞,收获很大
赞