RBAC（用户、角色、权限）模型学习笔记一

权限系统与RBAC模型概述

RBAC（Role-Based Access Control ）基于角色的访问控制。

在20世纪90年代期间，大量的专家学者和专门研究单位对RBAC的概念进行了深入研究，先后提出了许多类型的RBAC模型，其中以美国George Mason大学信息安全技术实验室（LIST）提出的RBAC96模型最具有系统性，得到普遍的公认。

RBAC认为权限的过程可以抽象概括为：判断【Who是否可以对What进行How的访问操作（Operator）】这个逻辑表达式的值是否为True的求解过程。

即将权限问题转换为Who、What、How的问题。who、what、how构成了访问权限三元组。

RBAC支持公认的安全原则：最小特权原则、责任分离原则和数据抽象原则。

• 最小特权原则得到支持，是因为在RBAC模型中可以通过限制分配给角色权限的多少和大小来实现，分配给与某用户对应的角色的权限只要不超过该用户完成其任务的需要就可以了。
• 责任分离原则的实现，是因为在RBAC模型中可以通过在完成敏感任务过程中分配两个责任上互相约束的两个角色来实现，例如在清查账目时，只需要设置财务管理员和会计两个角色参加就可以了。
• 数据抽象是借助于抽象许可权这样的概念实现的，如在账目管理活动中，可以使用信用、借方等抽象许可权，而不是使用操作系统提供的读、写、执行等具体的许可权。但RBAC并不强迫实现这些原则，安全管理员可以允许配置RBAC模型使它不支持这些原则。因此，RBAC支持数据抽象的程度与RBAC模型的实现细节有关。

RBAC96是一个模型族，其中包括RBAC0~RBAC3四个概念性模型。

1、基本模型RBAC0定义了完全支持RBAC概念的任何系统的最低需求。

2、RBAC1和RBAC2两者都包含RBAC0，但各自都增加了独立的特点，它们被称为高级模型。

RBAC1中增加了角色分级的概念，一个角色可以从另一个角色继承许可权。

RBAC2中增加了一些限制，强调在RBAC的不同组件中在配置方面的一些限制。

3、RBAC3称为统一模型，它包含了RBAC1和RBAC2，利用传递性，也把RBAC0包括在内。这些模型构成了RBAC96模型族。

RBAC的组成

在RBAC模型里面，有3个基础组成部分，分别是：用户、角色和权限。

RBAC通过定义角色的权限，并对用户授予某个角色从而来控制用户的权限，实现了用户和权限的逻辑分离（区别于ACL模型），极大地方便了权限的管理

下面在讲解之前，先介绍一些名词：

• User（用户）：每个用户都有唯一的UID识别，并被授予不同的角色
• Role（角色）：不同角色具有不同的权限
• Permission（权限）：访问权限
• 用户-角色映射：用户和角色之间的映射关系
• 角色-权限映射：角色和权限之间的映射

它们之间的关系如下图所示：

用户、角色、权限关系

例如下图，管理员和普通用户被授予不同的权限，普通用户只能去修改和查看个人信息，而不能创建创建用户和冻结用户，而管理员由于被授 予所有权限，所以可以做所有操作。

例如下图，管理员和普通用户被授予不同的权限，普通用户只能去修改和查看个人信息，而不能创建用户和冻结用户，而管理员由于被授予所有权限，所以可以做所有操作。

角色操作示例

RBAC支持的安全原则

RBAC支持三个著名的安全原则：最小权限原则、责任分离原则和数据抽象原则

• 最小权限原则：RBAC可以将角色配置成其完成任务所需的最小权限集合
• 责任分离原则：可以通过调用相互独立互斥的角色来共同完成敏感的任务，例如要求一个计账员和财务管理员共同参与统一过账操作
• 数据抽象原则：可以通过权限的抽象来体现，例如财务操作用借款、存款等抽象权限，而不是使用典型的读、写、执行权限

RBAC的优缺点

（1）优点：

• 简化了用户和权限的关系
• 易扩展、易维护

（2）缺点：

RBAC模型没有提供操作顺序的控制机制，这一缺陷使得RBAC模型很难适应那些对操作次序有严格要求的系统

RBAC的3种模型

RBAC0

RBAC0，是最简单、最原始的实现方式，也是其他RBAC模型的基础。

RBAC0

在该模型中，用户和角色之间可以是多对多的关系，即一个用户在不同场景下是可以有不同的角色，例如：项目经理也可能是组长也可能是架构师。同时每个角色都至少有一个权限。这种模型下，用户和权限被分离独立开来，使得权限的授权认证更加灵活。

