B端權限規則模型:RBAC模型
導讀: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 協議
問個問題,如果某列表頁面,對于A和B兩個角色,查看時候展示列有小部分區別,該如何設計呢?
界面權限,標簽權限,字段權限進行權限管理配置設計,可以考慮后期的靈活配置。
還要考慮產品屬性
產品書籍免費下載:https://qr21.cn/BJ3hRM
產品書籍免費下載地址:https://qr21.cn/BJ3hRM
嘎嘎
666
666677
理員和普通用戶被授予不同的權限,普通用戶只能去修改和查看個人信息,而不能創建創建用戶和凍結用戶,而管理員由于被授 予所有權限,所以可以做所有操作。