做B端產(chǎn)品，權(quán)限是無(wú)法躲過(guò)的一類問題。比如，企業(yè)類軟件，不同部門、不同職位的人的權(quán)限是不同的；再例如，一款軟件，不同付費(fèi)層級(jí)的用戶，所使用的權(quán)限也是迥然不同的。
一、權(quán)限
1.什么是權(quán)限
權(quán)限是基于實(shí)際業(yè)務(wù)的需要，設(shè)計(jì)的一套系統(tǒng)使用關(guān)系。沒有固定的方法，每個(gè)公司可能都是不一樣的。權(quán)限分為：頁(yè)面權(quán)限、操作權(quán)限、數(shù)據(jù)權(quán)限。
頁(yè)面權(quán)限：誰(shuí)可以訪問頁(yè)面。例如，財(cái)務(wù)可以訪問財(cái)務(wù)報(bào)表，而銷售不可訪問財(cái)務(wù)報(bào)表頁(yè)面；
操作權(quán)限：誰(shuí)可以操作數(shù)據(jù)。例如：老板和財(cái)務(wù)都可以訪問財(cái)務(wù)報(bào)表，但是財(cái)務(wù)可以增刪查改，但是老板只能看，不可以改；
數(shù)據(jù)權(quán)限：誰(shuí)可以看哪個(gè)范圍的數(shù)據(jù)。例如：銷售一分部的老板只能看銷售一分部的數(shù)據(jù)，公司的老板可以看整個(gè)公司的數(shù)據(jù)；
2.遇到的問題
網(wǎng)上很多關(guān)于RBAC的資料，大多與如何用數(shù)據(jù)表實(shí)現(xiàn)RBCA相關(guān)，并不容易理解。很多人看了很多文章來(lái)描述權(quán)限、RBAC等等，看了很多，還是搞不清楚權(quán)限和RBAC的關(guān)系；或者看了RBAC也不知道如何去使用；在實(shí)際設(shè)計(jì)中，往往根據(jù)自我感覺就搭建了用戶和權(quán)限模型。自己想的模型可能會(huì)導(dǎo)致很多問題，例如權(quán)限管理不夠靈活，權(quán)限覆蓋能力弱，甚至操作混亂等。
3.解決方法
實(shí)際上，已經(jīng)有成熟的RBAC模型可直接應(yīng)用于權(quán)限設(shè)計(jì)，我們無(wú)需自己拍腦袋設(shè)置用戶權(quán)限模型，正如牛頓所言，站在巨人的肩膀上才能看的更遠(yuǎn)。我們不妨去參照已有的比較成熟的權(quán)限模型RBAC（Role-Based Access Control）——基于角色的訪問控制。我會(huì)以產(chǎn)品經(jīng)理的角度去解析RBAC模型，并分別舉例如何運(yùn)用這套已得到驗(yàn)證的成熟模型。
二、RBAC模型
1.傳統(tǒng)權(quán)限模型
在沒有RBAC前，傳統(tǒng)權(quán)限模型通過(guò)賬號(hào)直接配置權(quán)限。每一個(gè)賬號(hào)都需要勾選賬號(hào)對(duì)應(yīng)的每一個(gè)權(quán)限，如下圖。可見非常繁瑣，維護(hù)起來(lái)非常麻煩。
2.RBAC概念
RBAC增加了“角色”的概念，我們首先把權(quán)限賦予角色，再把角色賦予用戶。這樣，由于增加了角色，授權(quán)會(huì)更加靈活方便。在RBAC中，根據(jù)權(quán)限的復(fù)雜程度，又可分為RBAC0、RBAC1、RBAC2、RBAC3，RBAC4。其中，RBAC0是基礎(chǔ)，RBAC1、RBAC2、RBAC3、RBAC4都是以RBAC0為基礎(chǔ)的升級(jí)。我們可以根據(jù)自家產(chǎn)品權(quán)限的復(fù)雜程度，選取適合的權(quán)限模型。
3.RBAC0：基本模型
解析：RBAC0是RBAC模型中最基本的模型，很多產(chǎn)品只需基于RBAC0就可以搭建權(quán)限模型了。用戶與角色可為多對(duì)一或多對(duì)多的關(guān)系，當(dāng)一個(gè)用戶的角色為多對(duì)多時(shí)，當(dāng)前用戶的權(quán)限是多個(gè)角色的并集。
舉例：譬如我們做一款企業(yè)管理產(chǎn)品，如果按傳統(tǒng)權(quán)限模型，給每一個(gè)用戶賦予權(quán)限則會(huì)非常麻煩，并且做不到批量修改用戶權(quán)限。這時(shí)候，可以抽象出幾個(gè)角色，譬如銷售經(jīng)理、財(cái)務(wù)經(jīng)理、市場(chǎng)經(jīng)理等，然后把權(quán)限分配給這些角色，再把角色賦予用戶。這樣無(wú)論是分配權(quán)限還是以后的修改權(quán)限，只需要修改用戶和角色的關(guān)系，或角色和權(quán)限的關(guān)系即可，更加靈活方便。此外，如果一個(gè)用戶有多個(gè)角色，譬如王先生既負(fù)責(zé)銷售部也負(fù)責(zé)市場(chǎng)部，那么可以給王先生賦予兩個(gè)角色，即銷售經(jīng)理+市場(chǎng)經(jīng)理，這樣他就擁有這兩個(gè)角色的所有權(quán)限。
4.RABC1：用戶組/權(quán)限組模型
解析：在RABC0的基礎(chǔ)上，加入了用戶組的概念。賬號(hào)既可以通過(guò)角色來(lái)配置權(quán)限，也可以通過(guò)用戶組來(lái)配置權(quán)限。這樣做的好處是，若存在多個(gè)角色具有統(tǒng)一的權(quán)限，無(wú)需對(duì)每一個(gè)角色的共同權(quán)限進(jìn)行配置。僅需將共同權(quán)限配置在用戶組，使賬號(hào)歸屬于用戶組即可；（此級(jí)別，也可同時(shí)存在權(quán)限組，類似于用戶組，這里就不細(xì)講了）
一個(gè)賬號(hào)可以既存在用戶組也存在角色，權(quán)限范圍為其的并集；
舉例：會(huì)計(jì)、出納、公司老板均可以查看公司的財(cái)務(wù)報(bào)表，但是操作不同，會(huì)計(jì)審核，出納付款，老板僅查看；此時(shí)只需要抽象出一個(gè)報(bào)表查看用戶組，用戶組配置所需查看的報(bào)表，再將會(huì)計(jì)、出納、公司老板都加入用戶組；這樣，加入用戶組的用戶都可以查看報(bào)表；再將會(huì)計(jì)和出納角色配置單獨(dú)的操作權(quán)限，一并賦予，這樣會(huì)計(jì)和出納就既擁有了用戶組的權(quán)限（可查看報(bào)表），以及獨(dú)特的操作權(quán)限（審核/付款）
5.RBAC2：角色繼承模型
解析：角色繼承，講一個(gè)角色分為多個(gè)級(jí)別，高級(jí)別的角色可繼承低級(jí)別角色的權(quán)限，上層角色繼承下層角色的全部權(quán)限，且可額外賦予權(quán)限。
舉例：
基于之前RBAC0的例子，我們又發(fā)現(xiàn)一個(gè)公司的財(cái)務(wù)經(jīng)理可能是分三個(gè)等級(jí)的，財(cái)務(wù)經(jīng)理、財(cái)務(wù)組長(zhǎng)、財(cái)務(wù)員工。財(cái)務(wù)組長(zhǎng)只有財(cái)務(wù)經(jīng)理的部分權(quán)限。這時(shí)候，我們就可以采用RBAC1的分級(jí)模型，把財(cái)務(wù)這個(gè)角色分成多個(gè)等級(jí)，給財(cái)務(wù)組長(zhǎng)賦予較低的等級(jí)即可。
6.RBAC3：角色限制模型
解析：角色限制的RBAC模型，指的是當(dāng)用戶可以存在多個(gè)角色時(shí)，多個(gè)角色質(zhì)檢存在限制條件。例如，一個(gè)人不能既是裁判，又是運(yùn)動(dòng)員；這些限制可以分成兩類，即靜態(tài)職責(zé)分離SSD(Static Separation of Duty)和動(dòng)態(tài)職責(zé)分離DSD(Dynamic Separation of Duty)。
舉例：
基于之前RBAC0的例子，我們又發(fā)現(xiàn)有些角色之間是需要互斥的，譬如給一個(gè)用戶分配了財(cái)務(wù)經(jīng)理的角色，就不能給他再賦予審計(jì)經(jīng)理的角色了，否則他即可以錄入賬單又能自己審核賬單；再譬如，有些公司對(duì)角色的升級(jí)十分看重，一個(gè)財(cái)務(wù)員工要想升級(jí)到財(cái)務(wù)經(jīng)理，必須先升級(jí)到財(cái)務(wù)主管，這時(shí)候就要采用先決條件限制了。
7.RBAC4：統(tǒng)一模型
RBAC4是RBAC2和RBAC3的合集，所以RBAC3既有角色分層，也包括可以增加各種限制。
舉例：
這個(gè)就不舉例了，統(tǒng)一模型RBAC3可以解決上面三個(gè)例子的所有問題。當(dāng)然，只有在系統(tǒng)對(duì)權(quán)限要求非常復(fù)雜時(shí)，才考慮使用此權(quán)限模型。
8.擴(kuò)展案例
①公司架構(gòu)如圖，共有三種職能：前沿銷售、前臺(tái)、銷售、老板，各職能角色分別如上圖。前沿銷售需要查看和操作客戶列表、訂單列表，銷售需要查看和操作客戶列表、訂單列表，前臺(tái)需要查看和操作客戶列表，老板需查看所有的頁(yè)面，但不可操作。
②權(quán)限說(shuō)明：
1.頁(yè)面權(quán)限：前沿銷售——客戶列表、訂單列表；銷售員工——客戶列表、訂單列表；銷售主管——客戶列表、訂單列表、銷售報(bào)表；前臺(tái)——客戶列表；老板——所有頁(yè)面；
2.操作權(quán)限：前沿銷售——客戶列表（新增、刪除）、訂單列表（新增）；銷售員工——客戶列表（新增、刪除）、訂單列表（新增）；銷售主管——客戶列表（新增、刪除）、訂單列表（新增）、銷售報(bào)表（導(dǎo)出）；前臺(tái)——客戶列表（新增）；老板——所有頁(yè)面（無(wú)）；
3.數(shù)據(jù)權(quán)限：前沿銷售——客戶列表（本人）、訂單列表（本人）；銷售員工——客戶列表（本人）、訂單列表（本人）；銷售主管——客戶列表（本人及本人下屬）、訂單列表（本人及本人下屬）、銷售報(bào)表（本人及本人下屬）；前臺(tái)——客戶列表（本人）；老板——所有頁(yè)面（全部）；
③運(yùn)用RBAC0
1.頁(yè)面&操作權(quán)限：新建角色，勾選對(duì)應(yīng)的頁(yè)面以及操作
2.數(shù)據(jù)權(quán)限：新建數(shù)據(jù)權(quán)限，勾選對(duì)應(yīng)查看數(shù)據(jù)的范圍
但此時(shí)不要忘記，系統(tǒng)當(dāng)前對(duì)賬號(hào)之間的關(guān)系并不清楚，也就是系統(tǒng)并不知道賬號(hào)的上下級(jí)關(guān)系；所以數(shù)據(jù)權(quán)限還需要搭配部門上下級(jí)的功能。
這樣系統(tǒng)就知道，賬號(hào)所處的部門，也就可以配置銷售主管查看下屬的數(shù)據(jù)了，如下；
此時(shí)，該賬號(hào)已具備，1.查看本人及下屬的數(shù)據(jù)權(quán)限? 2.查看客戶列表、操作客戶列表的功能
9.最后的話
無(wú)論是本次的權(quán)限模型，還是其他產(chǎn)品相關(guān)實(shí)現(xiàn)方案，很多都已經(jīng)被前人所總結(jié)提煉，我們應(yīng)深度掌握這些成熟的知識(shí)和經(jīng)驗(yàn)，而不是絞盡腦汁自我推理。我們只需要使用輪子，不需要自己創(chuàng)造輪子。（本文部分借鑒其他文章，如有雷同，是我抄你【偷懶了，還請(qǐng)諒解】）
