點(diǎn)擊關(guān)注公眾號(hào)，實(shí)用技術(shù)文章及時(shí)了解

前言

權(quán)限管理是所有后臺(tái)系統(tǒng)的都會(huì)涉及的一個(gè)重要組成部分，主要目的是對(duì)不同的人訪問資源進(jìn)行權(quán)限的控制，避免因權(quán)限控制缺失或操作不當(dāng)引發(fā)的風(fēng)險(xiǎn)問題，如操作錯(cuò)誤，隱私數(shù)據(jù)泄露等問題。

目前在公司負(fù)責(zé)權(quán)限這塊, 所以對(duì)權(quán)限這塊的設(shè)計(jì)比較熟悉, 公司采用微服務(wù)架構(gòu), 權(quán)限系統(tǒng)自然就獨(dú)立出來了, 其他業(yè)務(wù)系統(tǒng)包括商品中心, 訂單中心, 用戶中心, 倉庫系統(tǒng), 小程序, 多個(gè) APP 等十幾個(gè)系統(tǒng)和終端

◆ 1. 權(quán)限模型

迄今為止最為普及的權(quán)限設(shè)計(jì)模型是 RBAC 模型, 基于角色的訪問控制（Role-Based Access Control)

1.1 RBAC0 模型

RBAC0 模型如下:

這是權(quán)限最基礎(chǔ)也是最核心的模型, 它包括用戶 / 角色 / 權(quán)限, 其中用戶和角色是多對(duì)多的關(guān)系, 角色和權(quán)限也是多對(duì)多的關(guān)系。

用戶是發(fā)起操作的主體, 按類型分可分為 2B 和 2C 用戶, 可以是后臺(tái)管理系統(tǒng)的用戶, 可以是 OA 系統(tǒng)的內(nèi)部員工, 也可以是面向 C 端的用戶, 比如阿里云的用戶。

角色起到了橋梁的作用, 連接了用戶和權(quán)限的關(guān)系, 每個(gè)角色可以關(guān)聯(lián)多個(gè)權(quán)限, 同時(shí)一個(gè)用戶關(guān)聯(lián)多個(gè)角色, 那么這個(gè)用戶就有了多個(gè)角色的多個(gè)權(quán)限。

有人會(huì)問了為什么用戶不直接關(guān)聯(lián)權(quán)限呢？在用戶基數(shù)小的系統(tǒng), 比如 20 個(gè)人的小系統(tǒng)，管理員可以直接把用戶和權(quán)限關(guān)聯(lián)，工作量并不大，選擇一個(gè)用戶勾選下需要的權(quán)限就完事了。

但是在實(shí)際企業(yè)系統(tǒng)中，用戶基數(shù)比較大, 其中很多人的權(quán)限都是一樣的，就是個(gè)普通訪問權(quán)限，如果管理員給 100 人甚至更多授權(quán), 工作量巨大。

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

• 權(quán)限：

是用戶可以訪問的資源, 包括頁面權(quán)限, 操作權(quán)限, 數(shù)據(jù)權(quán)限:

• 頁面權(quán)限:

即用戶登錄系統(tǒng)可以看到的頁面, 由菜單來控制, 菜單包括一級(jí)菜單和二級(jí)菜單, 只要用戶有一級(jí)和二級(jí)菜單的權(quán)限, 那么用戶就可以訪問頁面

• 操作權(quán)限:

即頁面的功能按鈕，包括查看, 新增, 修改, 刪除, 審核等，用戶點(diǎn)擊刪除按鈕時(shí)，后臺(tái)會(huì)校驗(yàn)用戶角色下的所有權(quán)限是否包含該刪除權(quán)限。如果是, 就可以進(jìn)行下一步操作, 反之提示無權(quán)限。

有的系統(tǒng)要求 "可見即可操作", 意思是如果頁面上能夠看到操作按鈕, 那么用戶就可以操作, 要實(shí)現(xiàn)此需求, 這里就需要前端來配合, 前端開發(fā)把用戶的權(quán)限信息緩存, 在頁面判斷用戶是否包含此權(quán)限, 如果有, 就顯示該按鈕, 如果沒有, 就隱藏該按鈕。

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

• 數(shù)據(jù)權(quán)限:

數(shù)據(jù)權(quán)限就是用戶在同一頁面看到的數(shù)據(jù)是不同的，比如財(cái)務(wù)部只能看到其部門下的用戶數(shù)據(jù)，采購部只看采購部的數(shù)據(jù)。

在一些大型的公司，全國有很多城市和分公司，比如杭州用戶登錄系統(tǒng)只能看到杭州的數(shù)據(jù)，上海用戶只能看到上海的數(shù)據(jù)，解決方案一般是把數(shù)據(jù)和具體的組織架構(gòu)關(guān)聯(lián)起來。

舉個(gè)例子, 再給用戶授權(quán)的時(shí)候, 用戶選擇某個(gè)角色同時(shí)綁定組織如財(cái)務(wù)部或者合肥分公司, 那么該用戶就有了該角色下財(cái)務(wù)部或合肥分公司下的的數(shù)據(jù)權(quán)限。

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

