近期的项目中有涉及到后台管理系统权限模块的设计，考虑把一些零碎的实践记录下来，作为一部分学习过程。主流的权限设计思路主要有两种：RBAC 和 ACL.

一、RBAC

RBAC 即 Role Basic Access Control （基于角色的权限控制），主要的思想是通过自定义的不同角色来控制权限，不同的用户可以拥有不同的角色，单个用户可以同时拥有多个角色。当系统需要获取某个用户的权限时，需要先确定该用户所拥有的所有角色，在依据角色包含的权限来确定该用户最终拥有的权限清单。

二、实现

RBAC 的实现通常需要依赖下面这些数据表：

• 用户信息表（users）：记录系统中的所有用户信息，该表的记录实体是“用户”；

• 角色信息表（roles）：用来记录所有可用的角色信息，记录实体是“角色”；

• 权限信息表（privileges）：记录所有可用的权限信息，实体是“权限”；

• 用户 - 角色关系表（user_roles）：记录系统中用户和角色实体的对应关系（通常是“多对多”关系，即一个用户可以拥有吧多种角色，某个角色也可以同时被多个用户持有）；

• 角色 - 权限关系表（role_privileges）：记录系统中角色和权限实体之间的对应关系（通常也是“多对多”的关系）

三、权限管理

对于一次正确的权限获取过程，数据流通常是这样的：

    users ---> user_roles ---> role_privileges ---> privileges

例如对于某个用户“张三”，如果需要获取他的所有权限，应当先通过 user 获取到该用户 user_id=1， 然后使用这个 user_id 去 user_roles 表中查到其对应的全部角色主键是：1,2,3，获取到角色列表后，再通过 role_privileges 表查到这些角色对应的所有权限信息（主键 id），最后通过 privileges 表就能查到最终的权限列表信息了。

四、改进

通常情况下，对于一个大型项目来说，系统中可用的权限会非常多，尤其是对于需要细粒度管控权限的场景，如果系统中的权限列表过长，会给系统管理员进行权限分配时候带来很大的不便，为此，在项目中可以对权限进行分组管理，即在“权限”和“角色”之间构建一个“权限组”的分层。

通常，一个“权限组”可以使一系列紧密关联的权限的集合，通常是系统中的某个具体模块，例如，可以吧对“用户信息的增删改查操作”归为一个权限组，如果某个角色拥有这一权限组，即同时拥有了该权限组下的全部权限，这样管理员再管控权限时候，可以权限组为单位进行权限的分配，从而避免了大量重复的权限分配过程。