RBAC1

基于RBAC0模型，引入了角色间的继承关系，即角色上有了上下级的区别。

RBAC1

角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构，实现角色间的单继承。

这种模型适合于角色之间层次分明，可以给角色分组分层。

RBAC2

RBAC2，基于RBAC0模型的基础上，进行了角色的访问控制。

RBAC2

RBAC2中的一个基本限制是互斥角色的限制，互斥角色是指各自权限可以互相制约的两个角色。对于这类角色一个用户在某一次活动中只能被分配其中的一个角色，不能同时获得两个角色的使用权。

该模型有以下几种约束：

• 互斥角色 ：同一用户只能分配到一组互斥角色集合中至多一个角色，支持责任分离的原则。互斥角色是指各自权限互相制约的两个角色。对于这类角色一个用户在某一次活动中只能被分配其中的一个角色，不能同时获得两个角色的使用权。常举的例子：在审计活动中，一个角色不能同时被指派给会计角色和审计员角色。
• 基数约束 ：一个角色被分配的用户数量受限；一个用户可拥有的角色数目受限；同样一个角色对应的访问权限数目也应受限，以控制高级权限在系统中的分配。例如公司的领导人有限的；
• 先决条件角色 ：可以分配角色给用户仅当该用户已经是另一角色的成员；对应的可以分配访问权限给角色，仅当该角色已经拥有另一种访问权限。指要想获得较高的权限，要首先拥有低一级的权限。就像我们生活中，主席是从副主席中选举的一样。
• 运行时互斥 ：例如，允许一个用户具有两个角色的成员资格，但在运行中不可同时激活这两个角色。

如何设计RBAC

RBAC的功能模块

RBAC执行流程

RBAC数据库设计

实用的RBAC模型的数据库建模

Mysql RBAC模型一（用户、角色、权限）

-- create database shiro default character set utf8;

drop table if exists sys_users;
drop table if exists sys_roles;
drop table if exists sys_permissions;
drop table if exists sys_users_roles;
drop table if exists sys_roles_permissions;

create table sys_users (
  id bigint auto_increment comment '编号',
  username varchar(100) comment '用户名',
  password varchar(100) comment '密码',
  salt varchar(100) comment '盐值',
  role_id varchar(50) comment '角色列表',
  locked bool default false comment '是否锁定',
  constraint pk_sys_users primary key(id)
) charset=utf8 ENGINE=InnoDB;
create unique index idx_sys_users_username on sys_users(username);

create table sys_roles (
  id bigint auto_increment comment '角色编号',
  role varchar(100) comment '角色名称',
  description varchar(100) comment '角色描述',
  pid bigint comment '父节点',
  available bool default false comment '是否锁定',
  constraint pk_sys_roles primary key(id)
) charset=utf8 ENGINE=InnoDB;
create unique index idx_sys_roles_role on sys_roles(role);

create table sys_permissions (
  id bigint auto_increment comment '编号',
  permission varchar(100) comment '权限编号',
  description varchar(100) comment '权限描述',
  rid bigint comment '此权限关联角色的id',
  available bool default false comment '是否锁定',
  constraint pk_sys_permissions primary key(id)
) charset=utf8 ENGINE=InnoDB;
create unique index idx_sys_permissions_permission on sys_permissions(permission);

create table sys_users_roles (
  id  bigint auto_increment comment '编号',
  user_id bigint comment '用户编号',
  role_id bigint comment '角色编号',
  constraint pk_sys_users_roles primary key(id)
) charset=utf8 ENGINE=InnoDB;

create table sys_roles_permissions (
  id bigint auto_increment comment '编号',
  role_id bigint comment '角色编号',
  permission_id bigint comment '权限编号',
  constraint pk_sys_roles_permissions primary key(id)
) charset=utf8 ENGINE=InnoDB;

MySql RBAC 模型二（单位、用户、角色、权限）

组织部门管理

需求分析

之所以先将部门管理提出来讲一下，是因为部门管理没有在我们上面的RBAC权限模型中进行提现。但是部门这样一个实体仍然是，后端管理系统的一个重要组成部分。通常有如下的需求：

