后台系统设计——角色权限
一、前言
不論是哪種后臺管理系統，“人員權限”始終是繞不開的話題。無論是移動端，PC端產品，登陸都需要一個賬號。只是對于C端的產品，大多都是用戶自己注冊即可。
而對于后臺產品而言，是需要公司內部人員去創建賬號的。每個使用系統的用戶都有一個獨一無二的賬號，每個賬號都有自己對應的權限。
多數情況下，除了超級管理員外，我們會對大多數的賬號的權限做一些限制，以此來管理不同用戶的使用權限問題。
譬如，做企業使用類軟件，不同部門、不同職位的人的權限是不同的；再例如一款收費產品的收費用戶和免費用戶權限也是迥然不同的。
如果每個用戶都單獨做權限控制的話，當系統用戶體量非常大的時候，就會發現以下問題：
很多賬號權限都是一樣的，但每次都要再配一次；
當某類權限用戶的權限需要修改時，無法批量修改，只能一個個去修改非常耗時；
二、經典模型——RBAC
這時候，聰明的產品先人就創建了“角色”的概念，通過對權限集的抽象，創立了角色，通過修改角色的權限，來控制擁有該角色的人員賬號的權限。
1、RBAC——基于角色的訪問控制（Role-Based Access Control ）
其基本思想是，對系統操作的各種權限不是直接授予具體的用戶，而是在用戶集合與權限集合之間建立一個角色集合。每一種角色對應一組相應的權限。一旦用戶被分配了適當的角色后，該用戶就擁有此角色的所有操作權限。
這樣做的好處是，不必在每次創建用戶時都進行分配權限的操作，只要分配用戶相應的角色即可，而且角色的權限變更比用戶的權限變更要少得多，這樣將簡化用戶的權限管理，減少系統的開銷。
按照百度百科對RBAC的定義，我們可以理解為此模型是通過角色關聯用戶，角色關聯權限的方式，間接賦予用戶權限。
2、分類
RBAC 模型分為RBAC0、RBAC1、RBAC2、RBAC3
RBAC0：是RBAC的核心思想。完全支持RBAC概念的任何系統的最低需求。
RBAC1：是把RBAC的角色分層模型。增加了角色分級的概念，一個角色可以從另一個角色繼承許可權。
RBAC2：增加了RBAC的約束模型。增加了一些限制，強調在RBAC的不同組件中在配置方面的一些限制。
RBAC3：其實是RBAC2 + RBAC1。稱為統一模型，它包含了RBAC1和RBAC2，利用傳遞性，也把RBAC0包括在內。這些模型構成了RBAC96模型族；
下面，我以最為基礎的RBAC0為例來講下角色權限體系：
三、RBAC0
1.用戶-角色-權限之間的關系
通過上面的分析，我們已經知道，在這個模型里，涉及到3個專有名詞，那就是用戶、角色、權限，下面是我對這3個詞的簡單定義：
用戶：使用系統的人；
角色：權限的的集合；
權限：數據權限、功能權限（頁面權限+操作權限）；
在這個RBAC0模型中，我們把權限賦予角色，再把用戶關聯角色來繼承角色所對應的權限。用戶和角色，角色和權限都是多對多的關系。用戶擁有的權限等于他所有的角色持有權限的并集；
?
?
接下來我們一一來剖析，如何把這3個名詞巧妙的聯合，來打造一個完整的系統用戶權限管理。
2.用戶管理
?
?
新增用戶有2個關鍵點，第一是需要關聯角色，第二是關聯組織部門。
關聯角色：我們通過RBAC0模型的關系圖1已經知道，用戶與角色之間是多對多的關系，所以如圖2中的用戶“吳京”，關聯了戰狼、偽裝者的角色，那么他就擁有戰狼、偽裝者這2個角色權限的并集。
用戶權限亦可單獨修改，修改用戶的權限不影響角色本身的權限。如修改角色權限會修改角色下關聯的所有用戶的對應權限。
關聯組織部門：什么是組織部門呢？且看下回分解——權限管理；
2.權限管理
權限可以分為數據權限、功能權限兩大類：
數據權限
顧名思義，就是賬號能查看哪些數據，例如當一個公司存在多個獨立的運營中心時，如何保證每個運營中心信息的獨立性，如何實現運營中心之間相互不能查看業務數據，這個就涉及到數據權限。
數據權限一般通過數據權限樹來控制，那什么是數據權限樹呢？
數據權限樹在一定程度上等于公司的組織結構，當然我們可以根據公司的特性去修改，并不一定要嚴格按照公司的部門結構來建立，只要能讓此結構更為方便的為公司服務即可，如下圖
?
例如：當一個公司旗下有3個子公司，那么每個子公司都是一個獨立的業務部門，這樣，在給每個子公司的用戶配置權限時，只需要給他配置其子公司下的數據即可；
當業務單據需要跨公司的時候，可能需要做些特殊的處理，比如建單的時候，在選擇公司時，權限放開，因為并不能確定哪些公司之間會有合作。
查詢頁面的顯示原則：凡涉及本公司業務的單據，擁有該公司業務數據權限的人皆可以查看。以電商中常見的倉庫調撥單為例：
?
此單據可以查看的人員有：
A公司擁有業務組1權限的人員+B公司有B倉權限的業務組的所有人員。有點拗口哈，但不妨礙我們把事兒說清楚。
功能權限
功能權限是頁面權限+操作權限的集合。頁面權限是指你的系統分為哪些個頁面，比如說銷售單查詢頁、商品庫存頁等等。操作權限是指頁面上能看到的：查詢、新增、刪除、導出等等操作。
頁面權限：所有系統都是由一個個的頁面組成，用戶是否能看到這個頁面的菜單、是否能進入這個頁面就稱為頁面權限。
操作權限：用戶凡是在操作系統中在任何頁面做的任何動作，都是操作權限，如增、刪、改、查、導出、審核等等。
?
以后臺系統功能權限為例，如圖4，一般來說，功能權限的配置方式都是以模塊+頁面名稱+頁面對應的操作為模型進行配置的，這樣配置既清晰，出錯的概率也比較小。
3.角色管理
角色管理是RBAC0模型的關鍵，以下是角色管理的圖文說明：角色的建立主要包括3個模塊，基礎信息功能權限、數據權限。
其中基礎信息和功能權限為必填，數據權限可選填。數據權限一般在用戶的賬號上再進行配置。
如果角色適用于所有的組織機構那么就可以配上數據權限，如角色是針對于某一個組織機構建立的，那配置數據權限反而是累贅。
例如：以圖3的公司結構為例，如果每個子公司都有自己的財務，并且最后需要匯總到總公司的財務體系下，這時系統如果只建立1個財務角色，那此時，就只需要配置功能權限，數據權限在新增用戶的時候對總公司的財務、分公司的財務配置不同的數據權限即可；
如果系統如果分別建立2個及以上個財務角色，1個叫總公司財務，一個叫子公司1財務、子公司1財務，那么每個財務角色就可以在新建的時候把數據權限、功能權限都配置好，新建用戶的時候就無需再去配置。
具體角色應該怎么新建，各公司可根據自身的實際情況進行靈活配置。
?
四、總結
RBAC0模型基本可以滿足任何一個系統去建立一套相對完整的權限體系，當然它也存在著一些不足，比如：
一個用戶擁有多個角色，多角色之間如果存在互斥關系如何處理？
當角色存在層級關系時如何給角色建立層級關系？
......
這時候我們就需要引入以下這些升級模型：
1、RBAC1：是把RBAC的角色分層模型。增加了角色分級的概念，一個角色可以從另一個角色繼承權限。
?
2、RBAC2：增加了RBAC的約束模型。添加了責任分離關系，規定了權限被賦予角色時，或角色被賦予用戶時，以及當用戶在某一時刻激活一個角色時所應遵循的強制性規則。
互斥角色: 同一用戶只能分配到一組互斥角色集合中至多一個角色，支持責任分離的原則。互斥角色是指各自權限互相制約的兩個角色。比如財務部有會計和審核員兩個角色,他們是互斥角色,那么用戶不能同時擁有這兩個角色,體現了職責分離原則
基數約束: 一個角色被分配的用戶數量受限；一個用戶可擁有的角色數目受限；同樣一個角色對應的訪問權限數目也應受限，以控制高級權限在系統中的分配
先決條件角色: 即用戶想獲得某上級角色,必須先獲得其下一級的角色
3、RBAC3：其實是RBAC2 + RBAC1。稱為統一模型，它包含了RBAC1和RBAC2，利用傳遞性，也把RBAC0包括在內。
以上是我根據自己主導過，使用過的系統，得出的對角色權限系統的歸納和總結，有不足之處，希望大家多多交流。
鏈接：https://www.jianshu.com/p/29c2d7721924
總結
以上是生活随笔為你收集整理的后台系统设计——角色权限的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 调光调压调功智能控制器
- 下一篇： springboot自动创建Oracle