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

在本號之前的文章中，已經為大家介紹了很多關於spring security的使用方法，也介紹了rbac的基於角色許可權控制模型。但是很多朋友雖然已經理解了rbac控制模型，但是仍有很多的問題阻礙他們進一步開發。比如：

上圖中：

本文講解只將許可權控制到選單的訪問級別，即控制頁面的訪問許可權。如果想控制到頁面中按鈕級別的訪問，可以參考menu與rolemenu的模式同樣的實現方式。或者乾脆在menu表裡面加上乙個字段區別該條記錄是選單項還是按鈕。

之所以先將部門管理提出來講一下，是因為部門管理沒有在我們上面的rbac許可權模型中進行提現。但是部門這樣乙個實體仍然是，後端管理系統的乙個重要組成部分。通常有如下的需求：

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

`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='系統選單表'

上圖為角色修改及分配許可權的頁面

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='角色選單多對多關聯表'
`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
;

在使用者的資訊表中，體現了一些隱藏的需求。如：多次登入鎖定與鎖定到期時間的關係。賬號有效期的設定規則等。

當然使用者表中，根據業務的不同還可能加更多的資訊，比如：使用者頭像等等。但是通常在比較大型的業務系統開發中，業務模組中使用的使用者表和在許可權管理模組使用的使用者表通常不是乙個，而是根據某些唯一欄位弱關聯，分開存放。這樣做的好處在於：經常發生變化的業務需求，不會去影響不經常變化的許可權模型。

RBAC許可權模型

rbac role based access control，基於角色的訪問控制 就是使用者通過角色與許可權進行關聯。簡單地說，乙個使用者擁有若干角色，每乙個角色擁有若干許可權。這樣，就構造成 使用者 角色 許可權 的授權模型。在這種模型中，使用者與角色之間，角色與許可權之間，一般者是多對多的關係。...

RBAC許可權管理

rbac role based access control，基於角色的訪問控制 就是使用者通過角色與許可權進行關聯。簡單地說，乙個使用者擁有若干角色，每乙個角色擁有若干許可權。這樣，就構造成 使用者 角色 許可權 的授權模型。在這種模型中，使用者與角色之間，角色與許可權之間，一般者是多對多的關係。...

RBAC許可權管理

rbac role based access control，基於角色的訪問控制 就是使用者通過角色與許可權進行關聯。簡單地說，乙個使用者擁有若干角色，每乙個角色擁有若干許可權。這樣，就構造成 使用者 角色 許可權 的授權模型。在這種模型中，使用者與角色之間，角色與許可權之間，一般者是多對多的關係。...