RBAC权限控制

最新推荐文章于 2024-08-19 10:52:05 发布

wht1995316

最新推荐文章于 2024-08-19 10:52:05 发布

阅读量934

点赞数

分类专栏：权限控制

本文链接：https://blog.csdn.net/wht1995316/article/details/115712009

版权

权限控制专栏收录该内容

1 篇文章 0 订阅

订阅专栏

1.什么是权限

权限是指为了保证职责的有效履行，任职者必须具备的，对某事项进行决策的范围和程度。它常常用“具有批准……事项的权限”来进行表达。

上述表述来子百度，是不是比较抽象？用于web用于该怎么理解呢？

比如，审核系统中有三个用户分别是审核员A，审核员B，审核组长C。审核员A可以操作和查看PGC的数据，审核员B可以操作UGC的数据,审核组长C可以查看和操作所有的数据。这些使用场景，都需要通过权限控制来实现的。如果不加限制的话，业务系统会异常混乱。

2.ACL

ACL 是 Access Control List 的缩写，称为访问控制列表，包含了对一个对象或一条记录可进行何种操作的权限定义。

对应于web应用既每个用户拥有一套自己的权限。考虑到web应用通常拥有很多用户，每次修改用户权限的时候需要逐条修改对应的所有用户，这样的方式不仅繁琐，而且容易出错。举个例子，审核系统现在只有一个PGC审核员，给PGC审核员分配了对应的权限。这时，又入职100个PGC审核员，这时系统管理员可能就崩溃了。

由于ACL的一些缺陷，RBAC出现了。

3.RBAC

1.RBAC是什么

RBAC，全称是Role-Based Access Control，基于角色的访问控制。简单来说就是一个用户可以拥有若干个角色，一个角色可以拥有若干个权限。这样就形成了“用户-角色-权限”的模型。通过这样的方式，角色的权限可以灵活配置，用户的权限变化只需要改变角色。RBAC有很多模型，如果RBAC0，RBAC1，RBAC2，RBAC3。

1.RBAC0

RBAC0是基础，通常大多数系统基于BAC0就可以满足需求。

此模型有可以分为两种设计:

用户和角色是多对一关系：一个用户只能拥有一种角色，一种角色可以拥有多个用户。
用户和角色是多对多关系：一个用户可以拥有多种角色，一种角色可以拥有多个用户。

使用场景：

如果系统比较简单，用户比较少且不存在兼岗的情况，可以考虑设计1的权限设计。但是考虑到系统的可扩展性，尽量使用设计2的权限设计。如审核员A可以同时拥有PGC，UGC的审核权限

2.RBAC1

RBAC1是RBAC0的扩展，在RBAC0模型的基础上对角色进行了分层，既可以在角色下创建多个子角色，子角色的权限来源于父角色。

使用场景：

如果审核系统存在审核经理、审核组长、审核员3种角色。审核经理权限 > 审核组长 > 审核员。如果采用RBAC0的模型来设计，可能会出现权限分配失误，而造成审核员拥有审核经理都没有的权限的情况。

角色分层：

2.与ACL的区别

ACL:访问控制列表

RBAC的优势：

1.简化了用户和权限的关系

2.易扩展，易于维护

RBAC不用给用户单个分配权限，只用指向对应的角色就会有对应的权限，而且分配权限和收回权限都很方便。

3.RBAC0整体架构

4.表设计

基于RBAC基本架构的设计，5个模块对应5张表。分别为用户表，角色表，用户角色关联表，权限表，角色权限关联表。

