編輯導(dǎo)語：用戶權(quán)限體系的搭建，是許多系統(tǒng)建設(shè)的基礎(chǔ)，尤其是在B端產(chǎn)品設(shè)計中都會涉及到這一功能模塊。那么我們該如何從零開始著手搭建用戶體系？作者總結(jié)了相關(guān)步驟，希望能夠給你帶來一個全局性的認(rèn)識，做到心中有數(shù)。

搭建用戶權(quán)限體系，是很多系統(tǒng)建設(shè)的基礎(chǔ)，特別是很多B端產(chǎn)品都會涉及到這一功能模塊。那么我們?nèi)绾螐牧汩_始著手這件事呢？

下面的內(nèi)容希望能帶給你一個全局性的認(rèn)識，即使是之前從來沒有涉及過的小白，也能幫助你做到心中有數(shù)。

一、系統(tǒng)資源

用戶權(quán)限管理是一種對系統(tǒng)資源的訪問控制，那么系統(tǒng)有什么樣的資源需要進(jìn)行權(quán)限分配呢？有3類：

1．菜單

菜單的授權(quán)意味著用戶可以使用該菜單下相關(guān)的功能。屬于高層級的授權(quán)。

2．操作

增刪改查的權(quán)限控制，有的角色只能看不能改，有的角色具有增刪改查全部權(quán)限。

3．?dāng)?shù)據(jù)

數(shù)據(jù)的權(quán)限控制，不同角色看到的數(shù)據(jù)范圍不同，有的角色只能看到基礎(chǔ)數(shù)據(jù)，有的角色能看到全部數(shù)據(jù)。

二、分配方式

了解了系統(tǒng)有哪些需要進(jìn)行權(quán)限分配的資源后，接下來面臨的問題是：系統(tǒng)有很多的用戶，也有很多的資源，那么怎么實現(xiàn)給每一個用戶分配好合適的權(quán)限呢？有兩種實現(xiàn)路徑：

1．直接分配，即ACL模型

給每一個用戶直接進(jìn)行權(quán)限的逐一分配。

這種方式的好處是非常靈活，能最大化滿足每個用戶對于權(quán)限的個性化需求。

缺點也顯而易見，那就是不便于操作，權(quán)限的分配與管理效率比較低。

權(quán)限管理人員需要對系統(tǒng)有深入的了解，如果管理層級比較多時，系統(tǒng)的權(quán)限分配與管理無法大規(guī)模下放和向下有效分散，容易產(chǎn)生高層級管理人員覺得工作量大、基層人員覺得不能自主操控不方便等問題。

2．基于角色進(jìn)行權(quán)限分配，即RBAC模型

這是一種間接分配方式，在用戶集合和權(quán)限集合之間建立一個角色集合，用戶通過角色與權(quán)限進(jìn)行關(guān)聯(lián)，形成“用戶-角色-權(quán)限”的授權(quán)模型。

這種方式的好處是不必在每次給用戶分配權(quán)限時都把系統(tǒng)所有的資源分配一遍，只要分配用戶相應(yīng)的角色即可，用戶就擁有了這些角色所關(guān)聯(lián)的權(quán)限。

而且角色的權(quán)限變更比用戶的權(quán)限變更要少得多，也能實現(xiàn)權(quán)限的動態(tài)管理，即當(dāng)角色的權(quán)限發(fā)生了變化以后，所有擁有該角色的用戶也同時更新了權(quán)限狀態(tài)。

下面重點來介紹一下RBAC模型。

在RBAC模型中，用戶是真實的，而角色是我們?yōu)榱朔奖愎芾頇?quán)限集合而虛擬出來的。本質(zhì)上，角色是一組權(quán)限的集合。

RBAC模型又可以分為RBAC0、RBAC1、RBAC2、RBAC3。

RBAC0：基本模型。用戶和角色可以是一對一，也可以是多對對，一個用戶擁有的權(quán)限是他所有角色的集合。

