起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識后臺基于RBAC模型的用戶與權限設計
本文作者結合實際經驗，跟大家談談后臺基于RBAC模型的用戶與權限是如何設計的，一起來看看~
一、項目背景
1.1 需求來源
前段時間，筆者所在公司收到了多個客戶對后臺權限和角色的需求。討論發現，現有的產品后臺架構并不能很好的滿足用戶需求，所以為了滿足這些客戶的需求并為之后可能存在的業務拓展打下基礎，我們決定對現有產品的后臺用戶體系進行迭代。
1.2?需求的拆解
通過過濾需求，我們發現其實用戶的需求主要是兩類：
- 是要求我們的用戶體系可以承載用戶多級分銷的業務模式并滿足各級分銷之間數據權限的要求；
- 是要求我們完善對用戶權限的控制。
二、理論依據
涉及到后臺用戶管理系統，繞不開的概念就是權限，任何一個賬號都會有自己的用例。但是多數情況下，我們對部分賬號的用例會做一些限制，如果直接將這種限制加在賬號上，就會產生二個問題：
- 每個賬號都要配置很麻煩；
- 無法批量修改一類用戶的權限。
所以角色的誕生就呼之欲出了，我們通過對權限集的抽象，創立了角色，通過修改角色，來達到控制擁有該角色的賬號的權限修改的目的。
權限可以分為數據權限和功能權限兩大類：
- 數據權限顧名思義，就是賬號能查看多少數據，如何實現A部門與B部門之間相互不能查看業務數據，這個就涉及到數據權限；
- 功能權限按照范圍以大致菜單權限和按鈕權限，按照操作可以大致分為查看和編輯權限。
2.1 RBAC-0模型
2.1.1?簡述
RBAC-0 模型的特點就是用戶和角色是多對多的關系，同一個用戶擁有多個角色的屬性，我們通過組織這個概念來構建組織架構，從而實現對角色數據權限的分配。這樣單個用戶賬號擁有的全部權限就是他所在組織的權限的累加。
2.1.2?舉例
在RBAC-0模型中，A用戶負責X組織的業務，B用戶負責Y組織的財務工作。正常情況下，A和B自然不能查看對方的數據，但是如果有天，B由于業務需要需要協助處理X組織的財務，那我們就可以通過為B用戶添加X組織的“財務”角色來實現這種需求。在業務結束后，也可以通過暫停/刪除操作來管理B在X組織下的權限。
2.2 RBAC-1模型
基于RBAC-0模型，針對角色引人繼承的概念，子角色可以對父角色的權限進行繼承，但是子角色的權限一定小于父角色。
2.3 RBAC-2模型
相較RBAC-0系統，RBAC-2系統在用戶與角色間和角色與角色之間加入了一些規則。
- 單個角色允許分配的用戶數限制，例如一個公司不可能有多無限個“董事會”角色；
- 單個用戶允許授予的角色數限制，例如單個用戶不允許在一個公組織或多個組織擔任無限多個職務；
- 角色與角色有層級關系，例如想新增一個部門經理，不能用一個部門職員的賬號去創建吧？
- 角色與角色存在互斥關系，這個根據實際業務需要來做限制，例如銷售不能兼任會計。
2.4 RBAC-3模型
RBAC-3模型也叫統一模型，它基于了RBAC-0，并包含了RBAC-1和RBAC-2模型的全部特點。
三、設計過程
3.1 新增賬號的屬性
新增賬號是用戶體系的最基本的功能，新增賬號時需要獲取賬號的哪些參數決定了整個用戶體系的數據維度。
這里不得不提的就是USER_ID，登錄賬號，昵稱的概念。
USER_ID：對應的是賬號在系統中唯一標識，可以不展示給用戶,例如微信的open_id和union_id，一般在新增賬號時由系統生成，且不可修改；
登陸賬號：登錄賬號和USER_ID在有的系統并不一致，同一個USER_ID可能對應著多個登錄賬號，例如微信可以通過微信號，手機號，郵箱去登錄，這里的不同登陸方式都對應這一個登陸賬號，一般在新增賬號時，由用戶輸入，且不可修改；
昵稱：昵稱是用戶可以自由編輯操作的，由用戶輸入，且允許修改。
3.2 功能權限的處理方式
功能權限通過對角色的權限樹進行修改來實現。在權限樹種我們可以將頁面權限，菜單權限和按鈕權限羅列，通過篩選對應權限完成對角色功能權限的控制。
需要注意的一個問題是，權限控制的最小粒度。如果要實現每一個權限的控制，相當于每一個權限對應功能都需要做封裝。大的頁面和菜單權限是必備的，但是哪些按鈕權限是可以封裝在一起的，（比如“啟用”和“暫?！币话愣际浅蓪Τ霈F的），這些是需要產品考慮的。
3.3?數據權限的處理方式
數據權限其實是角色權限的重要屬性，但是由于數據范圍太靈活，如果在角色加入“數據權限”tab，如果賬號下的數據量較大，用戶編輯數據權限的操作會很繁瑣。因此，因此現在主流的后臺設計都會使用“組織結構”來對應數據權限。
在系統中，我們使用了【新增組織】的方式，來處理數據權限。
3.4?對老用戶的兼容
在做用戶體系的重構時，老用戶的賬號兼容問題是產品必須考慮的部分。兼容問題也是從功能和數據兩個維度去驗證新的體系是否對老用戶是否有影響。
四、總結
文章的內容主要是本次迭代中實際的使用場景，抱著他山之石可以攻玉的想法，參考了現有的資料，結合自己系統的實際情況，對用戶體系設計做了一次小結。若有不足之處，還請大家多多溝通，共同進步。
本文由@幸失 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自 Unsplash ，基于 CC0 協議
你好，角色等級是怎么體現出來的？
樓主你好，以下對文中的理解與問題：
1. 權限樹是頁面權限、菜單權限和按鈕權限的羅列，那如果本身菜單級別就有2個層級，再加上按鈕權限那這個權限樹就至少3級了。
2. 每個頁面的按鈕不同，是不是增加或修改一個頁面都要過來修改權限樹呀？
3. 數據權限不在權限樹中體現，而是通過組織實現，相當于除了角色、用戶、權限之外引入了一個組織來做數據權限的管理？
12 一起討論吧，首先實際頁面和按鈕在不同系統中實際上不一定是強耦合，頁面其實更多體現的是一個信息結構。我們業務中更傾向將菜單和按鈕強耦合。 我舉個例子，同一按鈕功能的多個入口，如果我們強行將頁面插入菜單或者按鈕之上，就如你所說，加個頁面就要調整權限樹。這種顯然是不合理的，所以我們盡量要鎖定權限樹的枝干部分(菜單)，而按鈕這種葉子類目是可以調整的
3 你說得對，權限可以分功能權限和數據權限，用戶和權限是基礎。至于角色是包涵兩類權限還是只包涵功能權限，這完全取決于業務。 如果系統本身是有組織架構概念，由于組織架構本身就和數據權限息息相關，建議是角色做的簡單一點，側重功能全選，數據權限最好只做分類(只看平級，只看下級這種)。
數據權限那里，新增組織會進行什么操作呢？
新增組織相當于創建了一個數據隔離的小單元，可以將賬號添加進該單元，這樣該賬號在該單元的數據就對其他賬號做了數據隔離。
數據權限可不可以詳細展開講一下呢？怎么選擇數據范圍之類的。之前看到的文章是頁面權限優先操作權限優選于數據權限。所以一直考慮的是選好頁面權限，再選擇操作權限，在選擇相應的數據權限。這樣又特別繁瑣
“組織”在產品中的體現是什么呢？是樹形的層級架構？
組織是“組織架構”的最小可操作性單元。