传统RBAC与现实的距离
传统的RBAC（基于角色的访问控制）是一种经典的权限管理模型。 基本原则不是直接对系统的用户进行授权，而是利用角色作为系统用户和系统资源之间的中介，传递资源权限。 绑定到角色，再将角色绑定到用户就完成了整个授权过程，从而简化了授权和修改权限的过程。 （还有一点，这个概念和大家谈论的计算机软件系统不谋而合，当你觉得一个系统太复杂的时候，就给它加上一个中间层，这个“秘密”与之不谋而合，可见“一切都在世界有“同理”）
上述基本的RBAC（Wiki上称为RBAC0）简单易懂，易于实现。 但在实际工作过程中，人们往往会在基本的RBAC上叠加更多的功能来满足当前情况的需要。 例如，在用人制度上，普遍采用“按岗任人”的用人制度。 在权限系统中，当一个人变动职位，需要更新此人的各种权限时，只需要更新该人对应的组织关系，角色权限就会自动调整，从而减少了管理者和管理人员的工作量。使其更符合惯例。 岗位调动的操作方法。
所以今天我们就从两个方面来讨论这个问题
组织结构的特点：如何建立组织、岗位、账户的关联模型
我们先来了解一下组织结构的特点
01 组织架构特点
组织通常具有树形结构。 同一级别的组织内，有不同的职位，每个职位都有不同的权限。 例如3D道具，会计和出纳有不同的权限。
不同职位之间的权力存在重叠。 例如3D素材，办公室主任除了办公室人员的基本权限外，还拥有更多的审批和管理权限。
同一位置可能对应多个位置。 同时，也会出现一个人担任多个职位，即多个职位的情况。 如下图所示，副总经理级组织中有两人担任相应职务，分别是赵子龙和赵德彪。 同时，赵子龙除担任副总经理外，还担任总会计师级机构负责人职务。
02 组织、职位、角色、账户整合后的模型
以上述组织架构为例，我们来解密如何设计一个组织与岗位融为一体的权限体系。
当然，在此之前我们需要先理清术语。 我们先来了解一下各个名词的定义。
一般情况下，【账户】和【资源】不直接绑定。 前言中也提到了原因。 这种粒度太细，会让后期维护变得非常复杂、耗时。 为了方便赋能和后期维护，【职位】可以绑定【角色】。 同一职位下的所有【职位】具有相同的作用。 如下所示。
注：赵德彪副总经理需对应本人账号。 该账户仅代表一个仓位。 登录后，系统检查该账号代表职位C，职位C在组织结构中的职位为职位B。接下来，系统发现职位B对应4个角色，即角色2至角色5。每个角色代表不同的资源操作权限。 职位B拥有这四个角色的权限之和。 综上所述，登录后，赵德彪拥有对资源A、资源C以及……资源……的操作权限。
另一位副总经理赵子龙则需要对应自己的账号。 该账户代表两个头寸。 遵循上述逻辑推理步骤，省略中间过程。 最后总结就是，赵子龙登录后系统角色权限管理设计，拥有查看资源A、操作资源B、操作资源C的权限。
03 总结
在这篇文章中，我们首先快速回顾一下RBAC的基本原理系统角色权限管理设计，即绑定账户和角色，绑定角色和资源权限，实现简单合理的权限控制。 随后他介绍了一种真实的“以岗定人”的组织架构，一个岗位对应多个岗位，一个人多个岗位。 最后给出了一个实际操作，包括如何设计具有组织和职位的权限模型，以供参考。
欢迎大家一起讨论。
