通過rbac建立後台許可權體系。什麼是許可權體系呢，比如，在系統中a分站的使用者不能看到b分站的資料，業務員能看到自己的資料而看不到其他業務員的資料，業務經理可以看到所有業務員的資料，業務經理和財務經理擁有的功能許可權又不相同，這些場景，都是通過許可權控制完成的。
對於後台產品，一定是多使用者多角色多許可權的系統，如果沒有搭建好許可權體系，可能導致：
許可權控制缺失造成風險，
使用者組織架構無法建立，
業務系統拓展會變得艱難且混亂...
下面開始站在巨人的肩膀上，總結一下rbac怎麼控制許可權
rbac，全稱是role-based access control，基於角色的訪問控制，就是使用者通過角色與許可權進行關聯。簡單地說，就是把許可權賦給角色，使用者再通過啟用角色獲得該角色下的所有許可權，這樣，構造成「使用者-角色-許可權」的授權模型。通過這種方式，角色的許可權可以靈活配置，使用者的許可權的變化只需要改變角色。
舉乙個例子：老王是乙個財務，需要系統的財務報表許可權，錢包許可權，優惠券許可權...，管理員直接給他分配了這些許可權，後來老王來了乙個同事，設定這些許可權也沒啥問題，那如果來了100個新同事呢，管理員可以崩潰了。
如果採用rbac模型呢，將會是這樣的：
管理員先設定好乙個財務角色，並且分給財務角色相關的許可權，每來乙個新同事，分給他財務的角色就好了。這樣既能減少操作，又方便統一管理。
許可權分為功能許可權和資料許可權。
1、功能許可權
就是對於功能操作的許可權，粗略點可以通過頁面控制，就是給財務分配了錢包管理的許可權，那麼老王就能看到錢包的介面，而業務員小張就看不到這個頁面。但是這樣的許可權劃分不是最精確的，也可以把功能許可權的粒度更細化，細化到功能按鈕，頁面上的增刪查改，都通過許可權來分配。
2、資料許可權
資料許可權則是控制你可以看到哪些資料，a分站的人只能看到a分站的資料，比如老王和老李分屬ab分站的財務，雖然功能許可權相同，但是他們能夠看到的資料僅是自己所屬分站下面的資料。
更深入的應用——rbac96
rbac96是乙個模型族，其中包括rbac0~rbac3四個概念性模型。
1、rbac0
就是上面介紹的基礎模型，許可權賦予角色，使用者分配角色，角色與使用者之間只多對多的關係，角色和許可權之間也是多對多的關係。
直接上圖，新增使用者直接選擇系統中已經維護好的角色，角色對應了許可權，新建的賬號直接擁有了對應角色的許可權。
2、rbac1
基於rbac0模型，引入角色間的繼承關係，即角色上有了上下級的區別，老王是個財務總監，那麼新來的小王是會計，小王只能有老王許可權裡的一部分許可權，那麼對應到系統財務這個角色上，就分成了財務經理和普通財務兩種等級，角色「普通財務」的許可權繼承自「財務經理」。
3、rbac2
4、rbac3
將rbac1和rbac2進行整合了，既有角色分級，又存在限制條件。
以上這是對於rbac的基本解讀，實際應用中要以此為基礎，結合業務需求，再轉化成不同的產品方案。
RBAC基於角色的許可權管理模型
a.安全性 防止誤操作，防止資料洩露，保證資訊的安全。b.資料隔離 保持不同的角色具有不同的許可權，只能看到自己許可權範圍內的資料 a.傳統的許可權管理 隨著使用者數量的增大和使用者許可權區別的增大，傳統的許可權管理需要針對每個使用者依次管理，成本較高。b.rbac role based acces...
基於RBAC模型的許可權管理系統的設計和實現
圖1 rbac0模型 a.rbac0定義了能構成乙個rbac控制系統的最小的元素集合。在rbac之中,包含使用者users users 角色roles roles 目標objects obs 操作operations ops 許可權permissions prms 五個基本資料元素，許可權被賦予角色...
專案 RBAC模型與許可權設計
一.rbac模型 什麼是rbac rbac 全稱 role based access control 基於角色的許可權訪問控制，作為傳統訪問控制 自主訪問，強制訪問 的有前景的代替受到廣泛的關注。在rbac中，許可權與角色相關聯，使用者通過成為適當角色的成員而得到這些角色的許可權。這就極大地簡化了許...