前言:
RBAC是Role-Based Access Control的縮寫, 它幾乎成為權限系統的數據模型的選擇標配.
之前寫個兩篇關於權限系統的文章, 主要涉及如何在應用中實現權限控制, 對權限系統本身的數據模型未着水墨. 權限系統的設計到現在為止, 非常的成熟, 而且網上的資料大而全. 比如這篇博文: 權限系統與RBAC模型概述, 其基本就涵蓋了各類RBAC的權限數據模型的設計, 可根據小/中/大的業務場景進行定制.
本文結合自己的業務場景, 介紹一個小型的后台管理系統的權限系統(RBAC)的數據模型, 權做筆記, ^_^.
相關系列文章:
1. springmvc簡單集成shiro
2. 類Shiro權限校驗框架的設計和實現
設計目標:
最簡化RBAC的數據模型, 同時為了給系統添加一定的靈活度, 即可以單獨給用戶賦予某個特定權限.
這邊把權限定義為:
permission(權限) = resource(資源) + action(動作)
對於資源(resource), 不在細分為頁面(page)級別, 甚至到按鈕(menu)級別. 資源更像一個具體的業務/功能的標記.
對於動作(action), 可以簡單分為read/write/update/delete.
這樣權限(permission)就很容易定義和理解, 比如功能: 查看投訴, 其對應permission為: complaint:read.
role和user都相對獨立, 即role沒有繼承和層次關系, 用戶不再引入組group.
這樣的話, 將大大減少權限的設計, 避免在中小型業務后端, 進行過度設計, 導致工作量膨脹且沒明顯增量收益.
為了系統一定的靈活度, 在單獨引入user到permission的直接映射表, 用於擴展.
數據模型:
對了小型的后台管理系統, 用戶不多, 表可以采用單庫單表, 總之盡量簡單, 這邊的表都保留id字段(主鍵自增)作為約定.
作為最基礎的RBAC表設計:
為了增加靈活性, 單獨添加的用戶到權限的雙向映射表.
事實上, 如果業務規模真的不大, 且權限的粒度較粗, 完全退化為了用戶/權限表模型, 也是可以完全滿足需求的, 而且實現更快.
這邊結合了兩種, 算是一個小復合模式.
后記:
RBAC的權限確實很成熟, 不過還是那句老話, 紙上得來終覺淺, 絕知此事要躬行.
本文權做個人筆記了.