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