本文作者結(jié)合實(shí)際經(jīng)驗(yàn)，跟大家談?wù)労笈_(tái)基于RBAC模型的用戶與權(quán)限是如何設(shè)計(jì)的，一起來看看~

一、項(xiàng)目背景

1.1 需求來源

前段時(shí)間，筆者所在公司收到了多個(gè)客戶對(duì)后臺(tái)權(quán)限和角色的需求。討論發(fā)現(xiàn)，現(xiàn)有的產(chǎn)品后臺(tái)架構(gòu)并不能很好的滿足用戶需求，所以為了滿足這些客戶的需求并為之后可能存在的業(yè)務(wù)拓展打下基礎(chǔ)，我們決定對(duì)現(xiàn)有產(chǎn)品的后臺(tái)用戶體系進(jìn)行迭代。

1.2?需求的拆解

通過過濾需求，我們發(fā)現(xiàn)其實(shí)用戶的需求主要是兩類：

• 是要求我們的用戶體系可以承載用戶多級(jí)分銷的業(yè)務(wù)模式并滿足各級(jí)分銷之間數(shù)據(jù)權(quán)限的要求；
• 是要求我們完善對(duì)用戶權(quán)限的控制。

二、理論依據(jù)

涉及到后臺(tái)用戶管理系統(tǒng)，繞不開的概念就是權(quán)限，任何一個(gè)賬號(hào)都會(huì)有自己的用例。但是多數(shù)情況下，我們對(duì)部分賬號(hào)的用例會(huì)做一些限制，如果直接將這種限制加在賬號(hào)上，就會(huì)產(chǎn)生二個(gè)問題：

• 每個(gè)賬號(hào)都要配置很麻煩；
• 無法批量修改一類用戶的權(quán)限。

所以角色的誕生就呼之欲出了，我們通過對(duì)權(quán)限集的抽象，創(chuàng)立了角色，通過修改角色，來達(dá)到控制擁有該角色的賬號(hào)的權(quán)限修改的目的。

權(quán)限可以分為數(shù)據(jù)權(quán)限和功能權(quán)限兩大類：

• 數(shù)據(jù)權(quán)限顧名思義，就是賬號(hào)能查看多少數(shù)據(jù)，如何實(shí)現(xiàn)A部門與B部門之間相互不能查看業(yè)務(wù)數(shù)據(jù)，這個(gè)就涉及到數(shù)據(jù)權(quán)限；
• 功能權(quán)限按照范圍以大致菜單權(quán)限和按鈕權(quán)限，按照操作可以大致分為查看和編輯權(quán)限。

2.1 RBAC-0模型

2.1.1?簡(jiǎn)述

RBAC-0 模型的特點(diǎn)就是用戶和角色是多對(duì)多的關(guān)系，同一個(gè)用戶擁有多個(gè)角色的屬性，我們通過組織這個(gè)概念來構(gòu)建組織架構(gòu)，從而實(shí)現(xiàn)對(duì)角色數(shù)據(jù)權(quán)限的分配。這樣單個(gè)用戶賬號(hào)擁有的全部權(quán)限就是他所在組織的權(quán)限的累加。

2.1.2?舉例

在RBAC-0模型中，A用戶負(fù)責(zé)X組織的業(yè)務(wù)，B用戶負(fù)責(zé)Y組織的財(cái)務(wù)工作。正常情況下，A和B自然不能查看對(duì)方的數(shù)據(jù)，但是如果有天，B由于業(yè)務(wù)需要需要協(xié)助處理X組織的財(cái)務(wù)，那我們就可以通過為B用戶添加X組織的“財(cái)務(wù)”角色來實(shí)現(xiàn)這種需求。在業(yè)務(wù)結(jié)束后，也可以通過暫停/刪除操作來管理B在X組織下的權(quán)限。

2.2 RBAC-1模型

基于RBAC-0模型，針對(duì)角色引人繼承的概念，子角色可以對(duì)父角色的權(quán)限進(jìn)行繼承，但是子角色的權(quán)限一定小于父角色。

2.3 RBAC-2模型

相較RBAC-0系統(tǒng)，RBAC-2系統(tǒng)在用戶與角色間和角色與角色之間加入了一些規(guī)則。

