RBAC权限（一）

一. 权限管理

一.一 什么是权限管理?

权限，简单理解就是功能， 你是否具有某个权限，即你是否具有某个功能.

如，用户 两个蝴蝶飞 具有部门删除的权限， 那么就可以说用户两个蝴蝶飞具有部门删除的功能。

用户岳泽霖 不具有部门删除的权限,那么就可以说用户 岳泽霖 不具有部门删除的功能。

你具有某些权限，你就可以干某些事情。

一.二. 为什么要进行权限控制?

生活和开发中进行权限管理，主要是为了安全，保护数据。

现在的系统，无论是电脑，手机，Ipad, 网站，都支持多用户登录的情况， 如老蝴蝶电脑上有 两个蝴蝶飞和岳泽霖两个用户， 那么当我以两个蝴蝶飞这个用户登录时，是不能看到岳泽霖用户里面的相应信息的，同样，以岳泽霖这个身份登录时，也不能看到两个蝴蝶飞用户里面的相应信息，这样就保护了用户的隐私性，保障了数据的基本的安全。

就像在公司中，总裁下面有人事经理，财务经理， 人事经理下面有两个人事专员， 财务经理下面也有两个人事专员，

还有一个普通的小用户，你。

那么很显然，总裁具有该公司所有的权限，可以进行登录，可以查看自己的个人信息，也可以查看公司的报表统计， 而人事经理只能看人员信息，用户考勤等功能，是不能看到财务部相关的功能的。 同时，人事部里面人事经理的权限和人事专员的权限也可能是不一样的，人事经理的权限要稍微大一些，人事专员的权限相对小一些。 而你，一个普通的小用户，是没有办法看到公司的人员信息，考勤信息的，更无法看到财务信息的，只能进行简单的登录，修改个人信息等功能。如果你能看见公司人事经理的功能，或者财务经理的功能，那么很显然，对于个人和公司来说，都是非常不安全的，所以需要进行权限控制。

一.三. 开发中常见的权限控制

实际开发中，有着很复杂的权限控制，需要授权申请，同意授权，移除授权申请，同意移除授权，暂时授权等。

我们平常开发中，遇到的权限控制有:

1. 登录认证。 如果用户没有登录，则不能进行操作，必须先进行登录。 如查看用户的信息等。
2. 权限授权。 如果用户没有相应的权限，则不能进行相应的操作。 如，用户两个蝴蝶飞只有部门删除的权限，没有部门添加的权限，那么则只能进行删除，不能进行添加。

然而，在进行权限管理时，还需要保证以下几点:

1. 对于 跳转到登录页面，登录，注册，静态页面等内容，是不需要进行认证操作的，可以直接访问。
2. 当用户没有登录时，直接输入相应的网址，即使用户拥有此网址对应的功能，也无法进行操作，需要跳转到登录页面，先进行登录。
3. 对于用户已经登录的，直接输入相应的网址，如果用户不具有些网址对应的功能，无法进行操作，显示给用户 权限不足的提示。
4. 对于不具有某些功能的页面元素，如没有部门添加的功能，那么部门视图里面，对该用户来说，不能展示部门添加的按钮。
5. 对于已经退出系统的用户来说，直接输入相应的网址，也需要先进行登录。

权限控制，包括 表级别的权限控制和数据级别的权限控制。 常见的菜单，按钮属于表级别的权限控制。

数据级别的权限，指用户A和用户B都具有查询员工档案的权限，但用户A是总裁，那么用户A可以查看所有的员工档案信息，用户B是部门经理，那么只能查看该部门下的所有的员工信息， 也可以有一个员工C 人事经理，可以查看 当前在职的所有的员工档案。 同样都是员工档案的查看权限，由于身份不同，能够查看的数据结果不同。 这就是数据级别的权限。

数据级别的权限，通常需要业务逻辑处理， 即在业务代码中，进行相应的判断，如果是总裁，执行总裁查询的sql语句，如果是部门经理，执行部门经理查询的sql语句。

