权限体系设计:融合了组织和岗位的权限模型长啥样?
传统RBAC与现实的距离
传统的RBAC(基于角色的访问权限控制)是一个经典的权限管理模型,基本原理是不直接对系统种的用户赋权,而是通过角色作为系统用户和系统资源之间的中介,将资源权限绑定到角色,再将角色绑定到用户,来完成整个赋权的流程,从而简化赋权和修改权限的过程。(多扯一句,这个理念和计算机软件体系中,大家谈到的,当你觉得一个系统太复杂的时候,就给它加一个中间层的“秘笈”不谋而合,可见“世间万物皆有相通之理”)
上述的基础的RBAC(维基上命名为RBAC0)简单易懂,且容易落地。但是实际工作过程中,人们往往会在基础的RBAC上叠加更多特性,来满足现状的需要。比如从用人制度上,一般都会采取“以岗定人”的用人制度。在权限体系中,当人员调换岗位需要更新此人员的各种权限的时候,只需要更新人员对应的组织关系,那么角色权限会自动进行调整,从而减少了管理人员的工作量,也更符合常见的调岗操作方式。
因此,今天我们来讨论两个方面的问题
- 组织架构的特点
- 如何建立组织,岗位和账户的关联模型
先来了解一下组织架构的特点
01 组织架构的特点
组织一般是树形结构。在同一层的组织里面,有不同的职位,每个职位的权限都不一样。比如会计和出纳拥有不同的权限。
在不同职位之间,存在权限的重合。比如办公室主任除了拥有办公室职员的基础权限,主任还拥有更多的审批管理类权限。
同一个职位会对应多个岗位。同时还会存在一个人身兼多职也就是多个岗位的情况如下图所示,副总经理这一级组织对应的岗位上,有两人任职,赵子龙和赵德彪。同时赵子龙除了担任副总经理的岗位,还担任了总会计这一级组织里的负责人岗位。
02 组织,岗位,角色,帐号融合后的模型
以上面的组织架构为例,接下来会解密如何设计一个融合了组织和岗位的权限体系。
当然,在此之前需要我们对其一下术语。先来了解一下对每个名词的定义吧。
- 帐号:每一个真实的人,登录系统的场景,我们将这个真实的人用【帐号】来代表。
- 资源:系统中的每一个项,比如所有的菜单,所有的数据列表,所有的页面等。
- 角色:【角色】代表对资源的CRUD控制权限。
- 组织:图1所示就是一个组织架构
- 岗位:与人相对应,一个岗位只能对应一个人,但一人可以同时担任多个岗位。
- 职位:同一个类型的岗位,组成一个职位
一般不会直接将【帐号】与【资源】绑定,原因在前言中也说了,这种粒度过细,会让后期维护的时候非常复杂和耗时。为了方便赋权和后期的维护,可以将【职位】与【角色】绑定。同一个职位下的所有【岗位】拥有同样的角色。如下图所示。
说明:副总经理赵德彪,需要对应一个他自己的帐号。这个帐号只代表1个岗位,登陆后,系统检查这个帐号代表的是岗位C,岗位C在组织架构中的职位是职位B。接下来,系统发现这个职位B对应了4个角色,即角色2~5。每个角色都分别代表了不同的对资源操作的权限,职位B拥有的是这4个角色权限的总和。最终总结起来,赵德彪登陆后,拥有操作资源A,操作资源C和…资源…的权限。
另外一位副总经理赵子龙,需要对应一个他自己的帐号。这个帐号代表了2个岗位,按照上面的逻辑推断步骤,省略中间过程,最终总结起来就是,赵子龙登陆后,拥有查看资源A,操作资源B和操作资源C的权限。
03 总结
在这篇文章中,首先快速的过了一遍RBAC的基本原理,就是将帐号和角色绑定,角色与资源权限绑定,来实现简单合理的权限控制。然后介绍了一个真实的“以岗定人”的组织架构,存在一个职位对应多个岗位,一人多岗的特点。最后给出了一个可实际操作的,包含如何设计带有组织和岗位的权限模型,供参考。
欢迎大家一起讨论。
本文作者 @花生草 。
版权声明
本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!