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