RBAC 介紹 許可權

2022-07-26 22:42:09 字數 1676 閱讀 2667

rbac是什麼?

rbac  是基於角色的訪問控制(role-based access control)在rbac  中,許可權與角色相關聯,使用者通過成為適當角色的成員而得到這些角色的許可權。這就極大地簡化了許可權的管理。這樣管理都是層級相互依賴的,許可權賦予給角色,而把角色又賦予使用者,這樣的許可權設計很清楚,管理起來很方便。

rbac  認為授權實際上是whowhathow三元組之間的關係,也就是whowhat進行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,基於角色的訪問控制 就是使用者通過角色與許可權進行關聯。簡單地說,乙個使用者擁有若干角色,每乙個角色擁有若干許可權。這樣,就構造成 使用者 角色 許可權 的授權模型。在這種模型中,使用者與角色之間,角色與許可權之間,一般者是多對多的關係。...