來源 ：https://blog.csdn.net/rocher88/article/details/43190743

這是我在網上找的一些設計比較好的RBAC權限管理

不知道，像新浪、搜狐、網易、百度、阿里巴巴、淘寶網的RBAC用戶權限這一塊，都是這種細顆粒的RBAC設計開發，還是把他們像用戶組、角色組、權限組、操作組、資源組的表盒數據等都封裝成工具類，持久化曾通過一個數據庫視圖View或者聯合查詢，將細顆粒的設計轉化成粗顆粒的操作。開發人員不需要關注這些比較細的東西，只需要關注粗顆粒，比如說：用戶和角色以及菜單和操作就可以了。其他的什么按鈕的曾、刪、改、差、分頁、文件是否能上傳的權限操作，都陪封裝的這些操作的實體工具類里面了！！！

RBAC權限管理?
?
擴展accessmenufile

?
RBAC（Role-Based?Access?Control，基于角色的訪問控制），就是用戶通過角色與權限進行關聯。簡單地說，一個用戶擁有若干角色，每一個角色擁有若干權限。這樣，就構造成“用戶-角色-權限”的授權模型。在這種模型中，用戶與角色之間，角色與權限之間，一般者是多對多的關系。（如下圖）
?


角色是什么？可以理解為一定數量的權限的集合，權限的載體。例如：一個論壇系統，“超級管理員”、“版主”都是角色。版主可管理版內的帖子、可管理版內的用戶等，這些是權限。要給某個用戶授予這些權限，不需要直接將權限授予用戶，可將“版主”這個角色賦予該用戶。?
?
當用戶的數量非常大時，要給系統每個用戶逐一授權（授角色），是件非常煩瑣的事情。這時，就需要給用戶分組，每個用戶組內有多個用戶。除了可給用戶授權外，還可以給用戶組授權。這樣一來，用戶擁有的所有權限，就是用戶個人擁有的權限與該用戶所在用戶組擁有的權限之和。（下圖為用戶組、用戶與角色三者的關聯關系）
?


在應用系統中，權限表現成什么？對功能模塊的操作，對上傳文件的刪改，菜單的訪問，甚至頁面上某個按鈕、某個圖片的可見性控制，都可屬于權限的范疇。有些權限設計，會把功能操作作為一類，而把文件、菜單、頁面元素等作為另一類，這樣構成“用戶-角色-權限-資源”的授權模型。而在做數據表建模時，可把功能操作和資源統一管理，也就是都直接與權限表進行關聯，這樣可能更具便捷性和易擴展性。（見下圖）
?


請留意權限表中有一列“權限類型”，我們根據它的取值來區分是哪一類權限，如“MENU”表示菜單的訪問權限、“OPERATION”表示功能模塊的操作權限、“FILE”表示文件的修改權限、“ELEMENT”表示頁面元素的可見性控制等。

這樣設計的好處有二。其一，不需要區分哪些是權限操作，哪些是資源，（實際上，有時候也不好區分，如菜單，把它理解為資源呢還是功能模塊權限呢？）。其二，方便擴展，當系統要對新的東西進行權限控制時，我只需要建立一個新的關聯表“權限XX關聯表”，并確定這類權限的權限類型字符串。

這里要注意的是，權限表與權限菜單關聯表、權限菜單關聯表與菜單表都是一對一的關系。（文件、頁面權限點、功能操作等同理）。也就是每添加一個菜單，就得同時往這三個表中各插入一條記錄。這樣，可以不需要權限菜單關聯表，讓權限表與菜單表直接關聯，此時，須在權限表中新增一列用來保存菜單的ID，權限表通過“權限類型”和這個ID來區分是種類型下的哪條記錄。

到這里，RBAC權限模型的擴展模型的完整設計圖如下：
?

