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

Posted on by

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

一、RBAC權限模型簡介

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

  • 用戶：系統接口及訪問的操作者
  • 權限：能夠訪問某接口或者做某操作的授權資格
  • 角色：具有一類相同操作權限的用戶的總稱

RBAC權限模型核心授權邏輯如下：

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

二、RBAC的演化進程

2.1.用戶與權限直接關聯

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

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

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

  • 現在用戶是張三、李四，以後隨着人員增加，每一個用戶都需要重新授權
  • 或者張三、李四離職，需要針對每一個用戶進行多種權限的回收

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

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

  • 一個用戶有一個角色
  • 一個角色有多個操作（菜單）權限
  • 一個操作權限可以屬於多個角色

我們可以用下圖中的數據庫設計模型，描述這樣的關係。

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

但是在實際的應用系統中，一個用戶一個角色遠遠滿足不了需求。如果我們希望一個用戶既擔任銷售角色、又暫時擔任副總角色。該怎麼做呢？為了增加系統設計的適用性，我們通常設計：

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

我們可以用下圖中的數據庫設計模型，描述這樣的關係。

二、頁面訪問權限與操作權限

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

為了適應這種需求，我們可以把頁面資源(菜單)和操作資源(按鈕)分表存放，如上圖。也可以把二者放到一個表裡面存放，用一個字段進行標誌區分。

三、數據權限

數據權限比較好理解，就是某個用戶能夠訪問和操作哪些數據。

  • 通常來說，數據權限由用戶所屬的組織來確定。比如：生產一部只能看自己部門的生產數據，生產二部只能看自己部門的生產數據；銷售部門只能看銷售數據，不能看財務部門的數據。而公司的總經理可以看所有的數據。
  • 在實際的業務系統中，數據權限往往更加複雜。非常有可能銷售部門可以看生產部門的數據，以確定銷售策略、安排計劃等。

所以為了面對複雜的需求，數據權限的控制通常是由程序員書寫個性化的SQL來限制數據範圍的，而不是交給權限模型或者Spring Security或shiro來控制。當然也可以從權限模型或者權限框架的角度去解決這個問題，但適用性有限。

期待您的關注

  • 向您推薦博主的系列文檔：
  • 本文轉載註明出處（必須帶連接，不能只轉文字）：。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!