微服务与Nacos概述-6

RBAC 模型

RBAC 基于角色的访问控制是实施面向企业安全策略的一种有效的访问控制方式。

基本思想是，对系统操作的各种权限不是直接授予具体的用户，而是在用户集合与权限集合之间建立一个角色集合。每一种角色对应一组相应的权限。一旦用户被分配了适当的角色后，该用户就拥有此角色的所有操作权限。这样做的好处是，不必在每次创建用户时都进行分配权限的操作，只要分配用户相应的角色即可，而且角色的权限变更比用户的权限变更要少得多，这样将简化用户的权限管理，减少系统的开销。

在这里插入图片描述

权限可分为三类：数据权限、操作权限和页面权限。

1、数据权限：控制账号可看到的数据范围。例如负责不同区域的人员，只能看到自己负责区域的标的，不能看到和修改其他区域的。

2、页面权限：控制账号可以看到的页面，通常系统都会有这一层权限控制。这种控制相对操作权限来说比较粗放，难以对权限进行精细管理。

3、操作权限：控制账号在页面上可以操作的按钮，通常指的是页面中的新增、删除、编辑、查询功能。没有操作权限，就只能看到页面中的数据，但是不能对数据进行操作。操作权限是比页面权限更精细一层的权限控制。

基础概念

RBAC 模型根据设计需要可分为 RBAC0、RBAC1、RBAC2、RBAC3 四种类型。其中 RBAC0 是基础，另外三种是 RBAC0 的升级。产品经理在进行权限系统设计时，可以结合实际情况来选择使用的 RBAC 模型的类型。

RBAC0 是 RBAC 模型的核心基础思想，即用户通过被赋予角色和权限进行关联。用户、角色和权限之间的两两关系均是多对多关系，即一个用户可以被赋予多个角色，一个角色可以被赋予多个用户。一个角色可以拥有多项权限，一项权限可以赋予多个角色。

RBAC1 是引入继承关系的 RBAC 模型，一个角色可以从另一个角色继承许可权，即角色具有上下级的关系。角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系允许角色间的多继承，受限继承关系则进一步要求角色继承关系是一个树结构

RBAC-2 模型在用户与角色间和角色与角色之间加入了一些规则限制。互斥角色是指各自权限可以互相制约的两个角色。且不能同时获得两个角色的使用权。规定了权限被赋予角色时或角色被赋予用户时所应遵循的强制性规则。角色互斥、基数约束、先决条件角色等

互斥角色：同一用户在两个互斥角色中只能选择一个。例如不能同时被指派给会计角色和审计员角色

先决条件角色 ：指要想获得较高的权限要首先拥有低一级的权限。例如要想为用户分配角色 A，则必须先分配角色 B

基数约束：一个角色被分配的用户数量受限；一个用户可拥有的角色数目受限

运行时互斥：允许一个用户具有两个角色，但在运行中不可同时激活这两个角色。

RBAC3 统一模型：同时包含 RBAC1 和 RBAC2 的特性，既有角色层级划分，也有各种限制

表定义

在这里插入图片描述

系统的 RBAC 相关表的定义

create table if not exists tbl_users(id bigint primary key,foreign key(id) references tbl_account on delect cascade,username varchar(32) not null unique,password varchar(32) not null,salt varchar(32) comment '盐值',iter int default 6 comment '加密次数'
)engine = innodb default charset utf8 comment '登录账户信息';create table if not exists tbl_roles(id bigint primary key auto_increment comment '代理主键',name varchar(32) not null,descn varchar(255) comment '备注说明，一般在具体表中会创建一些看起来似乎没有什么用的列' 
)egine = innodb default charset utf8 comment '角色信息';

一般在管理系统中，针对普通用户的权限管理是通过菜单项是否显示来实现的，当然服务器端会针对用户的请求进行权限验证

在这里插入图片描述

无限级分类的实现方法为自关联表

create table if not exists tbl_permissions(id bigint primary key auto_increment,parent_id bigint,foreign key(parent_id) references tbl_persimissions(id) on delete cascade
) engine = innodb default charset utf8;

一般为了简化编码，还会引入一些额外列定义，例如 level 层级、是否具有孩子节点、孩子节点个数等

create table if not exists tbl_permissions(id bigint primary key auto_increment,parent_id bigint,foreign key(parent_id) references tbl_persimissions(id) on delete cascade,title varchar(32) not null comment'菜单项名称',url varchar(64) comment '对应的URL地址',descn comment '特别重要的列，用于表示访问当前菜单所需要的权限字符串，例如user:query:1',is_child boolean default  comment '额外列，用于表示是否叶子节点，还经常添加一些其它的列'
)engine=innodb default charset utf8;create table if not exists tbl_role2permission(role_id bigint not null,permission_id bigint not null,primary key(permission_id,role_id),foreign key(permission_id) references tbl_permissions on delete cascade,foreign key(role_id) references tbl_roles on delete cascade
)engine=innodb default charset utf8;

补充：

1、具体权限是否对应到菜单取决于控制等级，如果需要控制到按钮级，则菜单和权限之间多对多关联

2、考虑具体的业务规则，是否有临时授予用户某些权限的可能，如果有则还需要在用户表和权限表之间建立多对多关联

3、是否有用户组

JSON 响应结果

Json 响应枚举类型

public enum ResponseEnum { //列举出本系统业务上的所有的可能情况SUCCESS(200, "成功" ), ERROR(500, "发生未知错误，请联系管理员" )USERNAME_OR_PASSWORD_INVALIDATE(301, "用户名或者密码错误" ), HAVE_NO_RIGHTS(302, "该角色还没有被赋权,请联系管理员" ), NO_LOGIN(303, "还没有登录" ), LOGIN_SUCCESS(304, "登录成功" ),TOKEN_INVALID(305, "token 无效，请先登录" ), TOKEN_EXPIRE(306, "token 已经超时，请重新登录" ), USER_STATUS_ERROR(307, "用户已封禁" ), private int code;private String message;
}

public class JsonResult {private int code;private Boolean success;private String message;private Object data;public JsonResult(ResponseEnum responseEnum, Object data ) {this.code = responseEnum.getCode( );this.message = responseEnum.getMessage( );this.data = data;}
}

补充说明

1、用户组设置。一般来说权限管理系统不需要设置用户组，只要当用户基数较大，角色类型过多时，为了便于管理员进行操作，才会引入用户组的概念。用户组可以理解为，将某个部门的所有人看成一个用户组，再给用户组赋予角色，这个部门的所有人就都有了用户组中角色的权限。对于给群体账号赋予权限，用户组可以提供很大的便利。同时用户组中的账号，除拥有用户组的权限外，还可以拥有指定的角色。