rbac是什麼？
rbac 是基於角色的訪問控制（role-based access control）在rbac 中，許可權與角色相關聯，使用者通過成為適當角色的成員而得到這些角色的許可權。這就極大地簡化了許可權的管理。這樣管理都是層級相互依賴的，許可權賦予給角色，而把角色又賦予使用者，這樣的許可權設計很清楚，管理起來很方便。
rbac 認為授權實際上是who、what、how三元組之間的關係，也就是who對what進行how的操作，也就是「主體」對「客體」的操作。
who：是許可權的擁有者或主體（如：user，role）。
what：是操作或物件（operation，object）。
how：具體的許可權（privilege,正向授權與負向授權）。
我這裡結合我的見解，簡單的描述下（去掉那麼多的廢話）。
估計看完圖後，應該稍微清楚一點。
下面來看個demo。員工許可權設計的模型圖，以及對應關係。
關係圖，以及實體設計。
表設計在我們平常的許可權系統中，想完全遵循 rbac 模型是很難的，因為難免系統業務上有一些差異化的業務考量，所以在設計之初，不要太理想，太追求嚴格的 rbac 模型設計，因為這樣會使得你的系統處處雞肋，無法拓展。
所以在這裡要說明一下， rbac 是一種模型，是一種思想，是一種核心思想，但是就思想而言，不是要你完全參照，而是你在這個基礎之上，融入你自己的思想，賦予你的業務之上，達到適用你的業務。所以要批評一下那些說：「rbac模型是垃圾，按照它思路去執行，結果無法拓展。」之類話語的人。那是你自己不會變通。
言歸正傳。
背景需求：
需要在「許可權」=>「角色」=>「使用者」之間，在賦予乙個特殊的角色「客服」，這個需求比較常見，我乙個使用者想把我的許可權分配到「客服」角色上，然後由幾個「客服」去操作對應的業務流程。比如我們的天貓，**商家後天就是如此，當店鋪開到一定的規模，那麼就會有分工。
a客服：負責打單填寫發貨單。
b~e客服：負責每天對我們說「親，您好。祝親生活愉快！」，也就是和我們溝通交流的客服。
f~h：負責售後。
那麼這些客服也是歸屬到這個商家下面去。而且每個商家可能都有類似的客服，分工完全靠商家自己去分配管理。
這樣的系統，融合我們的許可權控制，關鍵要看「客服」使用者的新增是在哪新增，如果是由客服直接新增，不走我們的統一註冊流程，那建議不要融合到上面這一套 許可權、角色、使用者之間去，而是給使用者再多乙個繫結，把多個使用者繫結到客服下，並且給客服賦予對應的許可權。
許可權賦予是把當前使用者的許可權拉出來，然後分配的客服可以小於等於當前使用者的許可權。
正常的載入許可權，當使用者登入後，並且第一次使用許可權判斷的時候， shiro 會去載入許可權。
走正常使用者許可權判斷，但是資料操作需要判斷是不是當前歸屬的使用者的資料，其實這個是屬於業務層，就算你不是客服，也是需要判斷。
禁用啟用，也是正常的使用者流程，新增到禁用列表裡，如果被禁用，就無法操作任何內容。
下面發布一篇基於rbac3的設計模型，設計的 shiro + springmvc + mybatis 的demo 。
許可權管理系統（四） RBAC許可權模型分類介紹
rbac是role basedaccess control的英文縮寫，意思是基於角色的訪問控制。rbac認為許可權授權實際上是who what how的問題。在rbac模型中，who what how構成了訪問許可權三元組，也就是 who對what which 進行how的操作，也就是 主體 對 客...
rbac許可權管理設計 RBAC使用者角色許可權設計方案
rbac role based access control，基於角色的訪問控制 就是使用者通過角色與許可權進行關聯。簡單地說，乙個使用者擁有若干角色，每乙個角色擁有若干許可權。這樣，就構造成 使用者 角色 許可權 的授權模型。在這種模型中，使用者與角色之間，角色與許可權之間，一般者是多對多的關係。...
RBAC許可權管理
rbac role based access control，基於角色的訪問控制 就是使用者通過角色與許可權進行關聯。簡單地說，乙個使用者擁有若干角色，每乙個角色擁有若干許可權。這樣，就構造成 使用者 角色 許可權 的授權模型。在這種模型中，使用者與角色之間，角色與許可權之間，一般者是多對多的關係。...