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、禁用|啟用：
禁用啟用，也是正常的用戶流程，添加到禁用列表里，如果被禁用，就無法操作任何內容。
總之：不要讓框框架架來限制你的業務，也不要讓你的業務局限於框框架架。但是也不推薦你去改動框框架架，而是基於框框架架做業務封裝。
下面發布一篇基於RBAC3 的設計模型，設計的 Shiro + SpringMVC + Mybatis 的 Demo 。
Demo鏈接：http://www.sojson.com/shiro