背景：每個系統(tǒng)都會設計權(quán)限管理雌续，尤其對于B端產(chǎn)品來說斩个，會涉及多個角色用戶來使用產(chǎn)品，包括后臺系統(tǒng)驯杜、移動端業(yè)務應用等受啥。B端產(chǎn)品權(quán)限設計分為兩個模塊，包括基礎知識的學習和項目中的實際應用鸽心。
一腔呜、基礎知識
二、權(quán)限設計一般流程
三再悼、功能權(quán)限&數(shù)據(jù)權(quán)限
四、參考資料
一膝但、基礎知識
RBAC（role based access control）模型冲九，（基于用戶角色的訪問控制）
二、模型的不同分類
1.基本模型RBAC0：可以引入用戶組/權(quán)限組的概念
-用戶
-角色
-會話：會話是動態(tài)的概念，用戶必須通過會話才可以設置角色莺奸，是角色與激活的角色之間的映射關(guān)系丑孩。
-許可（操作和控制對象）
2.RBAC1角色分層模型
RBAC1在RBAC0基礎上角色新增繼承概念。比如灭贷，銷售經(jīng)理/銷售副經(jīng)理
來源于公司團隊的組織結(jié)構(gòu)温学，將角色與組織結(jié)構(gòu)進行關(guān)聯(lián)達到繼承角色模型的目的
-用戶
-角色+繼承：角色就有了上下級或者等級關(guān)系
-會話
-許可
比如：上層角色繼承下層角色的全部權(quán)限且可額外賦予權(quán)限
角色的繼承關(guān)系：
-樹形圖
-有向無環(huán)圖
3.RBAC2角色限制模型
RBAC0基礎上假設“約束”概念，引入靜態(tài)職責分離SSD和動態(tài)職責分離DSD概念甚疟。
DSD是會話和角色之間的約束仗岖，可以動態(tài)約束用戶擁有的角色，如一個用戶可以擁有兩個角色览妖，運行時只能激活一個角色轧拄。
SSD：用戶和角色的指派階段加入，對用戶和角色有如下約束：
-互斥角色：同一個用戶在兩個互斥角色中只能選擇一個
-基數(shù)約束：一個用戶擁有的角色是有限的讽膏，一個角色擁有的許可也是有限的
-先決條件約束:用戶想要獲得高級角色檩电，首先必須擁有低級角色
4.RBAC3統(tǒng)一模型
它是RBAC1+RBAC2合集，用于復雜情況下對權(quán)限系統(tǒng)進行考慮府树。
二俐末、權(quán)限設計一般流程
1.權(quán)限設計一般邏輯
1）抽象出對產(chǎn)品有訴求的的多個角色
2）依據(jù)角色的特性梳理使用場景并設計
舉例：
-當角色之間的使用場景不沖突，則不需要隔離奄侠，如網(wǎng)易云音樂的電臺和聽歌功能
-當角色之間的使用場景完全不相關(guān)卓箫，流程對立時，設計完全獨立的兩個系統(tǒng)遭铺，如滴滴的司機端和用戶端
-當角色和使用場景部分隔離部分通用丽柿，則引入權(quán)限管理的內(nèi)容
2.權(quán)限的拆分和設計
整體思路：
產(chǎn)品的權(quán)限由頁面、操作和數(shù)據(jù)構(gòu)成魂挂。頁面與操作關(guān)聯(lián)甫题，先有頁面權(quán)限再分配頁面權(quán)限下的對應的操作權(quán)限，如圖所示
基本點：
1）.權(quán)限操作是否支持前端配置：適用于有頻繁變動的自定義角色權(quán)限涂召，比如坠非，租戶體系的系統(tǒng)
2）.每個對象中，“增刪改查”各自作為一個基本單元果正，拆分為4個權(quán)限單元炎码。
3）.首先獲取頁面權(quán)限，才能夠配置當前頁面下的操作和數(shù)據(jù)權(quán)限
4）.查看權(quán)限優(yōu)先于操作權(quán)限秋泳，現(xiàn)有查看再有操作
5）.角色和權(quán)限之間的多種關(guān)系
是/否關(guān)系
數(shù)據(jù)范圍：比如潦闲，用戶只可以查看自己團隊的用戶權(quán)限
數(shù)據(jù)邊界限制（上限等）：添加人員時不能超過20個
數(shù)據(jù)字段：比如，HR查看人員列表中所有的字段迫皱，其他角色僅能查看姓名和郵箱
6）.表達方式：基于開發(fā)語言和技術(shù)模型進行表達歉闰，如圖
小tips注意點：
1.隱形的Admin：
超級管理員
將其賦予系統(tǒng)維護的工作人員
2.初始權(quán)限的賦予：游客等
3.人員管理中對自己的處理：比如，當自己為唯一管理員時，禁止編輯和刪除
4.無頁面權(quán)限的提示：避免用戶理解為系統(tǒng)bug和敬，提示“無權(quán)限”等字樣
三凹炸、功能權(quán)限&數(shù)據(jù)權(quán)限
1.功能權(quán)限
1）.功能的粒度
模塊級>頁面級>接口級（接口級別的功能權(quán)限是指哪個角色能調(diào)用哪些接口）
2）.功能的優(yōu)先級
優(yōu)先級規(guī)律：只要分配低優(yōu)先級的功能必須先分配高優(yōu)先級的功能。（比如昼弟，給操作權(quán)限沒給查看權(quán)限啤它，但是按鈕的操作在頁面上，得先給查看權(quán)限才能進行操作）
一般優(yōu)先順序為：查看詳情>查看列表>增加舱痘、刪除变骡、編輯、其他操作按鈕衰粹。
3）.跨模塊的問題
跨模塊分析的锣光，模塊A中能訪問鏈接，鏈接為模塊B中的內(nèi)容
方法一：模塊A中只可通過鏈接訪問B模塊
方法二：既有A又有B權(quán)限的人才可訪問
2.數(shù)據(jù)權(quán)限
解決用戶能看到多少數(shù)據(jù)量和看到什么數(shù)據(jù)的問題
1）.數(shù)據(jù)權(quán)限也企業(yè)的組織結(jié)構(gòu)有關(guān)系铝耻，組織架構(gòu)一般分為樹狀和扁平狀
2）.節(jié)點間的數(shù)據(jù)共享方式誊爹，如圖，假設已經(jīng)擁有功能權(quán)限
目前節(jié)點間的數(shù)據(jù)共享方式類別：
-父節(jié)點可以管理所有子節(jié)點的數(shù)據(jù)
-子階段可以管理父階段的功能
-兄弟節(jié)點之間可以互相管理
-節(jié)點只能管理自己所在節(jié)點的數(shù)據(jù)
-節(jié)點里的用戶只能看到自己的數(shù)據(jù)
實際應用時瓢捉，可選擇一種或者幾種規(guī)則频丘；可跟進業(yè)務定義管理：增刪改查及各種小功能的組合
ps：數(shù)據(jù)權(quán)限定義過程中如果出現(xiàn)同一節(jié)點下【用戶間層級問題（上下級）】需要回歸功能權(quán)限的【角色定義】去解決。
3.角色權(quán)限系統(tǒng)配置
將數(shù)據(jù)權(quán)限泡态、功能權(quán)限糅合到角色里搂漠，再行分配給用戶
從用戶操作層面看，選擇角色的過程中完成了功能權(quán)限的配置某弦，數(shù)據(jù)權(quán)限早已隨著他的所屬結(jié)點確定桐汤。
從架構(gòu)設計層面看，一開始是分開設計的靶壮，一般先做功能權(quán)限怔毛，最后會數(shù)據(jù)和功能結(jié)合看。但沒有既定的規(guī)則腾降，想清楚就好拣度。
參考資料：
-RBAC模型介紹鏈接http://www.reibang.com/p/115938c6294e
-競品：廠商SalesForce的CRM 產(chǎn)品Sales Cloud，遵循RBAC模型螃壤，實現(xiàn)了用戶抗果、角色、權(quán)限組的管理奸晴。
-權(quán)限管理：帶著枷鎖跳舞http://www.woshipm.com/pd/1241578.html
-RBAC權(quán)限管理模型：基本模型及角色模型解析及舉例http://www.woshipm.com/pd/440765.html
-角色權(quán)限設計的100種解法http://www.woshipm.com/pd/1214616.html
-3種權(quán)限模型冤馏，快速定位設計目標http://www.woshipm.com/ucd/1036860.html（待看懂
-最好的權(quán)限設計，是先區(qū)分功能權(quán)限和數(shù)據(jù)權(quán)限http://www.woshipm.com/pd/2889402.html
-如何設計網(wǎng)站權(quán)限系統(tǒng)寄啼？https://www.zhihu.com/question/20313385
-為啥別人家SaaS就是好用——權(quán)限體系設計實戰(zhàn)分析https://zhuanlan.zhihu.com/p/56410233
-權(quán)限管理平臺的產(chǎn)品設計思路http://www.woshipm.com/pd/2979056.html
