幾乎任何一個后臺，都會涉及到權(quán)限管理，哪些人（用戶）有能夠登陸，能夠操作哪些東西（權(quán)限）。

基于角色的訪問控制方法（Role-Based Access Control,簡稱RBAC）是目前公認的解決大型企業(yè)的統(tǒng)一資源訪問控制的有效方法。其顯著的兩大特征是：
1、減小授權(quán)管理的復(fù)雜性，降低管理開銷；
2、靈活地支持企業(yè)的安全策略，并對企業(yè)的變化有很大的伸縮性。

RBAC的基本思路

RBAC-0是基于角色的訪問控制方法的最基礎(chǔ)的模型，在原來的“用戶-權(quán)限”結(jié)構(gòu)中加入“角色”的概念，變成“用戶-角色-權(quán)限”結(jié)構(gòu)。
相應(yīng)的權(quán)限管理模塊和功能如下：
用戶管理
提供用戶賬戶的創(chuàng)建、編輯、啟用、停用、刪除的功能。具體依賴于郵箱、手機號或其他信息創(chuàng)建賬號，根據(jù)各公司實際情況而定。

角色管理
角色管理包含了用戶&角色的關(guān)聯(lián)、角色&權(quán)限的關(guān)聯(lián)管理，主要包括以下功能：
1、角色的創(chuàng)建、編輯、刪除的功能，
2、角色下用戶的添加和刪除
3、角色權(quán)限的配置功能

角色管理功能示意

這種結(jié)構(gòu)中，創(chuàng)建不同的角色，將權(quán)限直接賦予角色，用戶只需關(guān)聯(lián)角色即可獲得該角色的所對應(yīng)的權(quán)限。這樣做的好處是：
1、不用每個用戶都設(shè)置一遍權(quán)限，只需設(shè)置角色的權(quán)限。
2、用戶角色變化時，比如 從銷售轉(zhuǎn)崗到產(chǎn)品，只需將用戶的角色做變更，相應(yīng)的權(quán)限就會變更。

除了RBAC-0之外，還有RBAC-1、RBAC-2、RBAC-3，會放在文末供大家了解，為避免影響文章邏輯，在此不做詳述。

數(shù)據(jù)權(quán)限是功能權(quán)限的延伸

常見的權(quán)限需求有兩類：功能權(quán)限和數(shù)據(jù)權(quán)限。
功能權(quán)限
1、菜單級別的權(quán)限：可見性
2、頁面元素級別權(quán)限：可操作性
比如上面舉例的DBAC-0的設(shè)計方案就屬于功能權(quán)限，對于一級菜單和二級菜單來說，如果沒有權(quán)限，就不展示該菜單，即可見性；對于權(quán)限明細來說，如果沒有該權(quán)限，則操作時報錯，比如點擊時toast提示“對不起，您沒有該操作權(quán)限”，即可操作性。

數(shù)據(jù)權(quán)限
數(shù)據(jù)權(quán)限簡單說就是功能給你用，數(shù)據(jù)不給看。比如，查看銷售記錄的功能，用戶A和B都有權(quán)限使用，但A有權(quán)看到公司所有人的，B只能看到他自己的銷售記錄。這就涉及到數(shù)據(jù)權(quán)限的控制了。

涉及數(shù)據(jù)權(quán)限的權(quán)限管理需求會比單純的功能權(quán)限復(fù)雜一些，但數(shù)據(jù)權(quán)限的依賴于功能權(quán)限，是對功能權(quán)限的進一步描述，說明角色在指定的功能點上的數(shù)據(jù)控制權(quán)限。

角色的數(shù)據(jù)權(quán)限管理

首先，有一個約定，為了降低開發(fā)成本，數(shù)據(jù)權(quán)限一般采用“沒有明確規(guī)定即視為有效”的原則，如果沒有定義功能的數(shù)據(jù)權(quán)限，則說明該角色具有該功能的全部權(quán)限。如果定義了功能的某種類型的數(shù)據(jù)權(quán)限，則該用戶只具有該類型下指定數(shù)據(jù)的數(shù)據(jù)權(quán)限。