1.2 RBAC1 模型

此模型引入了角色繼承 (Hierarchical Role) 概念，即角色具有上下級(jí)的關(guān)系，角色間的繼承關(guān)系可分為一般繼承關(guān)系和受限繼承關(guān)系。

一般繼承關(guān)系僅要求角色繼承關(guān)系是一個(gè)絕對(duì)偏序關(guān)系，允許角色間的多繼承。

而受限繼承關(guān)系則進(jìn)一步要求角色繼承關(guān)系是一個(gè)樹結(jié)構(gòu)，實(shí)現(xiàn)角色間的單繼承。這種設(shè)計(jì)可以給角色分組和分層，一定程度簡化了權(quán)限管理工作。

1.3 RBAC2 模型

基于核心模型的基礎(chǔ)上，進(jìn)行了角色的約束控制，RBAC2 模型中添加了責(zé)任分離關(guān)系。

其規(guī)定了權(quán)限被賦予角色時(shí)，或角色被賦予用戶時(shí)，以及當(dāng)用戶在某一時(shí)刻激活一個(gè)角色時(shí)所應(yīng)遵循的強(qiáng)制性規(guī)則。

責(zé)任分離包括靜態(tài)責(zé)任分離和動(dòng)態(tài)責(zé)任分離。主要包括以下約束:

• 互斥角色:

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

互斥角色是指各自權(quán)限互相制約的兩個(gè)角色。比如財(cái)務(wù)部有會(huì)計(jì)和審核員兩個(gè)角色, 他們是互斥角色, 那么用戶不能同時(shí)擁有這兩個(gè)角色, 體現(xiàn)了職責(zé)分離原則

• 基數(shù)約束:

一個(gè)角色被分配的用戶數(shù)量受限；一個(gè)用戶可擁有的角色數(shù)目受限；同樣一個(gè)角色對(duì)應(yīng)的訪問權(quán)限數(shù)目也應(yīng)受限，以控制高級(jí)權(quán)限在系統(tǒng)中的分配

• 先決條件角色:

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

1.4 RBAC3 模型

即最全面的權(quán)限管理, 它是基于 RBAC0，將 RBAC1 和 RBAC2 進(jìn)行了整合。

1.5 用戶組

當(dāng)平臺(tái)用戶基數(shù)增大，角色類型增多時(shí)，而且有一部分人具有相同的屬性，比如財(cái)務(wù)部的所有員工，如果直接給用戶分配角色，管理員的工作量就會(huì)很大。

如果把相同屬性的用戶歸類到某用戶組，那么管理員直接給用戶組分配角色，用戶組里的每個(gè)用戶即可擁有該角色，以后其他用戶加入用戶組后，即可自動(dòng)獲取用戶組的所有角色，退出用戶組，同時(shí)也撤銷了用戶組下的角色，無須管理員手動(dòng)管理角色。

根據(jù)用戶組是否有上下級(jí)關(guān)系, 可以分為有上下級(jí)的用戶組和普通用戶組:

• 具有上下級(jí)關(guān)系的用戶組:

最典型的例子就是部門和職位，可能多數(shù)人沒有把部門職位和用戶組關(guān)聯(lián)起來吧。

當(dāng)然用戶組是可以拓展的，部門和職位常用于內(nèi)部的管理系統(tǒng)，如果是面向 C 端的系統(tǒng)。

比如淘寶網(wǎng)的商家，商家自身也有一套組織架構(gòu)，比如采購部，銷售部，客服部，后勤部等，有些人擁有客服權(quán)限，有些人擁有上架權(quán)限等等，所以用戶組是可以拓展的

• 普通用戶組:

即沒有上下級(jí)關(guān)系，和組織架構(gòu)，職位都沒有關(guān)系，也就是說可以跨部門，跨職位。

舉個(gè)例子，某電商后臺(tái)管理系統(tǒng)，有拼團(tuán)活動(dòng)管理角色，我們可以設(shè)置一個(gè)拼團(tuán)用戶組，該組可以包括研發(fā)部的后臺(tái)開發(fā)人員，運(yùn)營部的運(yùn)營人員，采購部的人員等等。

每個(gè)公司都會(huì)涉及到到組織和職位, 下面就重點(diǎn)介紹這兩個(gè)。

1.5.1 組織

常見的組織架構(gòu)如下圖:

我們可以把組織與角色進(jìn)行關(guān)聯(lián)，用戶加入組織后，就會(huì)自動(dòng)獲得該組織的全部角色，無須管理員手動(dòng)授予，大大減少工作量，同時(shí)用戶在調(diào)崗時(shí)，只需調(diào)整組織，角色即可批量調(diào)整。

組織的另外一個(gè)作用是控制數(shù)據(jù)權(quán)限, 把角色關(guān)聯(lián)到組織, 那么該角色只能看到該組織下的數(shù)據(jù)權(quán)限。

1.5.2 職位

假設(shè)財(cái)務(wù)部的職位如下圖:

每個(gè)組織部門下都會(huì)有多個(gè)職位，比如財(cái)務(wù)部有總監(jiān)，會(huì)計(jì)，出納等職位，雖然都在同一部門，但是每個(gè)職位的權(quán)限是不同的，職位高的擁有更多的權(quán)限。

總監(jiān)擁有所有權(quán)限，會(huì)計(jì)和出納擁有部分權(quán)限。特殊情況下, 一個(gè)人可能身兼多職。

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

根據(jù)以上場景, 新的權(quán)限模型就可以設(shè)計(jì)出來了, 如下圖:

根據(jù)系統(tǒng)的復(fù)雜度不同, 其中的多對(duì)多關(guān)系和一對(duì)一關(guān)系可能會(huì)有變化

1、在單系統(tǒng)且用戶類型單一的情況下，用戶和組織是一對(duì)一關(guān)系，組織和職位是一對(duì)多關(guān)系，用戶和職位是一對(duì)一關(guān)系，組織和角色是一對(duì)一關(guān)系，職位和角色是一對(duì)一關(guān)系，用戶和用戶組是多對(duì)對(duì)關(guān)系，用戶組和角色是一對(duì)一關(guān)系，當(dāng)然這些關(guān)系也可以根據(jù)具體業(yè)務(wù)進(jìn)行調(diào)整。

模型設(shè)計(jì)并不是死的, 如果小系統(tǒng)不需要用戶組, 這塊是可以去掉的。

2、分布式系統(tǒng)且用戶類型單一的情況下，到這里權(quán)限系統(tǒng)就會(huì)變得很復(fù)雜，這里就要引入了一個(gè) "系統(tǒng)" 概念。

3、此時(shí)系統(tǒng)架構(gòu)是個(gè)分布式系統(tǒng)，權(quán)限系統(tǒng)獨(dú)立出來，負(fù)責(zé)所有的系統(tǒng)的權(quán)限控制，其他業(yè)務(wù)系統(tǒng)比如商品中心，訂單中心，用戶中心，每個(gè)系統(tǒng)都有自己的角色和權(quán)限，那么權(quán)限系統(tǒng)就可以配置其他系統(tǒng)的角色和權(quán)限。

4、分布式系統(tǒng)且用戶類型多個(gè)的情況下，比如淘寶網(wǎng)，它的用戶類型包括內(nèi)部用戶，商家，普通用戶，內(nèi)部用戶登錄多個(gè)后臺(tái)管理系統(tǒng)，商家登錄商家中心，這些做權(quán)限控制，如果你作為架構(gòu)師，該如何來設(shè)計(jì)呢? 大神可以在評(píng)論區(qū)留言交流哦!

◆ 2. 授權(quán)流程

授權(quán)即給用戶授予角色, 按流程可分為手動(dòng)授權(quán)和審批授權(quán)。權(quán)限中心可同時(shí)配置這兩種, 可提高授權(quán)的靈活性。

• 手動(dòng)授權(quán):

管理員登錄權(quán)限中心為用戶授權(quán)，根據(jù)在哪個(gè)頁面授權(quán)分為兩種方式：給用戶添加角色，給角色添加用戶。

給用戶添加角色就是在用戶管理頁面，點(diǎn)擊某個(gè)用戶去授予角色，可以一次為用戶添加多個(gè)角色；給角色添加用戶就是在角色管理頁面，點(diǎn)擊某個(gè)角色，選擇多個(gè)用戶，實(shí)現(xiàn)了給批量用戶授予角色的目的。

• 審批授權(quán):

即用戶申請(qǐng)某個(gè)職位角色，那么用戶通過 OA 流程申請(qǐng)?jiān)摻巧缓笥缮霞?jí)審批，該用戶即可擁有該角色，不需要系統(tǒng)管理員手動(dòng)授予。

◆ 3. 表結(jié)構(gòu)

有了上述的權(quán)限模型, 設(shè)計(jì)表結(jié)構(gòu)就不難了, 下面是多系統(tǒng)下的表結(jié)構(gòu), 簡單設(shè)計(jì)下, 主要提供思路:

◆ 4. 權(quán)限框架

• Apache Shrio

• Spring Security

在項(xiàng)目中可以采用其中一種框架, 它們的優(yōu)缺點(diǎn)以及如何使用會(huì)在后面的文章中詳細(xì)介紹。

◆ 5. 結(jié)語

權(quán)限系統(tǒng)可以說是整個(gè)系統(tǒng)中最基礎(chǔ)，同時(shí)也可以很復(fù)雜的，在實(shí)際項(xiàng)目中，會(huì)遇到多個(gè)系統(tǒng)，多個(gè)用戶類型，多個(gè)使用場景，這就需要具體問題具體分析，但最核心的 RBAC 模型是不變的, 我們可以在其基礎(chǔ)上進(jìn)行擴(kuò)展來滿足需求。

--完--
推薦閱讀：
怎么接私貨？這個(gè)渠道你100%有用！請(qǐng)收藏！
喜歡文章，點(diǎn)個(gè)在看