本文作者結合實際經驗，跟大家談談后臺基于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 協議