這個與功能權(quán)限的設(shè)定是剛好相反的，功能權(quán)限是有指定才有權(quán)限，不指定就沒有權(quán)限。

繼續(xù)上面提到的設(shè)計方案，假如需求背景進一步明確：
張三、李四、王五為業(yè)務(wù)一部，公司一共3個業(yè)務(wù)部，還有業(yè)務(wù)二部、業(yè)務(wù)三部，小紅為業(yè)務(wù)一部經(jīng)理，小明為銷售部總經(jīng)理。要求按照組織架構(gòu)查看訂單信息：業(yè)務(wù)員只能查看個人、業(yè)務(wù)經(jīng)理可以查看自己業(yè)務(wù)部的所有訂單，總經(jīng)理可以查看自己事業(yè)部的所有訂單信息。

首先在數(shù)據(jù)權(quán)限中明確兩個概念，數(shù)據(jù)類型和數(shù)據(jù)對象。
數(shù)據(jù)類型即數(shù)據(jù)中的某一個字段，數(shù)據(jù)對象即數(shù)據(jù)類型的值。
比如A部門的人不能看B部門的數(shù)據(jù)，則對于A部門的人來說，其數(shù)據(jù)權(quán)限的數(shù)據(jù)類型就是“部門”，數(shù)據(jù)對象就是A。

基于上述需求設(shè)計方案相應(yīng)的進一步調(diào)整如下：
組織架構(gòu)
首先要有組織架構(gòu)數(shù)據(jù)庫，用于權(quán)限控制時調(diào)用。

組織架構(gòu)簡圖

業(yè)務(wù)員角色

一部業(yè)務(wù)經(jīng)理角色

銷售部經(jīng)理角色

對于數(shù)據(jù)權(quán)限來說，可根據(jù)需要設(shè)置多個數(shù)據(jù)類型字段，比如部門、商戶類型等，基于數(shù)據(jù)的字段來控制權(quán)限。

以上，是基于整理的RBAC資料梳理的權(quán)限管理功能設(shè)計思路，方案上可能有些欠妥，畢竟不是真實已落地的方案，歡迎大家留言指正，如果有真實案例分享也歡迎推薦呀

附文

補上RBAC的另外幾種延伸形式
1、RBAC-1
RBAC1引入角色間的繼承關(guān)系，角色間的繼承關(guān)系可分為一般繼承關(guān)系和受限繼承關(guān)系。一般繼承關(guān)系僅要求角色繼承關(guān)系是一個絕對偏序關(guān)系，允許角色間的多繼承。而受限繼承關(guān)系則進一步要求角色繼承關(guān)系是一個樹結(jié)構(gòu)。
2、RBAC-2
RBAC2模型中添加了責任分離關(guān)系。RBAC2的約束規(guī)定了權(quán)限被賦予角色時,或角色被賦予用戶時,以及當用戶在某一時刻激活一個角色時所應(yīng)遵循的強制性規(guī)則。
責任分離包括靜態(tài)責任分離和動態(tài)責任分離。

靜態(tài)責任分離
1、互斥角色限制：同一個用戶在兩個互斥的角色中只能選擇一個
2、角色數(shù)量限制：一個用戶擁有的角色數(shù)是有限的，同樣的權(quán)限也會是有限的
3、角色先后限制：用戶要擁有更高級的角色，首先要有相應(yīng)的低級角色
動態(tài)責任分離
4、角色激活限制：如一個用戶允許擁有兩個角色，但運行時只能激活一個角色

約束與用戶-角色-權(quán)限關(guān)系一起決定了RBAC2模型中用戶的訪問許可。

3、RBAC-3
RBAC3包含了RBAC1和RBAC2，既提供了角色間的繼承關(guān)系，又提供了責任分離關(guān)系。