使用者許可權設計(三)——通用資料許可權管理系統設計
通用資料許可權管理系統設計
作者:逸雲
前言:
本文提供一種整合功能許可權和資料許可權的解決方法,以滿足多層次組織中許可權管理方面的集中控制。本方法是RBAC(基於角色的訪問控制方法)的進一步擴充套件和延伸,即在功能許可權的基礎上增加資料許可權的管理,實現資料許可權和功能許可權的集中處理。
解釋:
功能許可權:能做什麼的問題,如增加銷售訂單;
資料許可權:能在哪裡幹什麼的問題,如察看北京分公司海淀銷售部張三的銷售訂單;
術語:
資源:系統中的資源,主要是各種業務物件,如銷售單、付款單等;
操作型別:對資源可能的訪問方法,如增加、刪除、修改等;
功能:對資源的操作,是資源與操作型別的二元組,如增加銷售單、修改銷售單等;
資料型別:業務系統中常用的資料許可權型別,如公司、部門、專案、個人等;
資料物件:具體的業務物件,如甲公司、乙部門等等,包括所有涉及到資料許可權的物件值;
許可權:角色可使用的功能,分角色的功能許可權和角色的資料許可權;
角色:特定許可權的集合;
使用者:參與系統活動的主體,如人,系統等。
通用資料許可權管理系統設計(二)
方法說明:
在實際應用中,資料許可權的控制點一般相對固定,如針對公司、部門、個人、客戶、供應商等,也就是說資料許可權一般針對指定資料型別下的一些資料物件。
本方法中,資料許可權的依賴於功能許可權,是對功能許可權的進一步描述,說明角色在指定的功能點上的資料控制許可權。
本方法中採用“沒有明確規定即視為有效”的原則,如果沒有定義功能的資料許可權,則說明該角色具有該功能的全部的許可權。如果定義了功能的某種型別的資料許可權,則該使用者只具有該型別下指定資料的資料許可權。
這段話比較繞口,下面舉個例子實際例子。
某公司有北京銷售部、上海銷售部和廣州銷售部三個銷售部,現在需要定義幾種角色:
銷售總監 -- 能察看所有銷售部的銷售訂單;
北京銷售經理 -- 只能察看北京銷售部的所有銷售訂單;
上海銷售經理 -- 只能察看上海銷售部的所有銷售訂單;
廣州銷售經理 -- 只能察看廣州銷售部的所有銷售訂單;
上述角色的定義如下:
-------------------------------------------------------------------
角色名稱 功能 資料型別 資料物件
-------------------------------------------------------------------
銷售總監 察看銷售訂單
北京銷售經理 察看銷售訂單 部門 北京
上海銷售經理 察看銷售訂單 部門 上海
廣州銷售經理 察看銷售訂單 部門 廣州
-------------------------------------------------------------------
上述定義中,銷售總監只定義了功能許可權,而沒有定義資料許可權,所以銷售總監能夠察看所有的銷售訂單;而其他幾位銷售經理分別定義了這一功能的資料許可權,所以只能察看指定部門的銷售訂單。
在實際應用中,往往會出現部門分組,組長能夠察看本組所有人員處理的銷售訂單的情況,以及某些情況下,某些人只能察看本人的銷售訂單的情況,這些特殊情況在上述的說明中無法解決,需要在設計和實現中進行處理。
北京銷售代表 -- 只能察看北京銷售部的本人的所有銷售訂單;
北京銷售代表 察看銷售訂單 部門 北京
個人
通用資料許可權管理系統設計(三)--資料庫設計
我們先來看看傳統的基於角色的許可權管理系統,如下圖所示,最簡單的基於角色的許可權管理由系統功能、系統角色、系統使用者、角色功能和使用者角色五部分組成。

圖一:基於角色的資料庫結構
為實現資料許可權控制,在設計上對基於角色的許可權管理進行擴充,如下圖所示:

圖二:通用資料許可權管理系統資料庫設計
對比兩張圖,我們可以看到,他們之間的主要變化為:
1、 增加系統資源資訊和操作型別資訊,系統資源為樹形結構、如銷售模組、銷售訂單等;操作型別記錄可能的操作,如增加、刪除、修改、檢視、查詢等,系統功能是資源與操作型別的組合,對資源的操作就是系統功能。
2、 增加資料物件型別和資料物件兩張表,資料物件型別記錄系統中需要控制的物件型別,如部門、庫房、員工、客戶、供應商等;資料物件記錄各物件型別的物件例項,如北京銷售部、上海銷售部、張三、李四等等。(獨立儲存的好處後面會說到)
3、 增加系統資源與資料物件型別的關聯表(多對多),本表為配置表,說明某種資源可能需要的控制點,如銷售訂單與部門型別的關聯可能涉及到分部門分配許可權;銷售訂單與客戶的關聯可能涉及到按客戶分配許可權等等。
4、 增加資料物件與角色許可權的關聯,這張表是真正最終實現資料許可權管理的所在地。
通過這種設計,能夠最小化地減少對原有許可權系統的更改,並且可以很靈活地增加資料的控制點。在產品化軟體的設計中使用,能夠靈活滿足客戶的需要。
相關文章
- 通用許可權系統之資料庫表設計資料庫
- 許可權系統:許可權應用服務設計
- 許可權系統:6個許可權概念模型設計模型
- 許可權系統:許可權應用服務設計Tu
- 許可權設計
- 如何設計應用系統的資料許可權管理
- learun通用許可權系統框架功能實現設計框架
- 許可權系統:一文搞懂功能許可權、資料許可權
- 管理系統之許可權的設計和實現
- JavaWeb許可權設計原理JavaWeb
- android 許可權元件設計Android元件
- SpringSecurity許可權管理系統實戰—九、資料許可權的配置SpringGse
- 授權許可權服務設計解析
- Rbac使用者角色許可權表設計
- Spring Security + jwt 許可權系統設計,包含SQLSpringJWTSQL
- 分散式系統中,許可權設計實踐分散式
- 關於系統許可權的設計-位操作
- ubuntu 許可權管理設定Ubuntu
- 資料許可權就該這麼設計,yyyds!
- 帶你學習DWS資料庫使用者許可權設計與管理資料庫
- 手把手擼套框架-許可權系統設計框架
- PingCode Wiki 許可權設計之ACLGC
- 選單許可權和按鈕許可權設定
- Linux系統程式設計(七)檔案許可權系統呼叫Linux程式設計
- 淺談許可權管理的設計與實現
- 企業許可權管理系統
- Winner許可權管理系統3.0
- 若依管理系統RuoYi-Vue(二):許可權系統設計詳解Vue
- SAP Basis DEBUG改表資料許可權角色設計
- PostgreSQL資料庫使用者許可權管理SQL資料庫
- 基於SSM框架的JavaWeb通用許可權管理系統SSM框架JavaWeb
- 基於Spring Security和 JWT的許可權系統設計SpringJWT
- Confluence6對比系統管理員許可權和Confluence管理員許可權
- 資料庫的許可權管理資料庫
- 基於RBAC的許可權設計模型模型
- 許可權安全管控的設計想法
- 資料湖統一後設資料與許可權
- mysql使用者許可權管理MySql
- Vue2.0 + ElementUI 手寫許可權管理系統後臺模板(二)——許可權管理VueUI