1. 程式人生 > >RBAC最少需要幾張表,簡述實現原理

RBAC最少需要幾張表,簡述實現原理

RBAC:
基於角色的許可權訪問控制(Role-Base-Access Control)


從RBAC0到RBAC3分別需要5到12張表
1. RBAC0
RBAC0是RBAC中的基礎模型,後續的模型都是RBAC0的改進
RBAC0引入了角色概念來解決使用者與許可權之間的分離問題,使用者實際上沒有許可權,而只有給使用者賦予某種角色之後,才擁有相應的許可權.
RBAC0主要解決了許可權的分離問題


資料表模型:
我們需要5張表來完成RBAC0
分別是:
1.使用者表(User)
欄位:使用者名稱,密碼
2.角色表(Role)
欄位:角色名,角色父ID
3.許可權表(Permission)
欄位:許可權名,類方法名,許可權父ID
4.許可權角色關聯表(PA) ->多對多
欄位:角色ID,許可權ID
5.使用者角色關聯表(UA) ->多對多
欄位:使用者ID,角色ID


現在我們實現了一個基本的RBAC0的基礎模型
我們來對這個模型加以改進:
當用戶數量過多的時候,我們需要引入使用者組的概念.角色不僅可以對使用者進行關聯,也可以對使用者組進行關聯,所現在我們需要新增三張表
新增以下三張表
6. 使用者組表(UserGroup)
7. 使用者組角色關聯表(UGA)
8. 使用者組與使用者關聯表(UUG)
在公司中,我們還有所謂的上下級關係,一個部門部長下面要管理副部長,經理等等.這時我們就要引入角色的繼承關係來表示上下級關係,體現在資料表上,就要新增一張角色繼承表
9.角色繼承關係表
到了這一步我們基本上實現了RBAC1的標準規範
而在角色的繼承中,我們其實對繼承的角色許可權也要加以控制,畢竟不可能讓繼承過來的角色擁有父角色的所有許可權,所以就需要多加一張對來對繼承的角色進行許可權約束
10.角色許可權約束
我們除了對角色進行約束,其實還可以對使用者來進行一些相關的約束來更好的保證整個系統的責任鏈分離,如果你也添加了使用者的約束規則,那麼我們就基本上達到了RBAC2的規範了
11.使用者啟用約束
在這個基礎上,我們再來看看許可權授權這一部分
這時候,如果我們需要判定的功能許可權太多,那麼就可以將許可權劃分模組,然後統一將角色授權給某個模組.
12.許可權模組表
13.許可權模組與許可權關聯表
14.角色與模組的關係表
到此個人認為已經達到了比較完善的RBAC許可權控制