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、RBAC一、RBAC二、RBAC3 ，若是你不知道他們有什麼區別，你能夠百度百科：百度百科-RBAC 估計你看不懂。仍是看看個人簡單介紹。

我這裏結合個人看法，簡單的描述下（去掉那麼多的廢話）。

RBAC0、RBAC一、RBAC二、RBAC3簡單介紹。

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

 

RBAC0，RBAC的核心。

RBAC1，基於角色的分層模型

RBAC二、是RBAC的約束模型。

RBAC三、就是RBAC1+RBAC2

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

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

關係圖，以及實體設計。

表設計

在咱們日常的權限系統中，想徹底遵循  RBAC  模型是很難的，由於不免系統業務上有一些差別化的業務考量，因此在設計之初，不要太理想，太追求嚴格的  RBAC  模型設計，由於這樣會使得你的系統到處雞肋，沒法拓展。

因此在這裏要說明一下，  RBAC  是一種模型，是一種思想，是一種核心思想，可是就思想而言，不是要你徹底參照，而是你在這個基礎之上，融入你本身的思想，賦予你的業務之上，達到適用你的業務。因此要批評一下那些說：「RBAC模型是垃圾，按照它思路去執行，結果沒法拓展。」之類話語的人。那是你本身不會變通。

言歸正傳。

背景需求：

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

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

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

F~H：負責售後。

... ...

那麼這些客服也是歸屬到這個商家下面去。並且每一個商家可能都有相似的客服，分工徹底靠商家本身去分配管理。

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

一、權限賦予：

權限賦予是把當前用戶的權限拉出來，而後分配的客服能夠小於等於當前用戶的權限。

二、權限加載：

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

三、權限判斷：

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

四、禁用|啓用：

禁用啓用，也是正常的用戶流程，添加到禁用列表裏，若是被禁用，就沒法操做任何內容。

 

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

 

 

 

下面發佈一篇基於RBAC3 的設計模型，設計的 Shiro  + SpringMVC  + Mybatis  的 Demo  。

Demo連接：http://www.sojson.com/shiro