2019/3/10
什么是RBAC
權限系統(tǒng)通常基于RBAC（Role-Based Access Control）的思想設計，擁有4個關鍵元素：
用戶 – 角色 – 權限 – 資源。
λ 資源
被安全管理的對象（Resources頁面佛寿、菜單、按鈕、訂單等）
λ 權限
訪問和操作資源的許可（Permit刪除容客、編輯、審批等）
λ 角色
我們通過業(yè)務流程確定一個角色约郁，實際是確定角色并角色具備的那些權限的過程缩挑，角色所以是權限的集合，是眾多權限顆粒組成鬓梅；
我們通過把權限給這個角色供置，再把角色給用戶，從而實現(xiàn)用戶的權限绽快，因此它承擔了一個橋梁的作用芥丧。
引入角色這個概念，可以幫助我們靈活的擴展谎僻，使一個用戶可以具備多種角色娄柳。
λ 用戶
系統(tǒng)實際的操作員（User）
【用戶(user：誰)】被賦予【角色(role：具有1-n個權限)】，通過角色關聯(lián)的【權限(permit：許可)】去訪問/操作【資源(resource)】
場景：
張三（user）是人事主管（role）艘绍，可以看到李四的請假申請（resource）赤拒，并批復同意（permit）
為什么需要RBAC
傳統(tǒng)權限模型
傳統(tǒng)模型中無角色概念，用戶直接被賦予權限诱鞠；
1挎挖、 導致配置權限相當麻煩
2、 無法快速為多個用戶批量刪除/編輯權限
3航夺、 用戶多身份下權限配置維護麻煩
用戶—角色—權限多對多的關系蕉朵，解決了這些問題，權限修改只需對角色的關聯(lián)權限進行修改阳掐。
若多身份始衅，只需多用戶進行多角色賦予即可。
權限通過角色來賦予至用戶缭保，使得用戶即使發(fā)生變更汛闸、離職也不會影響權限本身的穩(wěn)定性。
RBAC Types
RBAC模型可以分為4種類型：
RBAC0/ RBAC1/ RBAC2/ RBAC3
1艺骂、2诸老、3種衍生類型均給予RBAC0衍化。
RBAC0
場景：
公司運營時段時間了钳恕，形成了不同的部門别伏，每個部門專注于自身的工作內容和客戶蹄衷，不同身份的員工應當杜絕互相看到或具備干預其他部門的業(yè)務情況出現(xiàn)，所以需要對每個員工進行權限的控制厘肮。
此場景處理時引入RBAC處理如下：
前提：資源已經被抽象出來愧口，資源關聯(lián)的權限已經清晰。
抽象定義階段
1轴脐、抽取資源及相關權限
員工管理
查看員工调卑、新增員工、修改員工大咱、刪除員工… else
客戶管理
查看客戶恬涧、新增客戶、修改客戶碴巾、刪除客戶… else
… else
2溯捆、定義角色及關聯(lián)相關權限
角色定義，一般從崗位進行抽取厦瓢，或者通過業(yè)務流程進行定義提揍。
是指在組織內需要承擔特定的動作或活動，并且可能與其他業(yè)務角色有互動的角色煮仇。
角色? ? ? ? ? ?權限
人事專員? ? 查看員工劳跃、新增員工、修改員工浙垫、刪除員工… else
銷售專員? ? 查看客戶刨仑、新增客戶、修改客戶夹姥、刪除客戶… else
… else?
功能落地階段
1杉武、構建角色
2、賦予員工對應角色
RBAC0是RBAC權限模型基礎辙售。
權限設計時將權限賦予給角色轻抱，而不是用戶，一個用戶可以擁有若干角色旦部，從而使用戶可以獲得更廣泛的權限祈搜。
就此構造成“用戶- 角色- 權限”的授權模型。
在這種模型中士八，用戶與角色之間容燕，角色與權限之間，一般者是多對多的關系曹铃。
角色和權限綁定，用戶被賦予相應的角色捧杉，通過多對多的關系來實現(xiàn)授權和授權的快速變更陕见，從而控制用戶對系統(tǒng)的功能使用和數(shù)據訪問權限秘血。
在RBAC模型下，我們只需要將組織中的角色進行抽象评甜，例如銷售經理灰粮、財務經理、市場經理忍坷、市場專員...
然后把權限分配給這些角色粘舟，再把角色賦予用戶。
這樣無論是分配權限還是后期進行權限的修改佩研，只需要修改用戶和角色的關系（分配）柑肴，或角色和權限的關系即可（維護），更加靈活方便旬薯。
此外晰骑，如果一個用戶有多個角色。
譬如王先生既負責銷售部也負責市場部绊序，那么可以給王先生賦予兩個角色硕舆，即銷售經理和市場經理，這樣他就擁有這兩個角色的所有權限骤公。
RBAC1
場景：
A公司新招很多員工抚官，其中包括很多管理崗位，it部門在位新員工開通賬號時發(fā)現(xiàn)阶捆，給管理崗位員工進行角色賦予時遇到一個很麻煩的問題凌节，管理崗位不能直接擁有下屬的權限，
比如給銷售經理角色進行分配時趁猴，下面的銷售專員扣讼，銷售助理等她們的權限銷售經理是不能直接獲得的。
怎樣才能讓銷售經理直接擁有下屬員工的權限呢鹿寻？
這種情況就適合RBAC1模型渐尿，對角色進行繼承。
基于RBAC0模型捕犬，引入角色間的繼承關系跷坝，即角色上有了上下級的區(qū)別；
角色間的繼承關系可分為一般繼承（General）和受限繼承（Limited）碉碉。
λ 一般繼承關系：
要求角色繼承關系是一個絕對偏序關系柴钻，允許角色間的多繼承。
λ 受限繼承關系：
進一步要求角色繼承關系是一個樹結構垢粮，實現(xiàn)角色間的單繼承贴届。
受限繼承則增強了職責關系的分離
一般繼承和受限繼承的區(qū)別，一般繼承是圖；
受限繼承可以有多個父節(jié)點毫蚓，但子節(jié)點只能有一個占键，是一個反向樹結構。
概念圖解：
λ 一般繼承關系
行政主管
|
|--------------------|--------------------|
|? ? ? ? ? ? ? ? ? ? ? ? |? ? ? ? ? ? ? ? ? ? ? ? |
v? ? ? ? ? ? ? ? ? ? ? ?v? ? ? ? ? ? ? ? ? ? ? ?v
行政管理員? ? ? 行政秘書? ? ? ? ? ?行政專員
xx權限? ? ? ? ? ? ?xx權限? ? ? ? ? ? ? ?xx權限
行政主管權限繼承自行政管理員元潘、行政秘書畔乙、行政專員
λ 受限繼承關系
角色繼承用來解決組織機構之間的權限關系。
角色繼承的方向和用戶關系的方向時相反的翩概，舉例：
用戶繼承關系–>
業(yè)務員 -> 部門經理->總經理
角色繼承關系->
總經理-> 部門經理->業(yè)務員
舉例：所有role_Sales（業(yè)務員）的權限role_Mgr（部門經理）都具有牲距，那么即role_Mgr）繼承自role_Sales。
了解基本概念后钥庇，以上場景解決方案如下：
1牍鞠、抽取業(yè)務角色
行政主管、行政專員上沐、行政助理 … else
銷售主管皮服、銷售專員、銷售助理 … else
產品主管参咙、產品專員龄广、產品助理 … else
人力主管、人力專員蕴侧、人力助理 … else
市場主管择同、市場專員、市場助理 … else
… else
2净宵、確定角色層級關系
行政主管
|--------------------|--------------------|
v? ? ? ? ? ? ? ? ? ? ? ?v? ? ? ? ? ? ? ? ? ? ? ?v
行政專員? ? ? ? ? ?行政助理? ? ? ? ?行政…
… else
3敲才、確定角色與用戶賦予關系
哪些用戶，需要被賦予那些角色择葡。
功能落地階段
1紧武、角色創(chuàng)建/維護
2、用戶創(chuàng)建/角色分配
角色管理
角色名稱? ? 繼承角色? ? ? ? ? ? ? ? ? 生效? ? ?操作? ? ? ? ? ?更新時間
行政專員? ? 無? ? ? ? ? ? ? ? ? ? ? ? ? ? ?是? ? ? ? 修改/刪除? ? Date
行政助理? ? 無? ? ? ? ? ? ? ? ? ? ? ? ? ? ?否??
行政主管? ? 行政專員敏储、行政助理???
xx專員? ? ? ?無? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 是? ? ? ? ?修改/刪除? ? Date
xx助理? ? ? 無? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 否??
xx主管? ? ? ?xx專員阻星、xx助理???
… else????
RBAC2
場景：
最近公司議論紛紛，因為一個叫張瑪麗的同事已添，他是老板的小姨子妥箕，但在公司卻即是會計，還同時是審計更舞，這錢怎么支出的畦幢，合規(guī)不合規(guī)大家都不知道，財務總監(jiān)也犯怵缆蝉，萬一真在錢上出了叉子可怎么辦瘦真？
這種情況就適合RBAC2模型，對角色進行限制雷逆。
RBAC2同樣建立在RBAC0基礎之上，僅是對用戶、角色和權限三者之間增加了一些限制兴喂，實現(xiàn)了責任分離酱酬。
RBAC2約束當角色被賦予給用戶時，或用戶在某一個時刻激活了一個角色時陨界，需要遵循一些強制性的規(guī)則录平。
這些限制可以分成兩類，
即靜態(tài)職責分離SSD(Static Separation of Duty)和動態(tài)職責分離DSD(Dynamic Separation of Duty)。
約束（Constraining）和 用戶– 角色– 權限一起決定了RBAC2模型下用戶的訪問許可崔拥。
λ 靜態(tài)職責分離（SSD）
當角色授權給用戶時，需要判斷當前用戶是否被賦予了一個與新角色沖突的角色，沖突的角色位一個二元關系，任何一個用戶在此場景下只能擁有其中一個角色。
λ 動態(tài)職責分離（DSD）
在角色分配時可以將沖突的角色賦予給同一個用戶，但是在用戶使用系統(tǒng)時阳似，一次會話中不能同時激活兩個角色畜吊。
舉例（引用）：
在超市POS系統(tǒng)中捌年，楊翠花可以即是收銀員（role_staff）虏劲，也是收銀主管（role_dire）。
收銀員必須要經過主管才能打開收銀機的抽屜修改某次結算錯誤。
在此場景下，DSD要求用戶必須先放棄收銀員的角色砾层；
即，當發(fā)生結算錯誤時贱案，收銀員需要先關閉抽屜宝踪，然后再以收銀主管的身份打開抽屜秕重，才可以進行結算糾正相關的處理。
RBAC2對角色的限制有此類：
角色互斥形庭、基數(shù)約束厌漂、先決條件角色約束萨醒、運行時互斥等倍宾。
1. 角色互斥（SSD）：用戶不能分配到互斥角色集合中的多個，在互斥的角色中只能選擇一個
如：財務當中的會計和審計不能同時被賦予給同一個用戶
2. 基數(shù)約束（SSD）：一個用戶能夠擁有的角色是有限的胜嗓，一個角色擁有的權限也是有限的
如：某個角色是為CEO準備的高职，那就不能有多個
3. 先決條件角色（SSD）：用戶想要獲得較高的權限，受限需要獲得低一級的權限
如：有副經理的權限才能有總經理的權限
4. 運行時互斥（DSD）：如果用戶同時擁有多個互斥角色辞州，但運行時只能激活其中一個角色
如：想要給自己發(fā)工資就需要先放棄自己員工的角色
針對本次場景怔锌，解決方案如下：
采用動態(tài)責任分離處理互斥角色處理
抽象定義階段
1、抽取業(yè)務角色
行政主管变过、行政專員埃元、行政助理 … else
銷售主管、銷售專員媚狰、銷售助理… else
產品主管岛杀、產品專員、產品助理 … else
人力主管崭孤、人力專員类嗤、人力助理 … else
市場主管、市場專員辨宠、市場助理 … else
… else
2遗锣、確定角色互斥關系
角色名稱? ? 互斥角色集合
會計? ? ? ? ? ?審計、出納 … else
3嗤形、確定角色與用戶賦予關系
哪些用戶精偿，需要被賦予那些角色。
功能落地階段
1赋兵、構建角色
2笔咽、角色賦予
RBAC3
RBAC3時RBAC1和RBAC2的合集，這種模式即要維護好角色間的繼承關系處理好分層霹期，又要處理角色間的責任分離拓轻。
統(tǒng)一模型：
RBAC3 = RBAC1 + RBAC2
權限設計基本的模塊劃分
權限設計基本圍繞權限本身相關資源展開，核心包含用戶经伙、權限扶叉、角色等
（簡單作為演示說明，實際根據業(yè)務豐富）
用戶管理
用戶為系統(tǒng)使用者帕膜，對應實際環(huán)境的員工枣氧。
用戶的管理包括用戶的構建，刪除垮刹，信息修改达吞，激活，禁用荒典，角色授權等酪劫。
用戶構建（示意）
如果授權動作叫復雜吞鸭，內容項較多，用戶構建覆糟、用戶角色授權可以分開刻剥，上圖僅做示意
No 名稱? ? ? ? 工號部門 職位? ? ? ? ? ?賬號? ? ? ? ? ? ? ?角色? ? ? ? ? ? ? ? ?狀態(tài)? ? 操作
1? ? 楊翠花? ? 10? ? xx? ? 收銀柜臺? ? cuihuayang? ? 收銀員，xxx? ? 激活? ? xxx/xxx
…????????
用戶列表（示意）
角色管理
角色創(chuàng)建（示意）
編號? ? 角色名稱? ? 狀態(tài)? ? 權限? ? ? ? ? ? ? ? 對應用戶? ? ? ? ? 操作
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?xxx/xxx/xxx? ? ?xxx/xxx/xxx?
角色列表（示意）
權限管理
權限管理從功能操作（頁面+功能）滩字、數(shù)據管理兩個不同顆粒度等級來考量的造虏。
權限的抽取可以是開發(fā)層面隨著項目的迭代同時進行權限的控制，也可以做成后臺進行統(tǒng)一管理
構建權限（示意）
權限名稱? ? ? ? ? ?權限類型? ? 權限地址? ? 管理操作?
查看付款申請? ? 功能權限? ? abc/def? ? ? ? 編輯/刪除?
… else????
權限顆粒– 功能菜單權限
粗力度權限控制麦箍，獲得當前權限后頁面所有數(shù)據可查看或操作
權限顆粒– 功能操作權限
比菜單權限更細化漓藕，具象到不同角色即使看到相同數(shù)據，所具備的操作管理權限也不一樣
權限顆粒– 數(shù)據字段權限
最細顆粒的權限控制挟裂，實現(xiàn)了不同角色進入后享钞，看到的數(shù)據字段都會不同。
