導讀：B端項目上，需要設計實現一個權限管理模塊，就要知道到一個很重要的RBAC模型，所以整理總結了RBAC的一些知識。目前，使用最普遍的權限管理模型正是RBAC（Role-Based Access Control）模型，這篇文章主要是介紹基于RBAC的權限管理系統，將會從RBAC是什么、如何設計RBAC兩部分來介紹。

一、RBAC模型是什么?

1. RBAC模型概述

RBAC模型（Role-Based Access Control：基于角色的訪問控制）模型是20世紀90年代研究出來的一種新模型，但其實在20世紀70年代的多用戶計算時期，這種思想就已經被提出來，直到20世紀90年代中后期，RBAC才在研究團體中得到一些重視，并先后提出了許多類型的RBAC模型。其中以美國George Mason大學信息安全技術實驗室（LIST）提出的RBAC96模型最具有代表，并得到了普遍的公認。

RBAC認為權限授權的過程可以抽象地概括為：Who是否可以對What進行How的訪問操作，并對這個邏輯表達式進行判斷是否為True的求解過程，也即是將權限問題轉換為What、How的問題，Who、What、How構成了訪問權限三元組，具體的理論可以去調查RBAC96的研究文件，這里就不做詳細的展開介紹，讓大家有個了解和即可。

2. RBAC的組成

在RBAC模型里面，有3個基礎組成部分，分別是：用戶、角色和權限。

RBAC通過定義角色的權限，并對用戶授予某個角色從而來控制用戶的權限，實現了用戶和權限的邏輯分離（區別于ACL模型），極大地方便了權限的管理。

下面在講解之前，先介紹一些名詞：

User（用戶）：每個用戶都有唯一的UID識別，并被授予不同的角色

Role（角色）：不同角色具有不同的權限

Permission（權限）：訪問權限

用戶-角色映射：用戶和角色之間的映射關系

角色-權限映射：角色和權限之間的映射

它們之間的關系如下圖所示：

例如下圖，管理員和普通用戶被授予不同的權限，普通用戶只能去修改和查看個人信息，而不能創建創建用戶和凍結用戶，而管理員由于被授 予所有權限，所以可以做所有操作。

例如下圖，管理員和普通用戶被授予不同的權限，普通用戶只能去修改和查看個人信息，而不能創建創建用戶和凍結用戶，而管理員由于被授予所有權限，所以可以做所有操作。

3. RBAC支持的安全原則

RBAC支持三個著名的安全原則：最小權限原則、責任分離原則和數據抽象原則。

最小權限原則：RBAC可以將角色配置成其完成任務所需的最小權限集合。

責任分離原則：可以通過調用相互獨立互斥的角色來共同完成敏感的任務，例如要求一個計賬員和財務管理員共同參與統一過賬操作。

數據抽象原則：可以通過權限的抽象來體現，例如財務操作用借款、存款等抽象權限，而不是使用典型的讀、寫、執行權限。

4. RBAC的優缺點

優點：簡化了用戶和權限的關系易擴展、易維護。

缺點：RBAC模型沒有提供操作順序的控制機制，這一缺陷使得RBAC模型很難適應哪些對操作次序有嚴格要求的系統。

5. RBAC的3種模型

1）RBAC0

RBAC0，是最簡單、最原始的實現方式，也是其他RBAC模型的基礎。

在該模型中，用戶和角色之間可以是多對多的關系，即一個用戶在不同場景下是可以有不同的角色，例如：項目經理也可能是組長也可能是架構師。同時每個角色都至少有一個權限。這種模型下，用戶和權限被分離獨立開來，使得權限的授權認證更加靈活。

A、權限是用戶可以訪問的資源，包括頁面權限、操作權限、數據權限。

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

b、操作權限： 即頁面的功能按鈕，包括查看、新增、修改、刪除、審核等，用戶點擊刪除按鈕時，后臺會校驗用戶角色下的所有權限是否包含該刪除權限，如果是，就可以進行下一步操作，反之提示無權限。有的系統要求”可見即可操作”，意思是如果頁面上能夠看到操作按鈕，那么用戶就可以操作，要實現此需求，這里就需要前端來配合，前端開發把用戶的權限信息緩存，在頁面判斷用戶是否包含此權限，如果有，就顯示該按鈕，如果沒有，就隱藏該按鈕。某種程度上提升了用戶體驗，但是在實際場景可自行選擇是否需要這樣做。

c、數據權限：數據權限就是用戶在同一頁面看到的數據是不同的，比如財務部只能看到其部門下的用戶數據，采購部只看采購部的數據，在一些大型的公司，全國有很多城市和分公司，比如杭州用戶登錄系統只能看到杭州的數據，上海用戶只能看到上海的數據，解決方案一般是把數據和具體的組織架構關聯起來，舉個例子，再給用戶授權的時候，用戶選擇某個角色同時綁定組織如財務部或者合肥分公司，那么該用戶就有了該角色下財務部或合肥分公司下的的數據權限。

2）RBAC1

基于RBAC0模型，引入了角色間的繼承關系，即角色上有了上下級的區別。