• 單個(gè)角色允許分配的用戶數(shù)限制，例如一個(gè)公司不可能有多無限個(gè)“董事會(huì)”角色；
• 單個(gè)用戶允許授予的角色數(shù)限制，例如單個(gè)用戶不允許在一個(gè)公組織或多個(gè)組織擔(dān)任無限多個(gè)職務(wù)；
• 角色與角色有層級(jí)關(guān)系，例如想新增一個(gè)部門經(jīng)理，不能用一個(gè)部門職員的賬號(hào)去創(chuàng)建吧？
• 角色與角色存在互斥關(guān)系，這個(gè)根據(jù)實(shí)際業(yè)務(wù)需要來做限制，例如銷售不能兼任會(huì)計(jì)。

2.4 RBAC-3模型

RBAC-3模型也叫統(tǒng)一模型，它基于了RBAC-0，并包含了RBAC-1和RBAC-2模型的全部特點(diǎn)。

三、設(shè)計(jì)過程

3.1 新增賬號(hào)的屬性

新增賬號(hào)是用戶體系的最基本的功能，新增賬號(hào)時(shí)需要獲取賬號(hào)的哪些參數(shù)決定了整個(gè)用戶體系的數(shù)據(jù)維度。

這里不得不提的就是USER_ID，登錄賬號(hào)，昵稱的概念。

USER_ID：對(duì)應(yīng)的是賬號(hào)在系統(tǒng)中唯一標(biāo)識(shí)，可以不展示給用戶,例如微信的open_id和union_id，一般在新增賬號(hào)時(shí)由系統(tǒng)生成，且不可修改；

登陸賬號(hào)：登錄賬號(hào)和USER_ID在有的系統(tǒng)并不一致，同一個(gè)USER_ID可能對(duì)應(yīng)著多個(gè)登錄賬號(hào)，例如微信可以通過微信號(hào)，手機(jī)號(hào)，郵箱去登錄，這里的不同登陸方式都對(duì)應(yīng)這一個(gè)登陸賬號(hào)，一般在新增賬號(hào)時(shí)，由用戶輸入，且不可修改；

昵稱：昵稱是用戶可以自由編輯操作的，由用戶輸入，且允許修改。

3.2 功能權(quán)限的處理方式

功能權(quán)限通過對(duì)角色的權(quán)限樹進(jìn)行修改來實(shí)現(xiàn)。在權(quán)限樹種我們可以將頁面權(quán)限，菜單權(quán)限和按鈕權(quán)限羅列，通過篩選對(duì)應(yīng)權(quán)限完成對(duì)角色功能權(quán)限的控制。

需要注意的一個(gè)問題是，權(quán)限控制的最小粒度。如果要實(shí)現(xiàn)每一個(gè)權(quán)限的控制，相當(dāng)于每一個(gè)權(quán)限對(duì)應(yīng)功能都需要做封裝。大的頁面和菜單權(quán)限是必備的，但是哪些按鈕權(quán)限是可以封裝在一起的，（比如“啟用”和“暫停”一般都是成對(duì)出現(xiàn)的），這些是需要產(chǎn)品考慮的。

3.3?數(shù)據(jù)權(quán)限的處理方式

數(shù)據(jù)權(quán)限其實(shí)是角色權(quán)限的重要屬性，但是由于數(shù)據(jù)范圍太靈活，如果在角色加入“數(shù)據(jù)權(quán)限”tab，如果賬號(hào)下的數(shù)據(jù)量較大，用戶編輯數(shù)據(jù)權(quán)限的操作會(huì)很繁瑣。因此，因此現(xiàn)在主流的后臺(tái)設(shè)計(jì)都會(huì)使用“組織結(jié)構(gòu)”來對(duì)應(yīng)數(shù)據(jù)權(quán)限。

在系統(tǒng)中，我們使用了【新增組織】的方式，來處理數(shù)據(jù)權(quán)限。

3.4?對(duì)老用戶的兼容

在做用戶體系的重構(gòu)時(shí)，老用戶的賬號(hào)兼容問題是產(chǎn)品必須考慮的部分。兼容問題也是從功能和數(shù)據(jù)兩個(gè)維度去驗(yàn)證新的體系是否對(duì)老用戶是否有影響。

四、總結(jié)

文章的內(nèi)容主要是本次迭代中實(shí)際的使用場(chǎng)景，抱著他山之石可以攻玉的想法，參考了現(xiàn)有的資料，結(jié)合自己系統(tǒng)的實(shí)際情況，對(duì)用戶體系設(shè)計(jì)做了一次小結(jié)。若有不足之處，還請(qǐng)大家多多溝通，共同進(jìn)步。

本文由@幸失 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash ，基于 CC0 協(xié)議