[[384144]]

本文轉(zhuǎn)載自微信公眾號「JAVA日知錄」，作者單一色調(diào)。轉(zhuǎn)載本文請聯(lián)系JAVA日知錄公眾號。

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

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

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

RBAC模型

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

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

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

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

RBAC0

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

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

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

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

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

1. 銷售人員只能看自己的數(shù)據(jù);
2. 各大區(qū)的銷售經(jīng)理只能看各區(qū)域的數(shù)據(jù)(安徽大區(qū)的銷售經(jīng)理看安徽區(qū)域的商機數(shù)據(jù))，同理也適用于某BG分管領(lǐng)導(dǎo)只能看所在BG的商機數(shù)據(jù);
3. 財務(wù)人員只能看金額小于一萬的數(shù)據(jù)。

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

這樣數(shù)據(jù)規(guī)則的幾個重點要素我們也明晰了，就是規(guī)則字段，規(guī)則表達(dá)式，規(guī)則值，上面三個場景對應(yīng)的規(guī)則分別如下：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

自定義一個數(shù)據(jù)權(quán)限的注解，比如叫PermissionData

在對應(yīng)的資源請求方法，比如商機列表上添加自定義注解@PermissionData

利用AOP抓取到用戶對應(yīng)角色的所有數(shù)據(jù)規(guī)則并進(jìn)行SQL拼接，最終在SQL層面實現(xiàn)數(shù)據(jù)過濾。

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

在上面的設(shè)計中我們通過給不同角色綁定不同數(shù)據(jù)規(guī)則實現(xiàn)了數(shù)據(jù)權(quán)限，但是考慮下面一種場景：某角色需要看到的數(shù)據(jù)范圍為 “所屬大區(qū)為安徽大區(qū)且事業(yè)部為消費者事業(yè)部的商機數(shù)據(jù)”，在這種場景里按照我們之前的設(shè)計需要建立兩個數(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 進(jìn)行連接，放一張應(yīng)用設(shè)計圖：

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

小結(jié)

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

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