一、目的

管理系統(tǒng)用戶的功能菜單權限，物理資源（文件、數(shù)據(jù)）權限。

二、RBAC模型設計

RBAC簡介

BAC模型（Role-Based Access Control：基于角色的訪問控制）模型是一種權限實現(xiàn)模型，是系統(tǒng)權限設計中的一套方法論。

RBAC認為權限授權的過程可以抽象地概括為：Who是否可以對What進行How的訪問操作，并對這個邏輯表達式進行判斷是否為True的求解過程，也即是將權限問題轉(zhuǎn)換為Who、What、How的問題，Who、What、How構成了訪問權限三元組。

RBAC模型的核心對象為：用戶、角色、權限

資源管理簡介

系統(tǒng)資源可分為邏輯資源和物理資源。邏輯資源如軟件系統(tǒng)的菜單、頁面、按鈕等等；物理資源如視頻文件、音頻文件、pdf文件等等。

其中邏輯資源可以通過權限來控制，物理資源可通過在角色下設置資源列表，通過角色關聯(lián)資源列表實現(xiàn)，也可直接將用戶和資源列表關聯(lián)實現(xiàn)。

權限管理模型設計

所有的權限管理最終都要落到用戶身上。

功能權限E-R設計

• 以RBAC0模型為基礎建立核心業(yè)務實體：單位（公司/部委/組織機構）、部門（科室）、用戶、角色、權限
• 使用關聯(lián)實體為核心業(yè)務實體建立映射關系：用戶角色、角色權限等
• 為方便數(shù)據(jù)查詢和業(yè)務拓展，增加單位權限、單位角色映射關系。此兩項非必須。
• 可按照RBAC1模型的設計思路，增加角色組，用戶關聯(lián)角色組、角色組關聯(lián)角色，角色關聯(lián)權限。從而實現(xiàn)更細粒度的權限管理。
• 可按照RBAC1模型的思想，將部門和用戶的映射關系修改為m:n，將能夠?qū)崿F(xiàn)一個用戶歸屬多個組織的權限管理。如分公司的董事長同時兼任集團公司部門領導的情況。其中隱含了單位和部門關系為多對多，部門和用戶關系為多對多。當用戶登錄的時候，讓用戶自己選擇需要在哪個組織下工作。鑒于這種情況的項目相對而言為少數(shù)，大部分項目沒有那么復雜的組織架構，可以對外提供兩套解決方案。

資源權限E-R設計

業(yè)務弱關聯(lián)性設計

建立如下資源和業(yè)務實體的映射關系：

• 資源本身作為一個業(yè)務實體，為資源劃分類型
• 資源和單位建立映射關系，用戶隸屬于單位
• 資源和部門建立映射關系，用戶隸屬于部門
• 資源和角色建立映射關系，用戶關聯(lián)角色
• 資源和行政區(qū)劃建立映射關系，用戶關聯(lián)行政區(qū)劃或部門關聯(lián)行政區(qū)劃或單位關聯(lián)行政區(qū)劃
• 拓展：資源和XXX業(yè)務實體建立映射關系，用戶關聯(lián)XXX業(yè)務實體

優(yōu)點：資源和業(yè)務實體為弱關聯(lián)性，可封裝成微服務組件對外賦能
缺點：關系模式更加復雜，開發(fā)、運維成本高

業(yè)務強關聯(lián)性設計

基于組織架構、職權（角色）、業(yè)務歸屬、區(qū)域、坐標等的業(yè)務實體建立如下映射關系：

• 數(shù)據(jù)權限的管理最簡單的維度就是基于功能權限的管理
• 根據(jù)業(yè)務數(shù)據(jù)歸屬分別建立用戶和數(shù)據(jù)的映射關系
• 根據(jù)業(yè)務數(shù)據(jù)所屬業(yè)務閘口、區(qū)域（行政區(qū)域，地緣，自定義劃區(qū)）和業(yè)務實體建立映射關系，業(yè)務實體最終落到用戶上
• 根據(jù)業(yè)務數(shù)據(jù)治理出來的坐標體系建立映射管理
• 其他維度的數(shù)據(jù)權限管理

優(yōu)點：方便和業(yè)務集成、遷移順滑
缺點：和業(yè)務強綁定

三、緩存設計

可能出現(xiàn)的問題：
1：用戶權限信息龐大，往redis中存儲大數(shù)據(jù)塊
2：用戶權限信息龐大，Mysql數(shù)據(jù)庫查詢效率低

四、認證服務設計

認證服務負責用戶登錄狀態(tài)的維護，對請求方簽發(fā)令牌；管理權限信息。
基于具體的業(yè)務形態(tài)，認證服務可劃分為兩類：內(nèi)部系統(tǒng)用戶認證和權限管理；自建開放平臺用戶認證和權限管理。
//TODO 后續(xù)抽時間設計

總結

以上是生活随笔為你收集整理的功能、资源权限管理的设计的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。