• 部门要能体现出上下级的结构（如上图中的红框）。在关系型数据库中。这就需要使用到部门id及上级部门id，来组合成一个树形结构。这个知识是SQL学习中必备的知识，如果您还不知道，请自行学习。
• 如果组织与用户之间是一对多的关系，就在用户表中加上一个org_id标识用户所属的组织。原则是：实体关系在多的那一边维护。比如：是让老师记住自己的学生容易，还是让学生记住自己的老师更容易？
• 如果组织与用户是多对多关系，这种情况现实需求也有可能存在。比如：某人在某单位既是生产部长，又是技术部长。所以他及归属于技术部。也归属于生产部。对于这种情况有两种解决方案，把该人员放到公司级别，而不是放到部门级别。另外一种就是从数据库结构上创建User与Org组织之间的多对多关系。
• 组织信息包含一些基本信息，如组织名称、组织状态、展现排序、创建时间
• 另外，要有基本的组织的增删改查功能

组织部门表的CreateSQL

CREATE TABLE `sys_org` (
	`id` INT(11) NOT NULL AUTO_INCREMENT,
	`org_pid` INT(11) NOT NULL COMMENT '上级组织编码',
	`org_pids` VARCHAR(64) NOT NULL COMMENT '所有的父节点id',
	`is_leaf` TINYINT(4) NOT NULL COMMENT '0:不是叶子节点，1:是叶子节点',
	`org_name` VARCHAR(32) NOT NULL COMMENT '组织名',
	`address` VARCHAR(64) NULL DEFAULT NULL COMMENT '地址',
	`phone` VARCHAR(13) NULL DEFAULT NULL COMMENT '电话',
	`email` VARCHAR(32) NULL DEFAULT NULL COMMENT '邮件',
	`sort` TINYINT(4) NULL DEFAULT NULL COMMENT '排序',
	`level` TINYINT(4) NOT NULL COMMENT '组织层级',
	`status` TINYINT(4) NOT NULL COMMENT '0:启用,1:禁用',
	PRIMARY KEY (`id`)
)
COMMENT='系统组织结构表'
COLLATE='utf8_general_ci'
ENGINE=InnoDB;

mysql没有oracle中的start with connect by的树形数据汇总SQL。所以通常需要为了方便管理组织之间的上下级树形关系，需要加上一些特殊字段，如：org_pids：该组织所有上级组织id逗号分隔，即包括上级的上级；is_leaf是否是叶子结点；level组织所属的层级(1,2,3)。

用户管理

需求分析

• 上图中点击左侧的组织菜单树结点，要能显示出该组织下的所有人员（系统用户）。在组织与用户是一对多的关系中，需要在用户表加上org_id字段，用于查询某个组织下的所有用户。
• 用户表中要保存用户的用户名、加密后的密码。页面提供密码修改或重置的功能。
• 角色分配:实际上为用户分配角色，与为角色分配权限的设计原则是一样的。所以可以参考。
• 实现用户基本信息的增删改查功能

sys_user 用户信息表及用户角色关系表的CreateSQL

CREATE TABLE `sys_user` (
        `id` INT(11) NOT NULL AUTO_INCREMENT,
        `org_id` INT(11) NOT NULL,
        `username` VARCHAR(64) NULL DEFAULT NULL COMMENT '用户名',
        `password` VARCHAR(64) NULL DEFAULT NULL COMMENT '密码',
        `enabled` INT(11) NULL DEFAULT '1' COMMENT '用户账户是否可用',
        `locked` INT(11) NULL DEFAULT '0' COMMENT '用户账户是否被锁定',
        `lockrelease_time` TIMESTAMP NULL DEFAULT NULL COMMENT  '用户账户锁定到期时间',
        `expired_time` TIMESTAMP NULL DEFAULT NULL COMMENT '用户账户过期时间',
        `create_time` TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '用户账户创建时间',
	PRIMARY KEY (`id`)
)
COMMENT='用户信息表'
ENGINE=InnoDB;
CREATE TABLE `sys_user_role` (
	`id` INT(11) NOT NULL AUTO_INCREMENT,
	`role_id` VARCHAR(16) NULL DEFAULT NULL,
	`user_id` VARCHAR(18) NULL DEFAULT NULL,
	PRIMARY KEY (`id`)
)
COLLATE='utf8_general_ci'
ENGINE=InnoDB;

在用户的信息表中，体现了一些隐藏的需求。如：多次登录锁定与锁定到期时间的关系。账号有效期的设定规则等。

当然用户表中，根据业务的不同还可能加更多的信息，比如：用户头像等等。但是通常在比较大型的业务系统开发中，业务模块中使用的用户表和在权限管理模块使用的用户表通常不是一个，而是根据某些唯一字段弱关联，分开存放。这样做的好处在于：经常发生变化的业务需求，不会去影响不经常变化的权限模型。

角色管理

上图为角色修改及分配权限的页面

需求分析

