微服務與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、用戶組設置。一般來說權限管理系統不需要設置用戶組，只要當用戶基數較大，角色類型過多時，為了便于管理員進行操作，才會引入用戶組的概念。用戶組可以理解為，將某個部門的所有人看成一個用戶組，再給用戶組賦予角色，這個部門的所有人就都有了用戶組中角色的權限。對于給群體賬號賦予權限，用戶組可以提供很大的便利。同時用戶組中的賬號，除擁有用戶組的權限外，還可以擁有指定的角色。