超全面的權限系統設計方案！

前言

權限管理是所有後臺系統的都會涉及的一個重要組成部分，主要目的是對不同的人訪問資源進行權限的控制，避免因權限控制缺失或操作不當引發的風險問題，如操作錯誤，隱私數據泄露等問題。

目前在公司負責權限這塊, 所以對權限這塊的設計比較熟悉, 公司採用微服務架構, 權限系統自然就獨立出來了, 其他業務系統包括商品中心, 訂單中心, 用戶中心, 倉庫系統, 小程序, 多個 APP 等十幾個系統和終端

1. 權限模型

迄今爲止最爲普及的權限設計模型是 RBAC 模型, 基於角色的訪問控制（Role-Based Access Control)

1.1 RBAC0 模型

RBAC0 模型如下:

這是權限最基礎也是最核心的模型, 它包括用戶 / 角色 / 權限, 其中用戶和角色是多對多的關係, 角色和權限也是多對多的關係。

用戶是發起操作的主體, 按類型分可分爲 2B 和 2C 用戶, 可以是後臺管理系統的用戶, 可以是 OA 系統的內部員工, 也可以是面向 C 端的用戶, 比如阿里雲的用戶。

角色起到了橋樑的作用, 連接了用戶和權限的關係, 每個角色可以關聯多個權限, 同時一個用戶關聯多個角色, 那麼這個用戶就有了多個角色的多個權限。

有人會問了爲什麼用戶不直接關聯權限呢？在用戶基數小的系統, 比如 20 個人的小系統，管理員可以直接把用戶和權限關聯，工作量並不大，選擇一個用戶勾選下需要的權限就完事了。

但是在實際企業系統中，用戶基數比較大, 其中很多人的權限都是一樣的，就是個普通訪問權限，如果管理員給 100 人甚至更多授權, 工作量巨大。

這就引入了 "角色 (Role)" 概念, 一個角色可以與多個用戶關聯, 管理員只需要把該角色賦予用戶, 那麼用戶就有了該角色下的所有權限, 這樣設計既提升了效率, 也有很大的拓展性。

是用戶可以訪問的資源, 包括頁面權限, 操作權限, 數據權限:

即用戶登錄系統可以看到的頁面, 由菜單來控制, 菜單包括一級菜單和二級菜單, 只要用戶有一級和二級菜單的權限, 那麼用戶就可以訪問頁面

即頁面的功能按鈕，包括查看, 新增, 修改, 刪除, 審覈等，用戶點擊刪除按鈕時，後臺會校驗用戶角色下的所有權限是否包含該刪除權限。如果是, 就可以進行下一步操作, 反之提示無權限。

有的系統要求 "可見即可操作", 意思是如果頁面上能夠看到操作按鈕, 那麼用戶就可以操作, 要實現此需求, 這裏就需要前端來配合, 前端開發把用戶的權限信息緩存, 在頁面判斷用戶是否包含此權限, 如果有, 就顯示該按鈕, 如果沒有, 就隱藏該按鈕。

某種程度上提升了用戶體驗, 但是在實際場景可自行選擇是否需要這樣做

數據權限就是用戶在同一頁面看到的數據是不同的，比如財務部只能看到其部門下的用戶數據，採購部只看採購部的數據。

在一些大型的公司，全國有很多城市和分公司，比如杭州用戶登錄系統只能看到杭州的數據，上海用戶只能看到上海的數據，解決方案一般是把數據和具體的組織架構關聯起來。

舉個例子, 再給用戶授權的時候, 用戶選擇某個角色同時綁定組織如財務部或者合肥分公司, 那麼該用戶就有了該角色下財務部或合肥分公司下的的數據權限。

以上是 RBAC 的核心設計及模型分析, 此模型也叫做 RBAC0, 而基於核心概念之上, RBAC 還提供了擴展模式。包括 RBAC1,RBAC2,RBAC3 模型。下面介紹這三種類型

1.2 RBAC1 模型

此模型引入了角色繼承 (Hierarchical Role) 概念，即角色具有上下級的關係，角色間的繼承關係可分爲一般繼承關係和受限繼承關係。

一般繼承關係僅要求角色繼承關係是一個絕對偏序關係，允許角色間的多繼承。

而受限繼承關係則進一步要求角色繼承關係是一個樹結構，實現角色間的單繼承。這種設計可以給角色分組和分層，一定程度簡化了權限管理工作。

1.3 RBAC2 模型

基於核心模型的基礎上，進行了角色的約束控制，RBAC2 模型中添加了責任分離關係。

其規定了權限被賦予角色時，或角色被賦予用戶時，以及當用戶在某一時刻激活一個角色時所應遵循的強制性規則。

責任分離包括靜態責任分離和動態責任分離。主要包括以下約束:

同一用戶只能分配到一組互斥角色集合中至多一個角色，支持責任分離的原則。

互斥角色是指各自權限互相制約的兩個角色。比如財務部有會計和審覈員兩個角色, 他們是互斥角色, 那麼用戶不能同時擁有這兩個角色, 體現了職責分離原則

一個角色被分配的用戶數量受限；一個用戶可擁有的角色數目受限；同樣一個角色對應的訪問權限數目也應受限，以控制高級權限在系統中的分配

即用戶想獲得某上級角色, 必須先獲得其下一級的角色