角色間的繼承關系可分為一般繼承關系和受限繼承關系。一般繼承關系僅要求角色繼承關系是一個絕對偏序關系，允許角色間的多繼承。而受限繼承關系則進一步要求角色繼承關系是一個樹結構，實現角色間的單繼承。

A、數據范圍的繼承

我們可以將用戶進行分級管理，比如建立多層級的組織架構樹，將不同用戶放置于組織架構的不同根節點上，來實現多層級用戶的建立和管理。

如果用戶的層級如果比較簡單（不多于三級），可以將層級關系融入到角色之中。

比如用戶分為三級：管理員-組長-組員，管理員能看到全部的數據范圍和擁有全部的功能權限，而組長能查看組員的數據范圍和擁有部分功能權限（比如無法編輯用戶），而組員的數據范圍僅僅為自己負責的數據和擁有部分功能權限。

我們可以在組長這個角色下，允許其綁定組員，針對不同的角色設置不同的數據范圍讀取方式，管理員可以讀取全部數據范圍，組長需要讀取其組員的，組員只能讀取自己的。這種模型適合于角色之間層次分明，可以給角色分組分層。

RBAC2：

RBAC2，基于RBAC0模型的基礎上，進行了角色的訪問控制。

RBAC2中的一個基本限制是互斥角色的限制，互斥角色是指各自權限可以互相制約的兩個角色。對于這類角色一個用戶在某一次活動中只能被分配其中的一個角色，不能同時獲得兩個角色的使用權。

該模型有以下幾種約束：

互斥角色 ：同一用戶只能分配到一組互斥角色集合中至多一個角色，支持責任分離的原則?；コ饨巧侵父髯詸嘞藁ハ嘀萍s的兩個角色。對于這類角色一個用戶在某一次活動中只能被分配其中的一個角色，不能同時獲得兩個角色的使用權。常舉的例子：在審計活動中，一個角色不能同時被指派給會計角色和審計員角色。

基數約束 ：一個角色被分配的用戶數量受限；一個用戶可擁有的角色數目受限；同樣一個角色對應的訪問權限數目也應受限，以控制高級權限在系統中的分配。例如公司的領導人有限的；

先決條件角色 ：可以分配角色給用戶僅當該用戶已經是另一角色的成員；對應的可以分配訪問權限給角色，僅當該角色已經擁有另一種訪問權限。指要想獲得較高的權限，要首先擁有低一級的權限。

運行時互斥 ：例如，允許一個用戶具有兩個角色的成員資格，但在運行中不可同時激活這兩個角色。

RBAC3：

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

二、如何設計RBAC?

介紹設計基于RBAC模型的權限系統的功能模塊組成、流程以及數據庫的設計。

1. RBAC的功能模塊

2. RBAC執行流程

3. RBAC數據庫設計

4. 用戶組

平臺用戶基數增大，角色類型增多時，而且有一部分人具有相同的屬性，比如財務部的所有員工,如果直接給用戶分配角色，管理員的工作量就會很大，如果把相同屬性的用戶歸類到某用戶組，那么管理員直接給用戶組分配角色，用戶組里的每個用戶即可擁有該角色，以后其他用戶加入用戶組后，即可自動獲取用戶組的所有角色，退出用戶組，同時也撤銷了用戶組下的角色，無須管理員手動管理角色。

根據用戶組是否有上下級關系,可以分為有上下級的用戶組和普通用戶組。

具有上下級關系的用戶組：最典型的例子就是部門和職位，可能多數人沒有把部門職位和用戶組關聯起來吧。當然用戶組是可以拓展的，部門和職位常用于內部的管理系統，如果是面向C端的系統，比如淘寶網的商家，商家自身也有一套組織架構，比如采購部，銷售部，客服部，后勤部等，有些人擁有客服權限，有些人擁有上架權限等等，所以用戶組是可以拓展的。

普通用戶組：即沒有上下級關系，和組織架構，職位都沒有關系，也就是說可以跨部門，跨職位,舉個例子，某電商后臺管理系統，有拼團活動管理角色，我們可以設置一個拼團用戶組，該組可以包括研發部的后臺開發人員，運營部的運營人員，采購部的人員等等。

5. 組織

常見的組織架構如下圖：

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

6. 授權流程

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

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

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

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

三、整理總結：

1. RBACM模型

RBAC0、RBAC1、RBAC2、RBAC3

RBAC0：是RBAC的核心思想。

RBAC1：RBAC基礎上增加了角色分層模型。

RBAC2：RBAC基礎上增加了約束模型。

RBAC3：其實是RBAC2 + RBAC1。

2. 權限

1) 權限賦予

權限賦予是把當前用戶的權限拉出來，然后分配的客服可以小于等于當前用戶的權限。

2) 權限加載

正常的加載權限，當用戶登錄后，并且第一次使用權限判斷的時候， Shiro（頁面框架） 會去加載權限。

3) 權限判斷

走正常用戶權限判斷，但是數據操作需要判斷是不是當前歸屬的用戶的數據，其實這個是屬于業務層，就算你不是客服，也是需要判斷。

(4) 禁用|啟用

禁用啟用，也是正常的用戶流程，添加到禁用列表里，如果被禁用，就無法操作任何內容。

本文由 @K 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自 Pexels，基于 CC0 協議