Gin框架如何使用并搭建一个后台管理系统 RBAC 权限管理（六）

一、RBAC 实现流程

1 、实现角色的增、删、改、查

2 、实现用户的增、删、改、查，增加修改用户的时候需要选择角色

3 、实现权限的增、删、改、查 （页面菜单）

4 、实现角色授权功能

5 、判断当前登录的用户是否有访问菜单的权限

6 、根据当前登录账户的角色信息动态显示左侧菜单

二、用户 RBAC 权限管理树形图

1. 理想的RBAC模型

RBAC模型根据不同业务场景的需要会有很多种演变，实际工作中业务是非常复杂的，权限分配也是非常复杂的，想要做出通用且高效的模型很困难。我们把RBAC模型的演变汇总起来会是一个支撑大数据量以及复杂业务的理想的模型。把RBAC、RBAC1、RBAC2、用户组、组织、职位汇总起来的模型

理想的RBAC模型并不是说我们一开始建权限模型就可以这么做，而是数据体量、业务复杂度达到一定程度之后可以使用这个模型来解决权限的问题，如果数据量特别少，比如刚成立的公司只有十几个人，那完全可以用用户-权限模型，都没有必要使用RBAC模型。

2.标准RBAC模型

有了角色之后可以把权限分配给角色，需要相同权限的用户和角色对应起来就可以了，一个权限可以分配给多个角色，一个角色可以拥有多个权限，同样一个用户可以分配多个角色，一个角色也可以对应多个用户，对应模型如下所示：

这就是经典的RBAC模型了（role-based-access-control），在这里面角色起到了桥梁左右，连接了用户和权限的关系，每个角色可以拥有多个权限，每个用户可以分配多个角色，这样用户就拥有了多个角色的多个权限。

同时因为有角色作为媒介，大大降低了错综复杂的交互关系，比如一家有上万人的公司，角色可能只需要几百个就搞定了，因为很多用户需要的权限是一样的，分配一样的角色就可以了。这种模型的对应关系图如下所示：

用户和角色，角色和权限都是多对多的关系，这种模型是最通用的权限管理模型，节省了很大的权限维护成本， 但是实际的业务千变万化，权限管理的模型也需要根据不同的业务模型适当的调整，比如一个公司内部的组织架构是分层级的，层级越高权限越大，因为层级高的人不仅要拥有自己下属拥有的权限，二期还要有一些额外的权限。

RBAC模型可以给不同层级的人分配不同的角色，层级高的对应角色的权限就多，这样的处理方式可以解决问题，但是有没有更好的解决办法呢，答案肯定是有的，这就引出角色继承的RBAC模型。

以角色为学生、教师为例子，大致流程图如下：

 

4.权限模型

　主体（账号、密码）

　　　　资源（资源名称、访问地址）

　　　　权限（权限名称、资源id）

　　　　角色（角色名称）

　　　　角色和权限关系（角色id、权限id）

　　　　主体和角色关系（主体id、角色id）

 　　如图所示：