我們開(kāi)發(fā)一個(gè)系統(tǒng)，必然面臨權(quán)限控制的問(wèn)題，即不同的用戶(hù)具有不同的訪問(wèn)、操作、數(shù)據(jù)權(quán)限。形成理論的權(quán)限控制模型有：自主訪問(wèn)控制（DAC: Discretionary Access Control）、強(qiáng)制訪問(wèn)控制（MAC: Mandatory Access Control）、基于屬性的權(quán)限驗(yàn)證（ABAC: Attribute-Based Access Control）等。最常被開(kāi)發(fā)者使用也是相對(duì)易用、通用的就是RBAC權(quán)限模型（Role-Based Access Control），本文就將向大家介紹該權(quán)限模型。

一、RBAC權(quán)限模型簡(jiǎn)介

RBAC權(quán)限模型（Role-Based Access Control）即：基于角色的權(quán)限控制。模型中有幾個(gè)關(guān)鍵的術(shù)語(yǔ)：

• 用戶(hù)：系統(tǒng)接口及訪問(wèn)的操作者
• 權(quán)限：能夠訪問(wèn)某接口或者做某操作的授權(quán)資格
• 角色：具有一類(lèi)相同操作權(quán)限的用戶(hù)的總稱(chēng)

RBAC權(quán)限模型核心授權(quán)邏輯如下：

• 某用戶(hù)是什么角色？
• 某角色具有什么權(quán)限？
• 通過(guò)角色的權(quán)限推導(dǎo)用戶(hù)的權(quán)限

二、RBAC的演化進(jìn)程

2.1.用戶(hù)與權(quán)限直接關(guān)聯(lián)

想到權(quán)限控制，人們最先想到的一定是用戶(hù)與權(quán)限直接關(guān)聯(lián)的模式，簡(jiǎn)單地說(shuō)就是：某個(gè)用戶(hù)具有某些權(quán)限。如圖：

• 張三具有創(chuàng)建用戶(hù)和刪除用戶(hù)的權(quán)限，所以他可能系統(tǒng)維護(hù)人員
• 李四具有產(chǎn)品記錄管理和銷(xiāo)售記錄管理權(quán)限，所以他可能是一個(gè)業(yè)務(wù)銷(xiāo)售人員

這種模型能夠清晰的表達(dá)用戶(hù)與權(quán)限之間的關(guān)系，足夠簡(jiǎn)單。但同時(shí)也存在問(wèn)題：

現(xiàn)在用戶(hù)是張三、李四，以后隨著人員增加，每一個(gè)用戶(hù)都需要重新授權(quán)

或者張三、李四離職，需要針對(duì)每一個(gè)用戶(hù)進(jìn)行多種權(quán)限的回收

2.2.一個(gè)用戶(hù)擁有一個(gè)角色

在實(shí)際的團(tuán)體業(yè)務(wù)中，都可以將用戶(hù)分類(lèi)。比如對(duì)于薪水管理系統(tǒng)，通常按照級(jí)別分類(lèi)：經(jīng)理、高級(jí)工程師、中級(jí)工程師、初級(jí)工程師。也就是按照一定的角色分類(lèi)，通常具有同一角色的用戶(hù)具有相同的權(quán)限。這樣改變之后，就可以將針對(duì)用戶(hù)賦權(quán)轉(zhuǎn)換為針對(duì)角色賦權(quán)。

• 一個(gè)用戶(hù)有一個(gè)角色
• 一個(gè)角色有多個(gè)操作（菜單）權(quán)限
• 一個(gè)操作權(quán)限可以屬于多個(gè)角色

我們可以用下圖中的數(shù)據(jù)庫(kù)設(shè)計(jì)模型，描述這樣的關(guān)系。

2.3 一個(gè)用戶(hù)一個(gè)或多個(gè)角色

但是在實(shí)際的應(yīng)用系統(tǒng)中，一個(gè)用戶(hù)一個(gè)角色遠(yuǎn)遠(yuǎn)滿(mǎn)足不了需求。如果我們希望一個(gè)用戶(hù)既擔(dān)任銷(xiāo)售角色、又暫時(shí)擔(dān)任副總角色。該怎么做呢？為了增加系統(tǒng)設(shè)計(jì)的適用性，我們通常設(shè)計(jì)：

• 一個(gè)用戶(hù)有一個(gè)或多個(gè)角色
• 一個(gè)角色包含多個(gè)用戶(hù)
• 一個(gè)角色有多種權(quán)限
• 一個(gè)權(quán)限屬于多個(gè)角色

我們可以用下圖中的數(shù)據(jù)庫(kù)設(shè)計(jì)模型，描述這樣的關(guān)系。

三、頁(yè)面訪問(wèn)權(quán)限與操作權(quán)限

頁(yè)面訪問(wèn)權(quán)限: 所有系統(tǒng)都是由一個(gè)個(gè)的頁(yè)面組成，頁(yè)面再組成模塊，用戶(hù)是否能看到這個(gè)頁(yè)面的菜單、是否能進(jìn)入這個(gè)頁(yè)面就稱(chēng)為頁(yè)面訪問(wèn)權(quán)限。

操作權(quán)限： 用戶(hù)在操作系統(tǒng)中的任何動(dòng)作、交互都需要有操作權(quán)限，如增刪改查等。比如：某個(gè)按鈕，某個(gè)超鏈接用戶(hù)是否可以點(diǎn)擊，是否應(yīng)該看見(jiàn)的權(quán)限。

為了適應(yīng)這種需求，我們可以把頁(yè)面資源(菜單)和操作資源(按鈕)分表存放，如上圖。也可以把二者放到一個(gè)表里面存放，用一個(gè)字段進(jìn)行標(biāo)志區(qū)分。

四、數(shù)據(jù)權(quán)限

數(shù)據(jù)權(quán)限比較好理解，就是某個(gè)用戶(hù)能夠訪問(wèn)和操作哪些數(shù)據(jù)。

通常來(lái)說(shuō)，數(shù)據(jù)權(quán)限由用戶(hù)所屬的組織來(lái)確定。比如：生產(chǎn)一部只能看自己部門(mén)的生產(chǎn)數(shù)據(jù)，生產(chǎn)二部只能看自己部門(mén)的生產(chǎn)數(shù)據(jù)；銷(xiāo)售部門(mén)只能看銷(xiāo)售數(shù)據(jù)，不能看財(cái)務(wù)部門(mén)的數(shù)據(jù)。而公司的總經(jīng)理可以看所有的數(shù)據(jù)。

在實(shí)際的業(yè)務(wù)系統(tǒng)中，數(shù)據(jù)權(quán)限往往更加復(fù)雜。非常有可能銷(xiāo)售部門(mén)可以看生產(chǎn)部門(mén)的數(shù)據(jù)，以確定銷(xiāo)售策略、安排計(jì)劃等。

所以為了面對(duì)復(fù)雜的需求，數(shù)據(jù)權(quán)限的控制通常是由程序員書(shū)寫(xiě)個(gè)性化的SQL來(lái)限制數(shù)據(jù)范圍的，而不是交給權(quán)限模型或者Spring Security或shiro來(lái)控制。當(dāng)然也可以從權(quán)限模型或者權(quán)限框架的角度去解決這個(gè)問(wèn)題，但適用性有限。

以上就是基于角色的權(quán)限控制模型RBAC圖文教程的詳細(xì)內(nèi)容，更多關(guān)于角色的權(quán)限控制模型RBAC的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論