前言

在項目實際開發(fā)中我們不光要控制一個用戶能訪問哪些資源，還需要控制用戶只能訪問資源中的某部分數(shù)據(jù)。

控制一個用戶能訪問哪些資源我們有很成熟的權限管理模型即RBAC，但是控制用戶只能訪問某部分資源（即我們常說的數(shù)據(jù)權限）使用RBAC模型是不夠的，本文我們嘗試在RBAC模型的基礎上融入數(shù)據(jù)權限的管理控制。

首先讓我們先看下RBAC模型。

RBAC模型

RBAC是Role-BasedAccess Control的英文縮寫，意思是基于角色的訪問控制。

RBAC事先會在系統(tǒng)中定義出不同的角色，不同的角色擁有不同的權限，一個角色實際上就是一組權限的集合。而系統(tǒng)的所有用戶都會被分配到不同的角色中，一個用戶可能擁有多個角色。使用RBAC可以極大地簡化權限的管理。

RBAC模型還可以細分為RBAC0，RBAC1，RBAC2，RBAC3。這里我們不討論他們之間的差異，感興趣的同學可以自行研究，我們主要聚焦于常見的RBAC0模型上。

如下圖就是一個經(jīng)典RBAC0模型的數(shù)據(jù)庫設計。

在RBAC模型下，系統(tǒng)只會驗證用戶A是否屬于角色RoleX，而不會判斷用戶A是否能訪問只屬于用戶B的數(shù)據(jù)DataB。這種問題我們稱之為“水平權限管理問題”。

數(shù)據(jù)權限

列表數(shù)據(jù)權限，主要通過數(shù)據(jù)權限控制行數(shù)據(jù)，讓不同的人有不同的查看數(shù)據(jù)規(guī)則；要實現(xiàn)數(shù)據(jù)權限，最重要的是需要抽象出數(shù)據(jù)規(guī)則。

數(shù)據(jù)規(guī)則

比如我們系統(tǒng)的商機數(shù)據(jù)，需要從下面幾個維度來控制數(shù)據(jù)訪問權限。

• 銷售人員只能看自己的數(shù)據(jù)；
• 各大區(qū)的銷售經(jīng)理只能看各區(qū)域的數(shù)據(jù)（安徽大區(qū)的銷售經(jīng)理看安徽區(qū)域的商機數(shù)據(jù)），同理也適用于某BG分管領導只能看所在BG的商機數(shù)據(jù)；
• 財務人員只能看金額小于一萬的數(shù)據(jù)。

上面的這些維度就是數(shù)據(jù)規(guī)則。

這樣數(shù)據(jù)規(guī)則的幾個重點要素我們也明晰了，就是規(guī)則字段，規(guī)則表達式，規(guī)則值，

上面三個場景對應的規(guī)則分別如下：

• 規(guī)則字段：創(chuàng)建人，規(guī)則表達式： = ，規(guī)則值：當前登錄人
• 規(guī)則字段：所屬大區(qū)，規(guī)則表達式： = ，規(guī)則值：安徽大區(qū)
• 規(guī)則字段：銷售金額，規(guī)則表達式： < ，規(guī)則值：10000

規(guī)則字段配置說明： 

條件表達式：大于/大于等于/小于/小于等于/等于/包含/模糊/不等于
規(guī)則值：指定值 ( 固定值/系統(tǒng)上下文變量 )

關聯(lián)資源、用戶

光有數(shù)據(jù)規(guī)則是不夠的，我們還需要把數(shù)據(jù)規(guī)則跟資源和用戶進行綁定。

數(shù)據(jù)規(guī)則與資源的綁定很簡單，我們只需要建立一個中間表即可，如下圖所示：

這樣資源就可以關聯(lián)上了數(shù)據(jù)規(guī)則。

在應用設計上我們需要一個單獨的數(shù)據(jù)規(guī)則管理功能，方便我們錄入數(shù)據(jù)規(guī)則，然后在資源管理頁面（比如商機列表）上就可以選擇內(nèi)置的數(shù)據(jù)規(guī)則進行資源與規(guī)則的綁定。

那么如何讓不同的用戶擁有不同的數(shù)據(jù)規(guī)則呢？