CREATE TABLE `user` (
  `id` int(10) NOT NULL AUTO_INCREMENT,
  `name` varchar(30) NOT NULL DEFAULT '' COMMENT '姓名',
  `status` tinyint(10) NOT NULL DEFAULT '1' COMMENT '用户状态 ： 1，有效 2，无效',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户表';
 
 
CREATE TABLE `role` (
  `id` int(10) NOT NULL AUTO_INCREMENT COMMENT '主键id',
  `name` varchar(30) NOT NULL DEFAULT '' COMMENT '角色名',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='角色表';
 
 
CREATE TABLE `relation_user_role` (
  `id` int(10) NOT NULL AUTO_INCREMENT COMMENT '主键id',
  `user_id` int(10) NOT NULL COMMENT '用户id',
  `role_id` int(10) NOT NULL DEFAULT '0' COMMENT '角色id',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
 
 
CREATE TABLE `access` (
  `id` int(10) NOT NULL COMMENT '主键id',
  `name` varchar(30) NOT NULL DEFAULT '' COMMENT '权限名称',
  `module` varchar(30) NOT NULL DEFAULT '' COMMENT '模块名',
  `action` varchar(30) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT '方法名',
  `status` tinyint(1) NOT NULL DEFAULT '1' COMMENT '状态: 1，正常 2，删除',
  `type` tinyint(1) NOT NULL COMMENT '权限类型 ：1.菜单 2.操作',
  `pid` int(10) NOT NULL COMMENT '菜单对应的父级id',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='权限表';
 
 
CREATE TABLE `relation_role_access` (
  `id` int(10) NOT NULL AUTO_INCREMENT,
  `role_id` int(10) NOT NULL DEFAULT '0' COMMENT '角色id',
  `access_id` int(10) NOT NULL DEFAULT '0' COMMENT '权限id',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='角色与权限关联关系';

5.流程控制

用户访问API
判断用户是否是合法用户
权限判断
拥有权限则可操作API，否则则提示无权限

判断权限逻辑：

根据登录信息获取用户id，标记是否是超级管理员(可用配置文件的形式写在代码里)
如是超级管理员则不需要做权限判断，否则根据用户id获取对应的角色信息
根据角色信息获取拥有的权限，去重后获取权限列表
判断当前操作是否在列表中

4.超审的权限控制分析

CREATE TABLE super_user_manager (
  id bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增主键',
  uid bigint(50) NOT NULL DEFAULT '0' COMMENT '用户passportid',
  username varchar(30) NOT NULL DEFAULT '' COMMENT '用户名',
  userunique varchar(33) NOT NULL DEFAULT '' COMMENT '用户唯一标识',
  comefrom varchar(50) NOT NULL DEFAULT '' COMMENT '用户来源',
  `status` tinyint(1) NOT NULL DEFAULT '1' COMMENT '用户状态 1-有效 0-无效',
  groupid int(11) NOT NULL DEFAULT '0' COMMENT '组群id',
  groupname varchar(50) NOT NULL DEFAULT '' COMMENT '权限组名称',
  auths varchar(10000) NOT NULL DEFAULT '' COMMENT '个人权限',
  otherinfo varchar(1024) NOT NULL DEFAULT '' COMMENT '附加信息',
  ext varchar(1024) NOT NULL DEFAULT '' COMMENT '扩展',
  addtime timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '添加时间',
  updatetime timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (id),
  UNIQUE KEY uid (uid),
  KEY username (username),
  KEY idx_groupid_status (groupid,`status`)
) ENGINE=InnoDB AUTO_INCREMENT=213 DEFAULT CHARSET=utf8 COMMENT='超审用户管理表'
 
 
CREATE TABLE super_group_manager (
  groupid int(11) NOT NULL AUTO_INCREMENT COMMENT '组群id,自增唯一索引',
  groupname varchar(100) NOT NULL DEFAULT '' COMMENT '组群名称',
  auths varchar(10000) NOT NULL DEFAULT '' COMMENT '分组权限集合',
  `status` tinyint(1) NOT NULL DEFAULT '1' COMMENT '状态 1-有效 0-无效',
  otherinfo varchar(1024) NOT NULL DEFAULT '' COMMENT '附加信息',
  ext varchar(1024) NOT NULL DEFAULT '' COMMENT '扩展',
  addtime timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '添加时间',
  updatetime timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (groupid),
  UNIQUE KEY groupname (groupname)
) ENGINE=InnoDB AUTO_INCREMENT=352 DEFAULT CHARSET=utf8 COMMENT='超审组群管理表'
 
 
CREATE TABLE super_catalog (
  id int(10) NOT NULL AUTO_INCREMENT COMMENT '自增id',
  `name` varchar(100) NOT NULL DEFAULT '' COMMENT '菜单名称',
  `type` tinyint(1) NOT NULL COMMENT '类型 ：1-菜单 2-权限 3-actions',
  pid int(10) NOT NULL DEFAULT '0' COMMENT '父节点id',
  auths_type varchar(50) NOT NULL COMMENT '权限类型：read，write，export',
  keyword varchar(200) NOT NULL DEFAULT '' COMMENT '关键字',
  url varchar(200) NOT NULL DEFAULT '' COMMENT '菜单对应url',
  is_leaf tinyint(1) NOT NULL DEFAULT '2' COMMENT '是否是叶子结点：1-是 2-否',
  update_time int(10) NOT NULL DEFAULT '0' COMMENT '最后更新时间',
  create_time int(10) NOT NULL DEFAULT '0' COMMENT '添加时间',
  PRIMARY KEY (id),
  KEY idx_pid (pid)
) ENGINE=InnoDB AUTO_INCREMENT=271 DEFAULT CHARSET=utf8 COMMENT='超审导航数据表'
 
 
CREATE TABLE relation_user_group (
  id int(10) NOT NULL AUTO_INCREMENT COMMENT '自增主键id',
  userid bigint(20) NOT NULL COMMENT '用户表uid',
  groupid int(10) NOT NULL COMMENT '组id',
  PRIMARY KEY (id),
  UNIQUE KEY `unique` (userid,groupid),
  KEY userid (userid),
  KEY groupid (groupid)
) ENGINE=InnoDB AUTO_INCREMENT=1000251 DEFAULT CHARSET=utf8 COMMENT='用户与组的关联关系'
 
 
CREATE TABLE super_product_line (
  id int(10) NOT NULL AUTO_INCREMENT COMMENT '主键',
  pid int(10) NOT NULL DEFAULT '0' COMMENT '父节点id',
  `name` varchar(200) NOT NULL DEFAULT '' COMMENT '产品线名称',
  keyword varchar(100) NOT NULL DEFAULT '' COMMENT '产品线标识',
  manager varchar(1000) NOT NULL DEFAULT '' COMMENT '产品线管理员平台账号',
  catalog_node varchar(3000) NOT NULL DEFAULT '' COMMENT '可操作菜单节点-目前是权限节点关键字',
  ext varchar(500) NOT NULL DEFAULT '' COMMENT '备注',
  operate_uid bigint(20) NOT NULL DEFAULT '0' COMMENT '操作人uid',
  add_time int(10) NOT NULL DEFAULT '0' COMMENT '添加时间',
  update_time int(10) NOT NULL DEFAULT '0' COMMENT '更新时间',
  PRIMARY KEY (id),
  UNIQUE KEY `name` (`name`),
  UNIQUE KEY keyword (keyword)
) ENGINE=InnoDB AUTO_INCREMENT=59 DEFAULT CHARSET=utf8 COMMENT='产品线信息表'

2.产品线

超审加入了产品线的概念。产品线的概念比较抽象，实际可能理解为：PGC审核A只可以看到PGC负责的数据;PGC审核组长B可以看到所有PGC审核员的数据，但是却看不UGC或问答审核员的数据。更直白一些来讲，就是审核员能操作的数据只有我和我的上级领到可以看到。这其实是RBAC1模型，既在RBAC0的基础上通过角色分级来控制权限。