1.4 RBAC3 模型

即最全面的權限管理, 它是基於 RBAC0，將 RBAC1 和 RBAC2 進行了整合。

1.5 用戶組

當平臺用戶基數增大，角色類型增多時，而且有一部分人具有相同的屬性，比如財務部的所有員工，如果直接給用戶分配角色，管理員的工作量就會很大。

如果把相同屬性的用戶歸類到某用戶組，那麼管理員直接給用戶組分配角色，用戶組裏的每個用戶即可擁有該角色，以後其他用戶加入用戶組後，即可自動獲取用戶組的所有角色，退出用戶組，同時也撤銷了用戶組下的角色，無須管理員手動管理角色。

根據用戶組是否有上下級關係, 可以分爲有上下級的用戶組和普通用戶組:

最典型的例子就是部門和職位，可能多數人沒有把部門職位和用戶組關聯起來吧。

當然用戶組是可以拓展的，部門和職位常用於內部的管理系統，如果是面向 C 端的系統。

比如淘寶網的商家，商家自身也有一套組織架構，比如採購部，銷售部，客服部，後勤部等，有些人擁有客服權限，有些人擁有上架權限等等，所以用戶組是可以拓展的

即沒有上下級關係，和組織架構，職位都沒有關係，也就是說可以跨部門，跨職位。

舉個例子，某電商後臺管理系統，有拼團活動管理角色，我們可以設置一個拼團用戶組，該組可以包括研發部的後臺開發人員，運營部的運營人員，採購部的人員等等。

每個公司都會涉及到到組織和職位, 下面就重點介紹這兩個。

1.5.1 組織

常見的組織架構如下圖:

我們可以把組織與角色進行關聯，用戶加入組織後，就會自動獲得該組織的全部角色，無須管理員手動授予，大大減少工作量，同時用戶在調崗時，只需調整組織，角色即可批量調整。

組織的另外一個作用是控制數據權限, 把角色關聯到組織, 那麼該角色只能看到該組織下的數據權限。

1.5.2 職位

假設財務部的職位如下圖:

每個組織部門下都會有多個職位，比如財務部有總監，會計，出納等職位，雖然都在同一部門，但是每個職位的權限是不同的，職位高的擁有更多的權限。

總監擁有所有權限，會計和出納擁有部分權限。特殊情況下, 一個人可能身兼多職。

1.6 含有組織 / 職位 / 用戶組的模型

根據以上場景, 新的權限模型就可以設計出來了, 如下圖:

根據系統的複雜度不同, 其中的多對多關係和一對一關係可能會有變化

1、在單系統且用戶類型單一的情況下，用戶和組織是一對一關係，組織和職位是一對多關係，用戶和職位是一對一關係，組織和角色是一對一關係，職位和角色是一對一關係，用戶和用戶組是多對對關係，用戶組和角色是一對一關係，當然這些關係也可以根據具體業務進行調整。

模型設計並不是死的, 如果小系統不需要用戶組, 這塊是可以去掉的。

2、分佈式系統且用戶類型單一的情況下，到這裏權限系統就會變得很複雜，這裏就要引入了一個 "系統" 概念。

3、此時系統架構是個分佈式系統，權限系統獨立出來，負責所有的系統的權限控制，其他業務系統比如商品中心，訂單中心，用戶中心，每個系統都有自己的角色和權限，那麼權限系統就可以配置其他系統的角色和權限。

4、分佈式系統且用戶類型多個的情況下，比如淘寶網，它的用戶類型包括內部用戶，商家，普通用戶，內部用戶登錄多個後臺管理系統，商家登錄商家中心，這些做權限控制，如果你作爲架構師，該如何來設計呢? 大神可以在評論區留言交流哦!

2. 授權流程

授權即給用戶授予角色, 按流程可分爲手動授權和審批授權。權限中心可同時配置這兩種, 可提高授權的靈活性。

管理員登錄權限中心爲用戶授權，根據在哪個頁面授權分爲兩種方式：給用戶添加角色，給角色添加用戶。

給用戶添加角色就是在用戶管理頁面，點擊某個用戶去授予角色，可以一次爲用戶添加多個角色；給角色添加用戶就是在角色管理頁面，點擊某個角色，選擇多個用戶，實現了給批量用戶授予角色的目的。

即用戶申請某個職位角色，那麼用戶通過 OA 流程申請該角色，然後由上級審批，該用戶即可擁有該角色，不需要系統管理員手動授予。

3. 表結構

有了上述的權限模型, 設計表結構就不難了, 下面是多系統下的表結構, 簡單設計下, 主要提供思路:

4. 權限框架

在項目中可以採用其中一種框架, 它們的優缺點以及如何使用會在後面的文章中詳細介紹。

5. 結語

權限系統可以說是整個系統中最基礎，同時也可以很複雜的，在實際項目中，會遇到多個系統，多個用戶類型，多個使用場景，這就需要具體問題具體分析，但最核心的 RBAC 模型是不變的, 我們可以在其基礎上進行擴展來滿足需求。

來源：

https://segmentfault.com/a/1190000039676989

“IT 大咖說” 歡迎廣大技術人員投稿，投稿郵箱：aliang@itdks.com

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/pe48CciWJ_m3zFlWsNK4nQ

猜你喜歡