RBAC權(quán)限管理模型:基本模型及角色模型解析及舉例
![](http://image.woshipm.com/wp-files/img/49.jpg)
站在巨人的肩膀上我們可以看得更遠(yuǎn),而不是再造一個輪子。
我們在做任何一款產(chǎn)品的時候,或多或少都會涉及到用戶和權(quán)限的問題。譬如,做企業(yè)類軟件,不同部門、不同職位的人的權(quán)限是不同的;做論壇類產(chǎn)品的時候,版主和訪客權(quán)限也是不一樣的;再例如一款產(chǎn)品的收費(fèi)用戶和免費(fèi)用戶權(quán)限也是迥然不同的。
但在設(shè)計(jì)產(chǎn)品的用戶和權(quán)限的關(guān)系的時候,很多產(chǎn)品經(jīng)理可能按照感覺來,在并不清楚用戶和權(quán)限是否存在優(yōu)秀的理論模型的時候,就按照自我推理搭建了產(chǎn)品的用戶和權(quán)限模型。而這種基于感覺和推理的模型肯定是有諸多問題的,譬如寫死了關(guān)系導(dǎo)致權(quán)限不夠靈活、考慮不周導(dǎo)致權(quán)限覆蓋能力弱等等。
正如牛頓所言,站在巨人的肩膀上才能看的更遠(yuǎn)。我們不妨去參照已有的比較成熟的權(quán)限模型,如:RBAC(Role-Based Access Control)——基于角色的訪問控制。我搜集了網(wǎng)上很多關(guān)于RBAC的資料,大多與如何用數(shù)據(jù)表實(shí)現(xiàn)RBCA相關(guān),并不容易理解。所以,我會以產(chǎn)品經(jīng)理的角度去解析RBAC模型,并分別舉例如何運(yùn)用這套已得到驗(yàn)證的成熟模型。
一、RBAC模型是什么?
RBAC是一套成熟的權(quán)限模型。在傳統(tǒng)權(quán)限模型中,我們直接把權(quán)限賦予用戶。而在RBAC中,增加了“角色”的概念,我們首先把權(quán)限賦予角色,再把角色賦予用戶。這樣,由于增加了角色,授權(quán)會更加靈活方便。在RBAC中,根據(jù)權(quán)限的復(fù)雜程度,又可分為RBAC0、RBAC1、RBAC2、RBAC3。其中,RBAC0是基礎(chǔ),RBAC1、RBAC2、RBAC3都是以RBAC0為基礎(chǔ)的升級。我們可以根據(jù)自家產(chǎn)品權(quán)限的復(fù)雜程度,選取適合的權(quán)限模型。
二、基本模型RBAC0
解析:
RBAC0是基礎(chǔ),很多產(chǎn)品只需基于RBAC0就可以搭建權(quán)限模型了。在這個模型中,我們把權(quán)限賦予角色,再把角色賦予用戶。用戶和角色,角色和權(quán)限都是多對多的關(guān)系。用戶擁有的權(quán)限等于他所有的角色持有權(quán)限之和。
舉例:
譬如我們做一款企業(yè)管理產(chǎn)品,如果按傳統(tǒng)權(quán)限模型,給每一個用戶賦予權(quán)限則會非常麻煩,并且做不到批量修改用戶權(quán)限。這時候,可以抽象出幾個角色,譬如銷售經(jīng)理、財(cái)務(wù)經(jīng)理、市場經(jīng)理等,然后把權(quán)限分配給這些角色,再把角色賦予用戶。這樣無論是分配權(quán)限還是以后的修改權(quán)限,只需要修改用戶和角色的關(guān)系,或角色和權(quán)限的關(guān)系即可,更加靈活方便。此外,如果一個用戶有多個角色,譬如王先生既負(fù)責(zé)銷售部也負(fù)責(zé)市場部,那么可以給王先生賦予兩個角色,即銷售經(jīng)理+市場經(jīng)理,這樣他就擁有這兩個角色的所有權(quán)限。
三、角色分層模型RBAC1
解析:
RBAC1建立在RBAC0基礎(chǔ)之上,在角色中引入了繼承的概念。簡單理解就是,給角色可以分成幾個等級,每個等級權(quán)限不同,從而實(shí)現(xiàn)更細(xì)粒度的權(quán)限管理。
舉例:
基于之前RBAC0的例子,我們又發(fā)現(xiàn)一個公司的銷售經(jīng)理可能是分幾個等級的,譬如除了銷售經(jīng)理,還有銷售副經(jīng)理,而銷售副經(jīng)理只有銷售經(jīng)理的部分權(quán)限。這時候,我們就可以采用RBAC1的分級模型,把銷售經(jīng)理這個角色分成多個等級,給銷售副經(jīng)理賦予較低的等級即可。
四、角色限制模型RBAC2
解析:
RBAC2同樣建立在RBAC0基礎(chǔ)之上,僅是對用戶、角色和權(quán)限三者之間增加了一些限制。這些限制可以分成兩類,即靜態(tài)職責(zé)分離SSD(Static Separation of Duty)和動態(tài)職責(zé)分離DSD(Dynamic Separation of Duty)。具體限制如下圖:
舉例:
還是基于之前RBAC0的例子,我們又發(fā)現(xiàn)有些角色之間是需要互斥的,譬如給一個用戶分配了銷售經(jīng)理的角色,就不能給他再賦予財(cái)務(wù)經(jīng)理的角色了,否則他即可以錄入合同又能自己審核合同;再譬如,有些公司對角色的升級十分看重,一個銷售員要想升級到銷售經(jīng)理,必須先升級到銷售主管,這時候就要采用先決條件限制了。
五、統(tǒng)一模型RBAC3
解析:
RBAC3是RBAC1和RBAC2的合集,所以RBAC3既有角色分層,也包括可以增加各種限制。
舉例:
這個就不舉例了,統(tǒng)一模型RBAC3可以解決上面三個例子的所有問題。當(dāng)然,只有在系統(tǒng)對權(quán)限要求非常復(fù)雜時,才考慮使用此權(quán)限模型。
六、基于RBAC的延展——用戶組
解析:
基于RBAC模型,還可以適當(dāng)延展,使其更適合我們的產(chǎn)品。譬如增加用戶組概念,直接給用戶組分配角色,再把用戶加入用戶組。這樣用戶除了擁有自身的權(quán)限外,還擁有了所屬用戶組的所有權(quán)限。
舉例:
譬如,我們可以把一個部門看成一個用戶組,如銷售部,財(cái)務(wù)部,再給這個部門直接賦予角色,使部門擁有部門權(quán)限,這樣這個部門的所有用戶都有了部門權(quán)限。用戶組概念可以更方便的給群體用戶授權(quán),且不影響用戶本來就擁有的角色權(quán)限。
七、最后的話
無論是本次的權(quán)限模型,還是其他產(chǎn)品相關(guān)實(shí)現(xiàn)方案,很多都已經(jīng)被前人所總結(jié)提煉,我們應(yīng)深度掌握這些成熟的知識和經(jīng)驗(yàn),而不是絞盡腦汁自我推理。還是文章開頭那句話,站在巨人的肩膀上我們可以看得更遠(yuǎn),而不是再造一個輪子。
作者:Monster,小滿科技產(chǎn)品經(jīng)理,公眾號:PM怪物Monster
本文由 @Monster 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。
用戶組的舉例,建議改成銷售組織(或者省級業(yè)務(wù)中心)
之前所在的產(chǎn)品項(xiàng)目也是b端,有很多類似模塊感覺應(yīng)該是有經(jīng)驗(yàn)積累下來的輪子的,但是又不知道去哪找,求教 ??
我已經(jīng)很久沒找輪子了。。一般是百度搜一下。。
學(xué)到了!!多了解輪子真的蠻重要的,請問作者平時是通過哪些渠道來了解到產(chǎn)品設(shè)計(jì)中的輪子的呢?
大神,想請教一下關(guān)于集團(tuán)性公司部門組織架構(gòu)建立,一個集團(tuán)下包含總分子公司,如果總公司有一個體系,這個體系下既有總公司的部門a,又有分公司的部門b,在創(chuàng)建組織架構(gòu)的時候,分公司那個部門b應(yīng)該創(chuàng)建在分公司的架構(gòu)下嗎?
我考慮了這兩種情況:
1.如果這個b部門創(chuàng)建在總公司下,可能從業(yè)務(wù)上來講,負(fù)責(zé)這個體系的領(lǐng)導(dǎo)查看整個體系的數(shù)據(jù)沒有問題,但是從職能上來講,分公司財(cái)務(wù)需要能看到這個b部門的數(shù)據(jù),但是架構(gòu)設(shè)置在總部
2.如果b部門創(chuàng)建在分公司架構(gòu)下,那負(fù)責(zé)這個體系的領(lǐng)導(dǎo)還要單獨(dú)給他這只b部門的權(quán)限
如果有其他大神有解,歡迎探討
不是大神,產(chǎn)品小白,根據(jù)你說的內(nèi)容,個人認(rèn)為一般情況是第二種情況符合;特殊情況為集團(tuán)直屬控制部門,例如總公司財(cái)務(wù)部門要特殊處理,培訓(xùn)部門特殊處理;
基于RBAC的延展——用戶組.我們可以把一個部門看成一個用戶組,如銷售部,財(cái)務(wù)部,再給這個部門直接賦予角色,使部門擁有部門權(quán)限,這樣這個部門的所有用戶都有了部門權(quán)限。這個部門銷售部、財(cái)務(wù)部所有人的權(quán)限都是一樣的嗎?
是的,先可以有簡單的、共有的部門權(quán)限,然后部門職員還可以有自己崗位特殊的角色權(quán)限。
這個讓我想到一個案例: 一個平臺里面要管理多個店的管理員和類目商品管理,類目商品有多個以上的上級進(jìn)行匯報工作(例如洗滌用品的要管理多個店的洗滌區(qū)域,飲料類的要管理多個店的飲料區(qū)域),同時要和單店管理員 和公司商品經(jīng)理雙線匯報公司,這樣的的賬號,角色,權(quán)限就用這個模型對應(yīng)關(guān)聯(lián)起來;
會員體系的搭建是不是也可以用這個模型?
會員體系好像不是后臺系統(tǒng)的范疇
對于RBAC1,角色的等級不是確定的,需要用戶自己去配置等級權(quán)限,這種該怎么設(shè)計(jì)呢
大神,我們的系統(tǒng)終于實(shí)現(xiàn)了這個巨人的理論了 ?
恭喜你,理論是一回事,落地又是一回事,你能推動落地非常棒!
我的文章真是棒棒的鴨鴨鴨!?。。。。。。。。。。。。。?/p>
每看一字都收益良多,佩服大神,到這里瞬間出戲 ?
哈哈哈哈哈哈哈哈哈哈哈哈
確實(shí)很棒,受益匪淺
關(guān)于權(quán)限的分配感謝指教,但是我還想請問你數(shù)據(jù)權(quán)限和功能權(quán)限如何區(qū)分?在配置功能權(quán)限時,有粗有細(xì),大到功能模塊,小到每一個頁面的小按鈕,那這種分法都在什么場景下使用呢?關(guān)于數(shù)據(jù)權(quán)限我現(xiàn)在還是沒有想清楚怎么設(shè)計(jì),麻煩大神指點(diǎn)一下
1、數(shù)據(jù)權(quán)限和功能權(quán)限分開配置;
2、場景太多了,按照你實(shí)際需求來;
3、數(shù)據(jù)權(quán)限類似,你和你老板都能使用組織架構(gòu)功能,但是你只看到你團(tuán)隊(duì)的人,你老板看到全公司的人。組織架構(gòu)算一個功能,需要賦予你和你老板,看到哪些人算數(shù)據(jù)權(quán)限,你看到的和你老板看到的范圍就不一樣了,也是需要設(shè)置的。
作者您好,就你所說的組織架構(gòu)算一個功能,需要賦予你和你老板,看到哪些人算數(shù)據(jù)權(quán)限,你看到的和你老板看到的范圍就不一樣了,也是需要設(shè)置的。怎么設(shè)置呢?可以具體在舉例說明嗎?目前我也遇到數(shù)據(jù)范圍權(quán)限的設(shè)置,還是不特別清楚。麻煩指點(diǎn)一下哦。非常感謝
在你數(shù)據(jù)本身做文章。例如你是銷售部經(jīng)理,老板是總經(jīng)理。那么員工本身有歸屬于某個部門,此時數(shù)據(jù)權(quán)限可分為,1.你看到的是部門時銷售部的所有員工。2.老板看到的是所有部門的員工。這樣數(shù)據(jù)權(quán)限不就區(qū)分開了嗎
是要把所有的人都要分組展示,然后做成可勾選嗎?
比如,看到:我的訂單,我所在部門下的訂單,我所在部門及下級部門的訂單,全部訂單。。等等。
需要把職員分部門分負(fù)責(zé)人這樣去設(shè)計(jì),才能夠進(jìn)行數(shù)據(jù)的區(qū)分(區(qū)分的前提是用戶跟數(shù)據(jù)本身是有關(guān)聯(lián)的)
站在巨人的肩膀上我們可以看得更遠(yuǎn)……同意。
三克油~
你好,受教了,但個人對于“用戶組”和“角色”之間的關(guān)系和應(yīng)用場景還是有點(diǎn)模糊,盼舉例指點(diǎn)一二,感激!
臨時組建一個項(xiàng)目部,給項(xiàng)目部分配權(quán)限,但是每個人在自己原先的崗位上還有角色和崗位
舉個例子,現(xiàn)在為公司的500名客服部門員工設(shè)置權(quán)限,這些員工的角色都屬于“客服”,我如果每一個客服都去設(shè)置一下,為什么不創(chuàng)建一個客服組,給這個組匹配“客服”這個角色,之后就是往里面添加員工即可,效率是不是提高了;這還是只是一個角色的情況下,如果公司有一批相同崗位的員工都具有N種相同的角色,此時會不會覺得角色組更好用呢?
這個時候不是用部門麼,
還有就是用組的話,要報超級的用戶添加到組里也是一件不少的工作量呵,對吧?
請問一般來說,一個用戶會歸屬于多個用戶組嗎?
可以歸屬多個用戶組
用戶權(quán)限有RBAC……,有什么其他比較成熟的業(yè)務(wù)模式么?
棒棒棒!!!
求教RBAC3模型???
不教鴨!
非常棒,講得深入淺出條理清晰。
謝謝哈~
目前只用到了RBAC0,保持最大的靈活度,沒想到B端產(chǎn)品有這么多專業(yè)名詞,感謝分享
感謝分享,非常受用
大多時候做的都是后臺型產(chǎn)品,感覺有些隔閡,終于!發(fā)現(xiàn)了新世界的大門![:mrgreen:](http://m.codemsi.com/wp-includes/images/smilies/mrgreen.png)
謝謝哈,加油
又重新看了一篇,看懂了但是實(shí)際使用時怎么用呢?
我舉了例子哈,也不是很清楚你具體場景,但是你可以理解邏輯后,自己針對具體業(yè)務(wù)梳理哈
RBAC1模型角色分等級,角色不同等級看成不同角色,是不是與RBAC0相同了,在實(shí)際使用中,與RBAC0有什么具體區(qū)別?
感謝分享~
不客氣哈
看了幾遍后終于看懂了,產(chǎn)品之路還得好好修煉 小白 ??
嗯嗯,加油
感謝分享~
不客氣~
干貨!正好對我現(xiàn)在遇到的問題很有幫助,感謝!
不客氣哈,加油
用戶組的概念從操作層面可以理解為用戶的集合,從背后權(quán)限分配的層面可以理解為對于一組用戶固定分配的一個角色,不知道可否這樣去理解
可以這樣理解,棒棒噠
那是不是相當(dāng)于組里面的人有兩個角色?只是不互斥?
最后的用戶組,通常情況下是不是可以等同于通訊錄的部門。因?yàn)榇蠖鄶?shù)情況下,每個部門是有獨(dú)特的權(quán)限的,比如市場部可以看報表,財(cái)務(wù)部可以看報銷,人事部可以看請假…
你提到的這種場景可以用用戶組滿足哈,一般情況下的確可能按部門來設(shè)置用戶組,然后給部門授權(quán)~棒棒噠
說的好
謝謝哈
如果一個用戶組下面又分組長和組員,
q1:組長和組員的權(quán)限是不同的要怎么分
q2:組長可以創(chuàng)建組員(用戶管理),但給組員分配權(quán)限既不能高于他自己,又和他自己有區(qū)別,這個時候就矛盾了,怎么細(xì)分
這里創(chuàng)建用戶組的目的只是為了方便群體授權(quán)(該部門所有人都有的權(quán)限),權(quán)限并不能包含用戶管理。而你說的分等級應(yīng)該在角色劃分時確定
站在巨人的肩膀上我們可以看得更遠(yuǎn),而不是再造一個輪子
對!對!對!