在RBAC模型中，用戶是通過授予不同的角色來進行資源的管理，同理我們可以讓角色在授予權限的時候關聯(lián)上數(shù)據(jù)規(guī)則，這樣最終在系統(tǒng)上就體現(xiàn)為不同的用戶擁有不同的數(shù)據(jù)規(guī)則。

有點拗口，我們還是按上面的例子來說。

銷售人員、大區(qū)銷售經(jīng)理、財務人員屬于不同的角色，他們都擁有商機列表這個資源權限，但是在給這些角色綁定商機列表資源權限時我們可以勾選對應的數(shù)據(jù)規(guī)則（上面已經(jīng)實現(xiàn)資源與數(shù)據(jù)規(guī)則的綁定）。體現(xiàn)在數(shù)據(jù)庫設計中我們可以在角色資源對應關系表 Role_Permission中添加一個字段用于存儲關聯(lián)的數(shù)據(jù)規(guī)則，如果有多個數(shù)據(jù)規(guī)則可以使用分隔符分割。

最終RBAC模型演變成如下所示的模型：

按照上面的設計我們需要區(qū)分各個大區(qū)管理的數(shù)據(jù)權限則需要建立不同的大區(qū)角色，如安徽大區(qū)銷售經(jīng)理、上海大區(qū)銷售經(jīng)理，然后分別給角色勾選對應的數(shù)據(jù)規(guī)則。這里就類似于RBAC1中的角色繼承的概念了。

這樣我們就基本實現(xiàn)了RBAC與數(shù)據(jù)規(guī)則的綁定，但是我們還有個問題就是如何在系統(tǒng)中落地。

這里我們就要借助大名鼎鼎的AOP來實現(xiàn)了，這篇文章只講原理不講實現(xiàn)，所以我們只順帶提一下實現(xiàn)方案。

• 自定義一個數(shù)據(jù)權限的注解，比如叫PermissionData
• 在對應的資源請求方法，比如商機列表上添加自定義注解@PermissionData
• 利用AOP抓取到用戶對應角色的所有數(shù)據(jù)規(guī)則并進行SQL拼接，最終在SQL層面實現(xiàn)數(shù)據(jù)過濾。

繼續(xù)優(yōu)化

在上面的設計中我們通過給不同角色綁定不同數(shù)據(jù)規(guī)則實現(xiàn)了數(shù)據(jù)權限，但是考慮下面一種場景：某角色需要看到的數(shù)據(jù)范圍為 “所屬大區(qū)為安徽大區(qū)且事業(yè)部為消費者事業(yè)部的商機數(shù)據(jù)”，

在這種場景里按照我們之前的設計需要建立兩個數(shù)據(jù)規(guī)則：

• 所屬大區(qū) = 安徽大區(qū)
• 所屬事業(yè)部 = 消費者事業(yè)部

然后再建立2個不同的角色，分別授予不同的數(shù)據(jù)規(guī)則，如果這樣的場景比較多的話很容易出現(xiàn)角色爆炸的情況，所有我們這里再抽取出 數(shù)據(jù)規(guī)則組 的概念。

一個數(shù)據(jù)規(guī)則組有多個數(shù)據(jù)規(guī)則，數(shù)據(jù)規(guī)則之間通過 AND 進行連接，放一張應用設計圖：

體現(xiàn)在數(shù)據(jù)庫設計中就變成了如下所示：

小結

通過上面8張表的設計我們實現(xiàn)了RBAC模型與數(shù)據(jù)權限的結合，當然這里還有繼續(xù)優(yōu)化的空間。比如這里的規(guī)則字段和規(guī)則值我們可以抽取出對應的字典表，讓數(shù)據(jù)規(guī)則表去關聯(lián)這些字典字段，這樣在應用層配置數(shù)據(jù)規(guī)則的時候就不需要管理員手動填寫而是從字典項中去選擇了，減少了數(shù)據(jù)規(guī)則配置出錯的概率。

數(shù)據(jù)權限是一個實現(xiàn)相對比較復雜的功能，這里我們選擇的是在RBAC模型基礎上進行擴展，如果你有更好的解決方案歡迎留言告訴我。

到此這篇關于數(shù)據(jù)設計之權限的實現(xiàn)的文章就介紹到這了,更多相關數(shù)據(jù)權限內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論