隨著系統的日益龐大，為了方便管理，可引入角色組對角色進行分類管理，跟用戶組不同，角色組不參與授權。例如：某電網系統的權限管理模塊中，角色就是掛在區局下，而區局在這里可當作角色組，它不參于權限分配。另外，為方便上面各主表自身的管理與查找，可采用樹型結構，如菜單樹、功能樹等，當然這些可不需要參于權限分配。

?

另外一個不同的RBAC用戶權限管理的設計：


基于RBAC的權限設計模型?

權限分析文檔?

基于RBAC的權限設計模型：?

1????????RBAC?介紹?

RBAC?模型作為目前最為廣泛接受的權限模型。?

NIST?（The?National?Institute?of?Standards?and?Technology，美國國家標準與技術研究院）標準RBAC模型由4個部件模型組成，這4個部件模型分別是基本模型RBAC0（Core?RBAC）、角色分級模型RBAC1（Hierarchal?RBAC）、角色限制模型RBAC2（Constraint?RBAC）和統一模型RBAC3（Combines?RBAC）[1]。RBAC0模型如圖1所示。?



圖表?1?RBAC?0?模型?

?????????RBAC0?定義了能構成一個RBAC控制系統的最小的元素集合?

在RBAC之中,包含用戶users(USERS)、角色roles(ROLES)、目標objects(OBS)、操作operations(OPS)、許可權permissions(PRMS)五個基本數據元素，權限被賦予角色,而不是用戶，當一個角色被指定給一個用戶時，此用戶就擁有了該角色所包含的權限。會話sessions是用戶與激活的角色集合之間的映射。RBAC0與傳統訪問控制的差別在于增加一層間接性帶來了靈活性，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的擴展。?

??????????RBAC1?引入角色間的繼承關系?

角色間的繼承關系可分為一般繼承關系和受限繼承關系。一般繼承關系僅要求角色繼承關系是一個絕對偏序關系，允許角色間的多繼承。而受限繼承關系則進一步要求角色繼承關系是一個樹結構。?

??????????RBAC2?模型中添加了責任分離關系?

RBAC2?的約束規定了權限被賦予角色時,或角色被賦予用戶時,以及當用戶在某一時刻激活一個角色時所應遵循的強制性規則。責任分離包括靜態責任分離和動態責任分離。約束與用戶-角色-權限關系一起決定了RBAC2模型中用戶的訪問許可。?

??????????RBAC3?包含了RBAC1和RBAC2?

既提供了角色間的繼承關系，又提供了責任分離關系。?

建立角色定義表。定出當前系統中角色。?

因為有繼承的問題，所以角色體現出的是一個樹形結構。?



2????????權限設計：?
?
配置資源以及資源的操作?：?這里資源可以定義為一個通用的資源模型。提供通用的資源統一接口。?
?
數據庫?ER?圖：?



關系圖：?


?


3????????分析：?

根據以上的類關系圖和ER圖可以看出。整個權限可以抽象為五個對象組成。?

OrgBean?:?用于描述org模型。?

Role?：?用于描述角色。?

Permission?：?用于描述權限。?

Resource?：?用于描述資源。?

Operation?：?用于描述操作。?

其中Permission中有Resource?,?Operation?的聚合，資源和操作組成權限。?

Role?和?Permission?都有自包含。因為設計到權限的繼承。?

資源Resource?也可能出現一顆樹形結構，那資源也要有自包含。?

思想?:?

權限系統的核心由以下三部分構成：?1.?創造權限，?2.?分配權限，?3.?使用權限，然后，系統各部分的主要參與者對照如下：?1.?創造權限?-?Creator?創造，?2.?分配權限?-?Administrator?分配，?3.?使用權限?-?User?：?

1.?Creator?創造?Privilege?，?Creator?在設計和實現系統時會劃分，一個子系統或稱為模塊，應該有哪些權限。這里完成的是?Privilege?與?Resource?的對象聲明，并沒有真正將?Privilege?與具體?Resource?實例聯系在一起，形成?Operator?。?

