我們開發一個系統，必然面臨權限控制的問題，即不同的用戶具有不同的訪問、操作、數據權限。形成理論的權限控制模型有：自主訪問控制（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來控制。當然也可以從權限模型或者權限框架的角度去解決這個問題，但適用性有限。