二. RBAC 实现权限管理

二.一 原始的权限管理

以前在开发权限管理时， 用户具有某些权限，直接创建一个用户表，一个权限表，还有一个用户权限表。 用户表里面放置的是用户信息，权限表里面放置权限的信息 ，包括菜单权限和按钮权限， 用户权限表是用户表和权限表的中间表，用于存放用户的权限信息。

当查看某个员工的权限时，直接去用户权限表里面，通过用户的id 进行查询权限。

这对于非常简单的项目来说，是没有太大的问题， 可当用户过多时，系统权限过多时，将会出现一些问题。

1. 数据多。每一个用户，都会往用户权限表里面放置数据，如果放满，则是 用户总量*权限总量 。 如果用户A具有权限编号为 1~10的权限，用户B 具有权限编号为 2~11的权限， 则需要将2~10 这九个权限重复2次，无法提取出来。
2. 查询效率低。 查询员工的权限时，需要遍历整个表的记录。
3. 后期维护成本大。 当新进来一个员工时，需要给其一个个配置权限，部门的删除和查看权限，员工的查看权限， 容易出现错误，可能出现少添加，多添加，或者错误配置权限。当员工离职时，需要给其一个个移除权限，部门的删除和查看权限，员工的查看权限，也容易出现错误。 很考验配置权限的那个员工的眼睛和细心程度的。
4. 当新添加一个权限时，给对应的员工配置，需要找到员工，一个个进行配置。 配置的过程，枯燥，容易出现遗漏。

这里，员工与权限，是直接相连的。

我们希望，在员工与权限的中间，有一个新的实体， 做到员工连接新实体，新实体连接权限， 员工与权限变成了间接相连，这样就很大程序地避免上面的问题了。 这个新实体，就是角色。

通过角色来控制权限，就是 RBAC.

二.二 RBAC

二.二.一 RBAC的简单解释

RBAC,全称是(Role-Based Access Control), 基于角色的访问控制。

用户连接角色，角色连接权限， 想知道某一个用户的权限，只需要 查询出该用户的所有的角色，然后将每一个角色的权限找出来然后进行合并即可。

如果用户A 具有110的权限，用户B具有211的权限， 那么只需要将2~10的权限提取出来，创建一个角色2_10, 角色2_10里面放置权限2,权限3…权限10, 用户A连接角色2_10, 那么用户A就具有权限2,权限3 … 权限10了。

当新添加一个员工时，只需要把这个员工与角色关联起来，新员工就可以拥有一些权限了。 当移除一个员工时，只需要把员工与角色进行断开关联 ，就可以取消该员工的权限，不需要再像以前那样再操作权限信息了。

流程图表示为:

该图片引用于: RBAC权限管理 https://www.jianshu.com/p/44bfd8d6184b

二.二.二 RBAC的表设计

数据表表示为:

二.二.二.一 用户表 user

CREATE TABLE `user` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '员工id',
  `code` varchar(20) DEFAULT NULL COMMENT '员工编号',
  `name` varchar(30) DEFAULT NULL COMMENT '员工姓名',
  `password` varchar(128) DEFAULT NULL COMMENT '密码',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;

二.二.二.二 角色表 role

CREATE TABLE `role` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '角色id',
  `name` varchar(50) DEFAULT NULL COMMENT '角色名称',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;

二.二.二.三 用户角色关联表 user_role