RBAC1：角色分層模型。RBAC1是在RBAC0的基礎(chǔ)上增加角色分層，引入了繼承概念。將角色分成多個等級，等級高的角色可以繼承等級低的所有權(quán)限。

如某個部門，有助理工程師和工程師，助理工程師的權(quán)限不能大于工程師。如果采用RBAC0，極有可能出現(xiàn)權(quán)限分配失誤，最終出現(xiàn)助理工程師擁有工程師都沒有的權(quán)限的情況。

RBAC1很好地解決了這個問題，創(chuàng)建完助理工程師的角色并配置好權(quán)限后，工程師的角色繼承助理工程師的權(quán)限并且增加特有的權(quán)限即可。

RBAC2：角色限制模型。RBAC2是在RBAC0的基礎(chǔ)上增加了對角色的一些限制，包含角色互斥、基數(shù)約束、先決條件、運行時互斥。

• 角色互斥：一個用戶不能同時擁有互斥的兩個或多個角色。如財務(wù)系統(tǒng)中，一個用戶不能同時擁有會計員角色和審核員角色。
• 基數(shù)約束：一個角色被分配的用戶數(shù)量是有限制的，不能無限地添加，即有多少用戶能夠擁有這個角色。如一個角色是為CEO創(chuàng)建的，那么這個角色的數(shù)量是有限的。
• 先決條件：想要獲得更高權(quán)限時，首先需要獲得低一級的權(quán)限。如先有助理工程師的權(quán)限，才能有工程師的權(quán)限。
• 運行時互斥：一個用戶允許具有兩個角色，但在運行時不可同時激活這兩個角色，如家長和老師，一個用戶可能既是家長又是老師，但在使用系統(tǒng)時，只能選擇一個角色。

RBAC3：統(tǒng)一模型。RBAC3是RBAC1和RBAC2的合集，所以RBAC3既有角色分層，也可以增加各種限制。

基于RBAC的延展。了解完RBAC模型本身以后，我們還需要了解一組與之相關(guān)的概念：用戶組、角色組、權(quán)限組。這3個概念的出現(xiàn)都是為了方便管理。

用戶組：用戶組是用戶的集合。

如果用戶數(shù)量比較龐大，可以給用戶分組，分好組以后可以給用戶組分配權(quán)限，這樣這個用戶組下的每一個用戶擁有的權(quán)限=用戶個人擁有的權(quán)限+該用戶組擁有的權(quán)限。以后加入更多的用戶，就自動擁有了用戶組的權(quán)限，不用再一一進(jìn)行設(shè)置了。

角色組：角色組是角色的集合。

有時多個角色針對某一部分系統(tǒng)資源擁有相同的權(quán)限，如經(jīng)理、技術(shù)人員、銷售人員這些角色，對同一類文件擁有相同的權(quán)限，這時就可以為這些角色建立一個角色組，把權(quán)限賦予這個角色組，這樣這些角色就都擁有了權(quán)限。

權(quán)限組：權(quán)限組是權(quán)限的集合。

權(quán)限之間有時是相關(guān)聯(lián)的，這時就可以為這些關(guān)聯(lián)的權(quán)限設(shè)置一個權(quán)限組，當(dāng)授權(quán)時就可以把權(quán)限組賦予某個角色/角色組，就不需要再一一去設(shè)置了。如當(dāng)我們視頻通話時，需要同時具有相機和麥克風(fēng)的權(quán)限。

三、角色定義

在了解完RBAC模型以后我們會發(fā)現(xiàn)，在RBAC模型中角色是關(guān)鍵。為了對許多擁有相似權(quán)限的用戶進(jìn)行分類管理，我們抽象出角色的概念。那么我們?nèi)绾蝸矶x角色呢？

角色是基于業(yè)務(wù)來定義，而不是依據(jù)行政關(guān)系。如雙人復(fù)核類業(yè)務(wù)，用戶A在一次業(yè)務(wù)過程中扮演操作員角色，用戶B扮演復(fù)核員角色。而在下一次業(yè)務(wù)過程中，用戶B扮演操作員角色，用戶A扮演復(fù)核員角色。這樣的角色定義完全是基于業(yè)務(wù)上的需要，而與用戶A和B的行政關(guān)系沒有任何關(guān)系。

