本文作者結合實際經驗，跟大家談談背景基于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 功能權限的處理方式
功能權限通過對角色的權限樹進行修改來實作。在權限樹種我們可以将頁面權限，菜單權限和按鈕權限羅列，通過篩選對應權限完成對角色功能權限的控制。
需要注意的一個問題是，權限控制的最小粒度。如果要實作每一個權限的控制，相當于每一個權限對應功能都需要做封裝。大的頁面和菜單權限是必備的，但是哪些按鈕權限是可以封裝在一起的，(比如“啟用”和“暫停”一般都是成對出現的)，這些是需要産品考慮的。
3.3 資料權限的處理方式
資料權限其實是角色權限的重要屬性，但是由于資料範圍太靈活，如果在角色加入“資料權限”tab，如果賬号下的資料量較大，使用者編輯資料權限的操作會很繁瑣。是以，是以現在主流的背景設計都會使用“組織結構”來對應資料權限。
在系統中，我們使用了【新增組織】的方式，來處理資料權限。
3.4 對老使用者的相容
在做使用者體系的重構時，老使用者的賬号相容問題是産品必須考慮的部分。相容問題也是從功能和資料兩個次元去驗證新的體系是否對老使用者是否有影響。
四、總結
文章的内容主要是本次疊代中實際的使用場景，抱着他山之石可以攻玉的想法，參考了現有的資料，結合自己系統的實際情況，對使用者體系設計做了一次小結。若有不足之處，還請大家多多溝通，共同進步。
本文由@幸失 原創釋出于人人都是産品經理。未經許可，禁止轉載
題圖來自 Unsplash ，基于 CC0 協定