文章从RBAC的基本原理出发，结合案例对权限设计中一个职位对应多个岗位的的情况进行了说明，并分享了相关权限模型，供大家一起参考和学习。
传统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的基本原理，就是将帐号和角色绑定，角色与资源权限绑定，来实现简单合理的权限控制。然后介绍了一个真实的“以岗定人”的组织架构，存在一个职位对应多个岗位，一人多岗的特点。最后给出了一个可实际操作的，包含如何设计带有组织和岗位的权限模型，供参考。
欢迎大家一起讨论。
本文由 @花生草 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