CREATE TABLE `user_role` (
  `uid` int(11) NOT NULL COMMENT '员工编号',
  `rid` int(11) NOT NULL COMMENT '角色编号',
  `create_by` int(11) DEFAULT NULL COMMENT '创建人',
  `create_date` date DEFAULT NULL COMMENT '创建时间',
  PRIMARY KEY (`uid`,`rid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

二.二.二.四 权限表 privilege

CREATE TABLE `privilege` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(50) DEFAULT NULL COMMENT '权限名称',
  `url` varchar(128) DEFAULT NULL COMMENT '权限的地址',
  `type` int(1) DEFAULT NULL COMMENT '类型,1是菜单，2是按钮',
  `orderNum` int(2) DEFAULT NULL COMMENT '排序，同一级别下的排序',
  `percode` varchar(30) DEFAULT NULL COMMENT '按钮权限的标识',
  `icon` varchar(128) DEFAULT NULL COMMENT '权限的图标',
  `pid` int(11) DEFAULT NULL COMMENT '上级权限编号',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=15 DEFAULT CHARSET=utf8;

二.二.二.五 角色权限表 role_privilege

CREATE TABLE `role_privilege` (
  `rid` int(11) NOT NULL COMMENT '角色编号',
  `pid` int(11) NOT NULL COMMENT '权限编号',
  `create_by` int(11) DEFAULT NULL COMMENT '操作人',
  `create_date` date DEFAULT NULL COMMENT '操作人',
  PRIMARY KEY (`rid`,`pid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

这就是基于 RBAC 的简单五个表的内容 。

二.三 四种模型 RBAC0,RBAC1,RBAC2,RBAC3

二.三.一 RBAC0 模型

RBAC0, 是RBAC的五个核心表， 就是上面那五个表。

二.三.二 RBAC1 模型

RBAC1 对 RBAC0 进行了扩展，引入了 角色继承的概念， 角色具有上下级了。

此时的角色表 role 表

CREATE TABLE `role` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '角色id',
  `name` varchar(50) DEFAULT NULL COMMENT '角色名称',
  `rpId` int(11) DEFAULT NULL COMMENT '上级角色编号',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;

角色一般员工的编号为1， 人事经理的角色编号为2，它的上级角色编号为1，总裁的角色编号为3，它的上级角色编号为1，

一般员工具有修改个人信息，查看个人档案的权限，

那么人事经理也想需要这两个权限，这个时候，不需要配置 人事经理的角色与修改个人信息，查看个人档案的权限关联，只需要让人事经理的角色继承 一般员工即可。

要想总裁也具有这两个权限，只需要总裁继承一般员工这个角色即可。

某一个员工，所具有的权限，就是该员工对应的每一个角色和所有父级角色的权限总和。

二.三.三 RBAC2 模型

角色与角色之间，可能存在冲突，如出纳和会计， 运动员和裁判。 一个员工是不能既是出纳，又是会计（你懂得）， 运行员不能既是运行员，又是裁判。

需要对不同的角色之间，进行职责分离。

职责分离，有两种形式， 第一种是静态职责分离，第二种是动态职责分离。

二.三.三.一 静态职责分离

静态职责分离，是指用户无法同时赋予有冲突的角色。 如果员工已经有了出纳的角色，那么在给该员工配置会计角色时，会提示角色有冲突，不让配置。 这个是在配置角色时，进行校验。 无论角色之间是否继承，都需要进行校验。

二.三.三.二 动态职责分离

动态职责分离，是指用户在一次会话(Session)中，不能同时激活自身所拥有的，互相冲突的角色，只能选择其一。 当用户登录时，或者登录成功后，会让用户选择角色，如用户选择了出纳的角色。 在运行会话期间，该用户是无法选择会计的角色进行操作的，只能先退出，再重新登录。 这个是在运行中，动态地选择的。 注意，这种模式在配置角色时，是可以配置成功的。

二.三.四 RBAC3 模型

RBAC3就是 RBAC1+RBAC2。

角色需要继承，同时也要进行职责分离。

一般开发中，我们只选择 RBAC0 模型即可。

三. RBAC 权限管理的完整表结构

完整的 RBAC 权限表结构，可以看 RBAC权限管理 https://blog.csdn.net/painsonline/article/details/7183613/

具有，用户，用户组，角色，权限，权限菜单 ，权限元素，权限文件，权限 等主要表信息。