我們在進(jìn)行角色定義時，可能會對角色的顆粒度產(chǎn)生迷惑，不知道該范圍大一些包含的內(nèi)容多一些還是應(yīng)該范圍小一些包含的內(nèi)容少一些。

如一個用戶涉及A、B、C三項業(yè)務(wù)，那么我是應(yīng)該定義一個角色完成A、B、C三項業(yè)務(wù)的范圍還是應(yīng)該定義兩個角色分別完成A、B業(yè)務(wù)和C業(yè)務(wù)呢？甚至定義三個角色分別完成A業(yè)務(wù)、B業(yè)務(wù)和C業(yè)務(wù)呢？

這時有人可能會說取決于ABC三項業(yè)務(wù)的關(guān)聯(lián)性，實際上這個問題與業(yè)務(wù)的關(guān)聯(lián)性沒有關(guān)系。因為如果是相關(guān)聯(lián)的業(yè)務(wù)那么必然會一起授權(quán)不可分割，如果是不相關(guān)的業(yè)務(wù)但是所有用戶都是一起使用，那么也應(yīng)該一起授權(quán)。

那么我們怎么判斷呢？其實上面的例子和問題是走入了一個本末倒置的誤區(qū)，從業(yè)務(wù)來歸類用戶了，方向上反了。前面我們說過，角色是擁有相似權(quán)限的用戶抽象。

所以梳理角色的時候分析用戶本身就可以了，歸類出每類有相似權(quán)限的用戶然后抽象成一個個角色。

用戶權(quán)限體系對于整個功能體系具有蝴蝶效應(yīng)，一點點小的差異/差錯到了最上層的功能和使用層面會放大很多倍。而且一旦需要修改會很麻煩，所以我們需要特別小心。

四、前端展現(xiàn)方式

如果一個用戶有多個角色，那么在前端功能層面我們該如何處理呢？有兩種方案：

1. 角色切換：當(dāng)一個用戶有多個角色時，前端僅展現(xiàn)當(dāng)前角色的相關(guān)功能，用戶需要切換角色去使用對應(yīng)的功能。
2. 統(tǒng)一展現(xiàn)：當(dāng)一個用戶有多個角色時，前端展現(xiàn)該用戶所有角色的功能的全集，用戶不再需要切換角色。

那么我們在這兩種方案之間，該如何選擇呢？我們需要判斷用戶所擁有角色之間的關(guān)系。

一般來說，如果角色之間存在運行時互斥的情況，那么需要選擇角色切換方案，如前面提到的家長和老師，一個用戶不可能在同一時間既是家長角色又是老師角色，所以需要切換角色去使用對應(yīng)的功能。

再比如求職者和招聘者，一個用戶不可能同時使用求職者和招聘者的功能。除此以外，其他情況都可以選擇統(tǒng)一展現(xiàn)方案。

這里需要我們注意一點，如果你的系統(tǒng)有很多功能，一個用戶的運行時互斥角色只涉及到部分功能模塊，那么角色切換可以只局限于局部，不必全局都進(jìn)行角色切換。

五、建議

1. 依據(jù)現(xiàn)實情況建立

依據(jù)現(xiàn)實情況已經(jīng)抽象形成的角色，最能貼合現(xiàn)實情況，能最大限度地滿足現(xiàn)實需要。除此以外，使用現(xiàn)實情況中的角色定義符合普遍認(rèn)知，避免“語言障礙”。

2. 最大化滿足個性化需要

需要進(jìn)行權(quán)限管理的系統(tǒng)，所涉及的業(yè)務(wù)特點、人員管理差異常常比較大，情況復(fù)雜，盡可能滿足個性化配置可以兼容各種現(xiàn)實情況。

作者：厚厚（微信公眾號：厚厚的語和文），多年互聯(lián)網(wǎng)和傳統(tǒng)企業(yè)的跨界產(chǎn)品經(jīng)理。

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

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