2.?Administrator?指定?Privilege?與?Resource?Instance?的關聯?。在這一步，?權限真正與資源實例聯系到了一起，?產生了?Operator?（?Privilege?Instance?）。?Administrator?利用?Operator?這個基本元素，來創造他理想中的權限模型。如，創建角色，創建用戶組，給用戶組分配用戶，將用戶組與角色關聯等等?...?這些操作都是由?Administrator?來完成的。?

3.?User?使用?Administrator?分配給的權限去使用各個子系統。?Administrator?是用戶，在他的心目中有一個比較適合他管理和維護的權限模型。于是，程序員只要回答一個問題，就是什么權限可以訪問什么資源，也就是前面說的?Operator?。程序員提供?Operator?就意味著給系統穿上了盔甲。?Administrator?就可以按照他的意愿來建立他所希望的權限框架?可以自行增加，刪除，管理?Resource?和?Privilege?之間關系。可以自行設定用戶?User?和角色?Role?的對應關系。?(?如果將?Creator?看作是?Basic?的發明者，?Administrator?就是?Basic?的使用者，他可以做一些腳本式的編程?)?Operator?是這個系統中最關鍵的部分，它是一個紐帶，一個系在?Programmer?，?Administrator?，?User?之間的紐帶。?

4????????權限API?

???getPermissionByOrgGuid(String?orgGuid?)?

??????通過傳入一個org的Guid?，?拿到當前這個org對象都具有那些訪問權限。?

?getSourcePermissionByOrgGuid(String?orgGuid?,?String?resouceGuid)?

????通過傳入一個org的Guid?和?一個資源的Guid?，?返回改Org對當前這個資源的訪問權限。?

getPermissionByResourceGuid(String?resource)?

????通過傳入一個資源的Guid?，?得到當前資源下都有那些權限定義。?

havingHeritPermission(String?orgGuid?,?String?resouceGuid)?:?Boolean?

????傳入一個orgGuid，?資源GUID?，查看改OrgGuid下對資源是否有向下繼承的權限。這里繼承是資源的繼承。即對父欄目有權限，可以繼承下去對父欄目下的子欄目同樣有權限。?

havingPermission(String?orgGuid?,?String?resourceGuid)?:?Boolean?

????判斷某Org對某一資源是否用權限。?

以上是粗粒度的權限API?。?以下為細粒度的權限：?

getOperationByPermission(String?permissionGuid)?

????通過permission?的Guid?得到該permission?的所有有效操作。?

getOperationByGuid(String?permissionGuid?,?String?resourceGuid)?

????通過permision的Guid?，?資源的Guid?得到該資源下所有的有效操作。?

screeningOpreationByGuid?(String?permissionGuid?,?String?resourceGuid?,?String?orgGuid)?

????通過permission?，?resource?，?org的Guid?得到改Org對這一資源的有效操作。?

hasOperation(String?operationGuid)?:?boolean?

????通過傳入的operationGuid?返回是否具有操作權限。?

5????????權限的實現：?

1?．表單式認證，這是常用的，但用戶到達一個不被授權訪問的資源時，?Web?容器就發?

出一個?html?頁面，要求輸入用戶名和密碼。?

2?．用?Filter?防止用戶訪問一些未被授權的資源，?Filter?會截取所有?Request/Response?，?

然后放置一個驗證通過的標識在用戶的?Session?中，然后?Filter?每次依靠這個標識來決定是否放行?Response?。?

這個模式分為：?

Gatekeeper?：采取?Filter?或統一?Servlet?的方式。?

Authenticator?：?在?Web?中使用?JAAS?自己來實現。?

Filter?攔截只是攔截該用戶是否有訪問這個頁面，或這一資源的權限。真正做到顯示后攔截是在應用程序內部去做。?

做顯示攔截提供API?，?標簽這兩種方式。

轉載于:https://www.cnblogs.com/hao-1234-1234/p/8976360.html

總結

以上是生活随笔為你收集整理的RBAC 权限设计（转载）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。