做B端產(chǎn)品售躁，權限是無法躲過的一類問題坞淮。比如，企業(yè)類軟件陪捷，不同部門碾盐、不同職位的人的權限是不同的；再例如揩局，一款軟件毫玖，不同付費層級的用戶，所使用的權限也是迥然不同的凌盯。
一付枫、權限
1.什么是權限
權限是基于實際業(yè)務的需要，設計的一套系統(tǒng)使用關系驰怎。沒有固定的方法阐滩，每個公司可能都是不一樣的。權限分為：頁面權限县忌、操作權限掂榔、數(shù)據(jù)權限。
頁面權限：誰可以訪問頁面症杏。例如装获，財務可以訪問財務報表，而銷售不可訪問財務報表頁面厉颤；
操作權限：誰可以操作數(shù)據(jù)穴豫。例如：老板和財務都可以訪問財務報表，但是財務可以增刪查改逼友，但是老板只能看精肃，不可以改；
數(shù)據(jù)權限：誰可以看哪個范圍的數(shù)據(jù)帜乞。例如：銷售一分部的老板只能看銷售一分部的數(shù)據(jù)司抱，公司的老板可以看整個公司的數(shù)據(jù)；
2.遇到的問題
網(wǎng)上很多關于RBAC的資料黎烈，大多與如何用數(shù)據(jù)表實現(xiàn)RBCA相關习柠，并不容易理解。很多人看了很多文章來描述權限怨喘、RBAC等等津畸，看了很多，還是搞不清楚權限和RBAC的關系必怜；或者看了RBAC也不知道如何去使用；在實際設計中后频，往往根據(jù)自我感覺就搭建了用戶和權限模型梳庆。自己想的模型可能會導致很多問題暖途，例如權限管理不夠靈活，權限覆蓋能力弱膏执，甚至操作混亂等驻售。
3.解決方法
實際上，已經(jīng)有成熟的RBAC模型可直接應用于權限設計更米，我們無需自己拍腦袋設置用戶權限模型欺栗，正如牛頓所言，站在巨人的肩膀上才能看的更遠征峦。我們不妨去參照已有的比較成熟的權限模型RBAC（Role-Based Access Control）——基于角色的訪問控制迟几。我會以產(chǎn)品經(jīng)理的角度去解析RBAC模型，并分別舉例如何運用這套已得到驗證的成熟模型栏笆。
二类腮、RBAC模型
1.傳統(tǒng)權限模型
在沒有RBAC前，傳統(tǒng)權限模型通過賬號直接配置權限蛉加。每一個賬號都需要勾選賬號對應的每一個權限蚜枢，如下圖≌爰ⅲ可見非常繁瑣厂抽，維護起來非常麻煩。
2.RBAC概念
RBAC增加了“角色”的概念丁眼，我們首先把權限賦予角色修肠，再把角色賦予用戶。這樣户盯，由于增加了角色嵌施，授權會更加靈活方便。在RBAC中莽鸭，根據(jù)權限的復雜程度吗伤，又可分為RBAC0、RBAC1硫眨、RBAC2足淆、RBAC3，RBAC4礁阁。其中巧号，RBAC0是基礎，RBAC1姥闭、RBAC2丹鸿、RBAC3、RBAC4都是以RBAC0為基礎的升級棚品。我們可以根據(jù)自家產(chǎn)品權限的復雜程度靠欢，選取適合的權限模型廊敌。
3.RBAC0：基本模型
解析：RBAC0是RBAC模型中最基本的模型，很多產(chǎn)品只需基于RBAC0就可以搭建權限模型了门怪。用戶與角色可為多對一或多對多的關系骡澈，當一個用戶的角色為多對多時，當前用戶的權限是多個角色的并集掷空。
舉例：譬如我們做一款企業(yè)管理產(chǎn)品肋殴，如果按傳統(tǒng)權限模型，給每一個用戶賦予權限則會非常麻煩坦弟，并且做不到批量修改用戶權限护锤。這時候，可以抽象出幾個角色减拭，譬如銷售經(jīng)理蔽豺、財務經(jīng)理、市場經(jīng)理等拧粪，然后把權限分配給這些角色修陡，再把角色賦予用戶。這樣無論是分配權限還是以后的修改權限可霎，只需要修改用戶和角色的關系魄鸦，或角色和權限的關系即可，更加靈活方便癣朗。此外拾因，如果一個用戶有多個角色，譬如王先生既負責銷售部也負責市場部旷余，那么可以給王先生賦予兩個角色绢记，即銷售經(jīng)理+市場經(jīng)理，這樣他就擁有這兩個角色的所有權限正卧。
4.RABC1：用戶組/權限組模型
解析：在RABC0的基礎上蠢熄，加入了用戶組的概念。賬號既可以通過角色來配置權限炉旷，也可以通過用戶組來配置權限签孔。這樣做的好處是，若存在多個角色具有統(tǒng)一的權限窘行，無需對每一個角色的共同權限進行配置饥追。僅需將共同權限配置在用戶組，使賬號歸屬于用戶組即可罐盔；（此級別但绕，也可同時存在權限組，類似于用戶組翘骂，這里就不細講了）
一個賬號可以既存在用戶組也存在角色壁熄，權限范圍為其的并集帚豪；
舉例：會計碳竟、出納草丧、公司老板均可以查看公司的財務報表，但是操作不同莹桅，會計審核昌执，出納付款，老板僅查看诈泼；此時只需要抽象出一個報表查看用戶組懂拾，用戶組配置所需查看的報表，再將會計铐达、出納岖赋、公司老板都加入用戶組；這樣瓮孙，加入用戶組的用戶都可以查看報表唐断；再將會計和出納角色配置單獨的操作權限，一并賦予杭抠，這樣會計和出納就既擁有了用戶組的權限（可查看報表）脸甘，以及獨特的操作權限（審核/付款）
5.RBAC2：角色繼承模型
解析：角色繼承，講一個角色分為多個級別偏灿，高級別的角色可繼承低級別角色的權限丹诀，上層角色繼承下層角色的全部權限，且可額外賦予權限翁垂。
舉例：
基于之前RBAC0的例子铆遭，我們又發(fā)現(xiàn)一個公司的財務經(jīng)理可能是分三個等級的，財務經(jīng)理沿猜、財務組長枚荣、財務員工。財務組長只有財務經(jīng)理的部分權限邢疙。這時候棍弄，我們就可以采用RBAC1的分級模型，把財務這個角色分成多個等級疟游，給財務組長賦予較低的等級即可呼畸。
6.RBAC3：角色限制模型
解析：角色限制的RBAC模型，指的是當用戶可以存在多個角色時颁虐，多個角色質(zhì)檢存在限制條件蛮原。例如，一個人不能既是裁判另绩，又是運動員儒陨；這些限制可以分成兩類花嘶，即靜態(tài)職責分離SSD(Static Separation of Duty)和動態(tài)職責分離DSD(Dynamic Separation of Duty)。
舉例：
基于之前RBAC0的例子蹦漠，我們又發(fā)現(xiàn)有些角色之間是需要互斥的椭员，譬如給一個用戶分配了財務經(jīng)理的角色，就不能給他再賦予審計經(jīng)理的角色了笛园，否則他即可以錄入賬單又能自己審核賬單隘击；再譬如，有些公司對角色的升級十分看重研铆，一個財務員工要想升級到財務經(jīng)理埋同，必須先升級到財務主管，這時候就要采用先決條件限制了棵红。
7.RBAC4：統(tǒng)一模型
RBAC4是RBAC2和RBAC3的合集凶赁，所以RBAC3既有角色分層，也包括可以增加各種限制逆甜。
舉例：
這個就不舉例了虱肄，統(tǒng)一模型RBAC3可以解決上面三個例子的所有問題。當然忆绰，只有在系統(tǒng)對權限要求非常復雜時浩峡，才考慮使用此權限模型。
8.擴展案例
①公司架構如圖错敢，共有三種職能：前沿銷售翰灾、前臺、銷售稚茅、老板纸淮，各職能角色分別如上圖。前沿銷售需要查看和操作客戶列表亚享、訂單列表咽块，銷售需要查看和操作客戶列表、訂單列表欺税，前臺需要查看和操作客戶列表侈沪，老板需查看所有的頁面，但不可操作晚凿。
②權限說明：
1.頁面權限：前沿銷售——客戶列表亭罪、訂單列表；銷售員工——客戶列表歼秽、訂單列表应役；銷售主管——客戶列表、訂單列表、銷售報表箩祥；前臺——客戶列表院崇；老板——所有頁面；
2.操作權限：前沿銷售——客戶列表（新增袍祖、刪除）底瓣、訂單列表（新增）；銷售員工——客戶列表（新增盲泛、刪除）濒持、訂單列表（新增）键耕；銷售主管——客戶列表（新增寺滚、刪除）、訂單列表（新增）屈雄、銷售報表（導出）村视；前臺——客戶列表（新增）；老板——所有頁面（無）酒奶；
3.數(shù)據(jù)權限：前沿銷售——客戶列表（本人）蚁孔、訂單列表（本人）；銷售員工——客戶列表（本人）惋嚎、訂單列表（本人）杠氢；銷售主管——客戶列表（本人及本人下屬）、訂單列表（本人及本人下屬）另伍、銷售報表（本人及本人下屬）鼻百；前臺——客戶列表（本人）；老板——所有頁面（全部）摆尝；
③運用RBAC0
1.頁面&操作權限：新建角色温艇，勾選對應的頁面以及操作
2.數(shù)據(jù)權限：新建數(shù)據(jù)權限，勾選對應查看數(shù)據(jù)的范圍
但此時不要忘記木人，系統(tǒng)當前對賬號之間的關系并不清楚窥岩，也就是系統(tǒng)并不知道賬號的上下級關系迫吐；所以數(shù)據(jù)權限還需要搭配部門上下級的功能。
這樣系統(tǒng)就知道琐鲁，賬號所處的部門，也就可以配置銷售主管查看下屬的數(shù)據(jù)了人灼，如下围段；
此時，該賬號已具備挡毅，1.查看本人及下屬的數(shù)據(jù)權限? 2.查看客戶列表蒜撮、操作客戶列表的功能
9.最后的話
無論是本次的權限模型，還是其他產(chǎn)品相關實現(xiàn)方案，很多都已經(jīng)被前人所總結提煉段磨，我們應深度掌握這些成熟的知識和經(jīng)驗取逾，而不是絞盡腦汁自我推理。我們只需要使用輪子苹支，不需要自己創(chuàng)造輪子砾隅。（本文部分借鑒其他文章，如有雷同债蜜，是我抄你【偷懶了晴埂，還請諒解】）
