基于角色的權限控制模型RBAC實例分析

本篇內容主要講解“基于角色的權限控制模型RBAC實例分析”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“基于角色的權限控制模型RBAC實例分析”吧!

一、RBAC權限模型簡介

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

• 用戶：系統接口及訪問的操作者

• 權限：能夠訪問某接口或者做某操作的授權資格

• 角色：具有一類相同操作權限的用戶的總稱

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

• 某用戶是什么角色？

• 某角色具有什么權限？

• 通過角色的權限推導用戶的權限

二、RBAC的演化進程

2.1.用戶與權限直接關聯

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

• 張三具有創建用戶和刪除用戶的權限，所以他可能系統維護人員

• 李四具有產品記錄管理和銷售記錄管理權限，所以他可能是一個業務銷售人員

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

現在用戶是張三、李四，以后隨著人員增加，每一個用戶都需要重新授權

或者張三、李四離職，需要針對每一個用戶進行多種權限的回收

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

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

• 一個用戶有一個角色

• 一個角色有多個操作（菜單）權限

• 一個操作權限可以屬于多個角色

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

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

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

• 一個用戶有一個或多個角色

• 一個角色包含多個用戶

• 一個角色有多種權限

• 一個權限屬于多個角色

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

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

頁面訪問權限: 所有系統都是由一個個的頁面組成，頁面再組成模塊，用戶是否能看到這個頁面的菜單、是否能進入這個頁面就稱為頁面訪問權限。

操作權限： 用戶在操作系統中的任何動作、交互都需要有操作權限，如增刪改查等。比如：某個按鈕，某個超鏈接用戶是否可以點擊，是否應該看見的權限。

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

四、數據權限

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

通常來說，數據權限由用戶所屬的組織來確定。比如：生產一部只能看自己部門的生產數據，生產二部只能看自己部門的生產數據；銷售部門只能看銷售數據，不能看財務部門的數據。而公司的總經理可以看所有的數據。

在實際的業務系統中，數據權限往往更加復雜。非常有可能銷售部門可以看生產部門的數據，以確定銷售策略、安排計劃等。

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

到此，相信大家對“基于角色的權限控制模型RBAC實例分析”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！