結合RBAC模型講解權限管理系統需求及表結構建立

在本號以前的文章中，已經爲你們介紹了不少關於Spring Security的使用方法，也介紹了RBAC的基於角色權限控制模型。可是不少朋友雖然已經理解了RBAC控制模型，可是仍有不少的問題阻礙他們進一步開發。好比：

• RBAC模型的表結構該如何建立？
• 具體到某個頁面，某個按鈕權限是如何控制的？
• 爲了配合登陸驗證表，用戶表中應該包含哪些核心字段？
• 這些字段與登陸驗證或權限分配的需求有什麼關係？

那麼本文就但願將這些問題，與你們進行一下分享。

1、回顧RBAC權限模型

• 用戶與角色之間是多對多的關係，一個用戶有多個角色，一個角色包含多個用戶
• 角色與權限之間是多對多關係，一個角色有多種權限，一個權限能夠屬於多個角色

上圖中：

• User是用戶表，存儲用戶基本信息
• Role是角色表，存儲角色相關信息
• Menu(菜單)是權限表，存儲系統包含哪些菜單及其屬性
• UserRole是用戶和角色的關係表
• RoleMenu是角色和權限的關係表

本文講解只將權限控制到菜單的訪問級別，即控制頁面的訪問權限。若是想控制到頁面中按鈕級別的訪問，能夠參考Menu與RoleMenu的模式一樣的實現方式。或者乾脆在menu表裏面加上一個字段區別該條記錄是菜單項仍是按鈕。

爲了有理有據，咱們參考一個比較優秀的開源項目：若依後臺管理系統。

2、組織部門管理

2.1.需求分析

之因此先將部門管理提出來說一下，是由於部門管理沒有在咱們上面的RBAC權限模型中進行提現。可是部門這樣一個實體仍然是，後端管理系統的一個重要組成部分。一般有以下的需求：

• 部門要能體現出上下級的結構（如上圖中的紅框）。在關係型數據庫中。這就須要使用到部門id及上級部門id，來組合成一個樹形結構。這個知識是SQL學習中必備的知識，若是您還不知道，請自行學習。
• 若是組織與用戶之間是一對多的關係，就在用戶表中加上一個org_id標識用戶所屬的組織。原則是：實體關係在多的那一邊維護。好比：是讓老師記住本身的學生容易，仍是讓學生記住本身的老師更容易？
• 若是組織與用戶是多對多關係，這種狀況現實需求也有可能存在。好比：某人在某單位既是生產部長，又是技術部長。因此他及歸屬於技術部。也歸屬於生產部。對於這種狀況有兩種解決方案，把該人員放到公司級別，而不是放到部門級別。另一種就是從數據庫結構上建立User與Org組織之間的多對多關係。
• 組織信息包含一些基本信息，如組織名稱、組織狀態、展示排序、建立時間
• 另外，要有基本的組織的增刪改查功能

2.2 組織部門表的CreateSQL

如下SQL以MySQL爲例:

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)。

3、菜單權限管理

3.1 需求分析

• 由上圖能夠看出，菜單仍然是樹形結構，因此數據庫表必須有id與menu_pid字段
• 必要字段：菜單跳轉的url、是否啓用、菜單排序、菜單的icon矢量圖標等
• 最重要的是菜單要有一個權限標誌，具備惟一性。一般可使用菜單跳轉的url路徑做爲權限標誌。此標誌做爲權限管理框架識別用戶是否具備某個頁面查看權限的重要標誌
• 須要具有菜單的增刪改查基本功能
• 若是但願將菜單權限和按鈕超連接相關權限放到同一個表裏面，能夠新增一個字段。用戶標誌該權限記錄是菜單訪問權限仍是按鈕訪問權限。

3.2 菜單權限表的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
;

4、角色管理

上圖爲角色修改及分配權限的頁面

4.1.需求分析

• 角色自己的管理須要注意的點很是少，就是簡單的增刪改查。重點在於角色分配該如何作。
• 角色表包含角色id，角色名稱，備註、排序順序這些基本信息就足夠了
• 爲角色分配權限：以角色爲基礎勾選菜單權限或者操做權限，而後先刪除sys_role_menu表內該角色的全部記錄，在將新勾選的權限數據逐條插入sys_role_menu表。
• sys_role_menu的結構很簡單，記錄role_id與menu_id，一個角色擁有某一個權限就是一條記錄。
• 角色要有一個全局惟一的標識，由於角色自己也是一種權限。能夠經過判斷角色來判斷某用戶的操做是否合法。
• 一般的需求：不會在角色管理界面爲角色添加用戶，而是在用戶管理界面爲用戶分配角色。

4.2.角色表與角色菜單權限關聯表的的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
;

5、用戶管理

5.1.需求分析

• 上圖中點擊左側的組織菜單樹結點，要能顯示出該組織下的全部人員（系統用戶）。在組織與用戶是一對多的關係中，須要在用戶表加上org_id字段，用於查詢某個組織下的全部用戶。
• 用戶表中要保存用戶的用戶名、加密後的密碼。頁面提供密碼修改或重置的功能。
• 角色分配:實際上爲用戶分配角色，與爲角色分配權限的設計原則是同樣的。因此能夠參考。
• 實現用戶基本信息的增刪改查功能

5.2.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  '用戶帳戶鎖定到期時間',
        `expired_time` TIMESTAMP NULL  '用戶帳戶過時時間',
        `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
;

在用戶的信息表中，體現了一些隱藏的需求。如：屢次登陸鎖定與鎖定到期時間的關係。帳號有效期的設定規則等。

固然用戶表中，根據業務的不一樣還可能加更多的信息，好比：用戶頭像等等。可是一般在比較大型的業務系統開發中，業務模塊中使用的用戶表和在權限管理模塊使用的用戶表一般不是一個，而是根據某些惟一字段弱關聯，分開存放。這樣作的好處在於：常常發生變化的業務需求，不會去影響不常常變化的權限模型。

期待您的關注

• 向您推薦博主的系列文檔：《手摸手教您學習SpringBoot系列-16章97節》
• 本文轉載註明出處（必須帶鏈接，不能只轉文字）：字母哥博客。