圖文詳解基於角色的權限控制模型RBAC

咱們開發一個系統，必然面臨權限控制的問題，即不一樣的用戶具備不一樣的訪問、操做、數據權限。造成理論的權限控制模型有：自主訪問控制（DAC: Discretionary Access Control）、強制訪問控制（MAC: Mandatory Access Control）、基於屬性的權限驗證（ABAC: Attribute-Based Access Control）等。最常被開發者使用也是相對易用、通用的就是RBAC權限模型（Role-Based Access Control），本文就將向你們介紹該權限模型。

1、RBAC權限模型簡介

RBAC權限模型（Role-Based Access Control）即：基於角色的權限控制。模型中有幾個關鍵的術語：

• 用戶：系統接口及訪問的操做者
• 權限：可以訪問某接口或者作某操做的受權資格
• 角色：具備一類相同操做權限的用戶的總稱

RBAC權限模型核心受權邏輯以下：

• 某用戶是什麼角色？
• 某角色具備什麼權限？
• 經過角色的權限推導用戶的權限

2、RBAC的演化進程

2.1.用戶與權限直接關聯

想到權限控制，人們最早想到的必定是用戶與權限直接關聯的模式，簡單地說就是：某個用戶具備某些權限。如圖：

• 張三具備建立用戶和刪除用戶的權限，因此他可能系統維護人員
• 李四具備產品記錄管理和銷售記錄管理權限，因此他多是一個業務銷售人員

這種模型可以清晰的表達用戶與權限之間的關係，足夠簡單。但同時也存在問題：

• 如今用戶是張3、李四，之後隨着人員增長，每個用戶都須要從新受權
• 或者張3、李四離職，須要針對每個用戶進行多種權限的回收

2.2.一個用戶擁有一個角色

在實際的團體業務中，均可以將用戶分類。好比對於薪水管理系統，一般按照級別分類：經理、高級工程師、中級工程師、初級工程師。也就是按照必定的角色分類，一般具備同一角色的用戶具備相同的權限。這樣改變以後，就能夠將針對用戶賦權轉換爲針對角色賦權。

• 一個用戶有一個角色
• 一個角色有多個操做（菜單）權限
• 一個操做權限能夠屬於多個角色

咱們能夠用下圖中的數據庫設計模型，描述這樣的關係。

2.3 一個用戶一個或多個角色

可是在實際的應用系統中，一個用戶一個角色遠遠知足不了需求。若是咱們但願一個用戶既擔任銷售角色、又暫時擔任副總角色。該怎麼作呢？爲了增長系統設計的適用性，咱們一般設計：

• 一個用戶有一個或多個角色
• 一個角色包含多個用戶
• 一個角色有多種權限
• 一個權限屬於多個角色

咱們能夠用下圖中的數據庫設計模型，描述這樣的關係。

2、頁面訪問權限與操做權限

• 頁面訪問權限: 全部系統都是由一個個的頁面組成，頁面再組成模塊，用戶是否能看到這個頁面的菜單、是否能進入這個頁面就稱爲頁面訪問權限。
• 操做權限： 用戶在操做系統中的任何動做、交互都須要有操做權限，如增刪改查等。好比：某個按鈕，某個超連接用戶是否能夠點擊，是否應該看見的權限。

爲了適應這種需求，咱們能夠把頁面資源(菜單)和操做資源(按鈕)分表存放，如上圖。也能夠把兩者放到一個表裏面存放，用一個字段進行標誌區分。

3、數據權限

數據權限比較好理解，就是某個用戶可以訪問和操做哪些數據。

• 一般來講，數據權限由用戶所屬的組織來肯定。好比：生產一部只能看本身部門的生產數據，生產二部只能看本身部門的生產數據；銷售部門只能看銷售數據，不能看財務部門的數據。而公司的總經理能夠看全部的數據。
• 在實際的業務系統中，數據權限每每更加複雜。很是有可能銷售部門能夠看生產部門的數據，以肯定銷售策略、安排計劃等。

因此爲了面對複雜的需求，數據權限的控制一般是由程序員書寫個性化的SQL來限制數據範圍的，而不是交給權限模型或者Spring Security或shiro來控制。固然也能夠從權限模型或者權限框架的角度去解決這個問題，但適用性有限。

期待您的關注

• 向您推薦博主的系列文檔：《手摸手教您學習SpringBoot系列-16章97節》
• 本文轉載註明出處（必須帶鏈接，不能只轉文字）：字母哥博客。