RBAC 介紹 (權限)

RBAC是什么？

RBAC  是基於角色的訪問控制（Role-Based Access Control ）在 RBAC  中，權限與角色相關聯，用戶通過成為適當角色的成員而得到這些角色的權限。這就極大地簡化了權限的管理。這樣管理都是層級相互依賴的，權限賦予給角色，而把角色又賦予用戶，這樣的權限設計很清楚，管理起來很方便。

RBAC介紹。

RBAC  認為授權實際上是Who 、What 、How 三元組之間的關系，也就是Who 對What 進行How 的操作，也就是“主體”對“客體”的操作。

Who：是權限的擁有者或主體（如：User，Role）。

What：是操作或對象（operation，object）。

How：具體的權限（Privilege,正向授權與負向授權）。

然后 RBAC  又分為RBAC0、RBAC1、RBAC2、RBAC3 ，如果你不知道他們有什么區別，你可以百度百科：百度百科-RBAC 估計你看不懂。還是看看我的簡單介紹。

我這里結合我的見解，簡單的描述下（去掉那么多的廢話）。

RBAC0、RBAC1、RBAC2、RBAC3簡單介紹。

• RBAC0：是RBAC的核心思想。
• RBAC1：是把RBAC的角色分層模型。
• RBAC2：增加了RBAC的約束模型。
• RBAC3：其實是RBAC2 + RBAC1。

 

RBAC0，RBAC的核心。

RBAC1，基於角色的分層模型

RBAC2、是RBAC的約束模型。

RBAC3、就是RBAC1+RBAC2

估計看完圖后，應該稍微清楚一點。

下面來看個Demo。員工權限設計的模型圖，以及對應關系。

關系圖，以及實體設計。

表設計

在我們平常的權限系統中，想完全遵循  RBAC  模型是很難的，因為難免系統業務上有一些差異化的業務考量，所以在設計之初，不要太理想，太追求嚴格的  RBAC  模型設計，因為這樣會使得你的系統處處雞肋，無法拓展。

所以在這里要說明一下，  RBAC  是一種模型，是一種思想，是一種核心思想，但是就思想而言，不是要你完全參照，而是你在這個基礎之上，融入你自己的思想，賦予你的業務之上，達到適用你的業務。所以要批評一下那些說：“RBAC模型是垃圾，按照它思路去執行，結果無法拓展。”之類話語的人。那是你自己不會變通。

言歸正傳。

背景需求：

需要在“權限”=>“角色”=>“用戶”之間，在賦予一個特殊的角色“客服”，這個需求比較常見，我一個用戶想把我的權限分配到“客服”角色上，然后由幾個“客服”去操作對應的業務流程。比如我們的天貓，淘寶商家后天就是如此，當店鋪開到一定的規模，那么就會有分工。

A客服：負責打單填寫發貨單。

B~E客服：負責每天對我們說“親，您好。祝親生活愉快！”，也就是和我們溝通交流的客服。

F~H：負責售后。

... ...

那么這些客服也是歸屬到這個商家下面去。而且每個商家可能都有類似的客服，分工完全靠商家自己去分配管理。

這樣的系統，融合我們的權限控制，關鍵要看“客服”用戶的添加是在哪添加，如果是由客服直接添加，不走我們的統一注冊流程，那建議不要融合到上面這一套 權限、角色、用戶之間去，而是給用戶再多一個綁定，把多個用戶綁定到客服下，並且給客服賦予對應的權限。

1、權限賦予：

權限賦予是把當前用戶的權限拉出來，然后分配的客服可以小於等於當前用戶的權限。

2、權限加載：

正常的加載權限，當用戶登錄后，並且第一次使用權限判斷的時候，  Shiro  會去加載權限。

3、權限判斷：

走正常用戶權限判斷，但是數據操作需要判斷是不是當前歸屬的用戶的數據，其實這個是屬於業務層，就算你不是客服，也是需要判斷。

4、禁用|啟用：

禁用啟用，也是正常的用戶流程，添加到禁用列表里，如果被禁用，就無法操作任何內容。

 

總之：不要讓框框架架來限制你的業務，也不要讓你的業務局限於框框架架。但是也不推薦你去改動框框架架，而是基於框框架架做業務封裝。