• 角色本身的管理需要注意的点非常少，就是简单的增删改查。重点在于角色分配该如何做。
• 角色表包含角色id，角色名称，备注、排序顺序这些基本信息就足够了
• 为角色分配权限：以角色为基础勾选菜单权限或者操作权限，然后先删除sys_role_menu表内该角色的所有记录，在将新勾选的权限数据逐条插入sys_role_menu表。
• sys_role_menu的结构很简单，记录role_id与menu_id，一个角色拥有某一个权限就是一条记录。
• 角色要有一个全局唯一的标识，因为角色本身也是一种权限。可以通过判断角色来判断某用户的操作是否合法。
• 通常的需求：不会在角色管理界面为角色添加用户，而是在用户管理界面为用户分配角色。

角色表与角色菜单权限关联表的的CreateSQL

CREATE TABLE `sys_role` (
	`id` INT(11) NOT NULL AUTO_INCREMENT,
	`role_id` VARCHAR(16) NOT NULL COMMENT '角色ID',
	`role_name` VARCHAR(16) NOT NULL COMMENT '角色名',
	`role_flag` VARCHAR(64) NULL DEFAULT NULL COMMENT '角色标识',
	`sort` INT(11) NULL DEFAULT NULL COMMENT '排序',
	PRIMARY KEY (`id`)
)
COMMENT='系统角色表'
COLLATE='utf8_general_ci'
ENGINE=InnoDB;
CREATE TABLE `sys_role_menu` (
	`id` INT(11) NOT NULL AUTO_INCREMENT,
	`role_id` VARCHAR(16) NOT NULL COMMENT '角色ID',
	`menu_id` INT(11) NOT NULL COMMENT '菜单ID',
	PRIMARY KEY (`id`)
)
COMMENT='角色菜单多对多关联表'
COLLATE='utf8_general_ci'
ENGINE=InnoDB;

菜单权限管理

需求分析

• 由上图可以看出，菜单仍然是树形结构，所以数据库表必须有id与menu_pid字段
• 必要字段：菜单跳转的url、是否启用、菜单排序、菜单的icon矢量图标等
• 最重要的是菜单要有一个权限标志，具有唯一性。通常可以使用菜单跳转的url路径作为权限标志。此标志作为权限管理框架识别用户是否具有某个页面查看权限的重要标志
• 需要具备菜单的增删改查基本功能
• 如果希望将菜单权限和按钮超链接相关权限放到同一个表里面，可以新增一个字段。用户标志该权限记录是菜单访问权限还是按钮访问权限。

菜单权限表的CreateSQL

CREATE TABLE `sys_menu` (
	`id` INT(11) NOT NULL AUTO_INCREMENT,
	`menu_pid` INT(11) NOT NULL COMMENT '父菜单ID',
	`menu_pids` VARCHAR(64) NOT NULL COMMENT '当前菜单所有父菜单',
	`is_leaf` TINYINT(4) NOT NULL COMMENT '0:不是叶子节点，1:是叶子节点',
	`name` VARCHAR(16) NOT NULL COMMENT '菜单名称',
	`url` VARCHAR(64) NOT NULL COMMENT '跳转URL',
	`icon` VARCHAR(45) NULL DEFAULT NULL,
	`icon_color` VARCHAR(16) NULL DEFAULT NULL,
	`sort` TINYINT(4) NULL DEFAULT NULL COMMENT '排序',
	`level` TINYINT(4) NOT NULL COMMENT '菜单层级',
	`status` TINYINT(4) NOT NULL COMMENT '0:启用,1:禁用',
	PRIMARY KEY (`id`)
)
COMMENT='系统菜单表'
COLLATE='utf8_general_ci'
ENGINE=InnoDB;

原文链接

RBAC权限学习

MySQL基于RBAC实现系统权限管理流程

OA系统七：数据库表设计：RBAC（基于角色的访问控制）介绍与核心表

RBAC权限系统分析、设计与实现

结合RBAC模型讲解权限管理系统需求及表结构创建

本栏目推荐文章
• Jmeter 参数化之用户参数
• 2024/1/13 算法笔记
• Python学习笔记
• HDP 笔记
• cleaning of llm corpus 大模型语料清洗
• Ajax注册表单用户名实时验证
• 学习进度笔记2
• 微软企业库Unity学习笔记(一)
• 微软企业库Unity学习笔记(二)
• kepware关于U-CON的使用笔记 (串口_非主动问答式)

模型 权限 角色 笔记 用户模型 权限 角色 笔记 权限 角色 代码 用户 权限 角色 用户tomcat linux权限 笔记 用户 权限 角色 用户 角色 权限 amp dynamics权限 角色 角色 用户 空间 角色 权限 密码 角色mybatis用户