大家好：

常見的，在項目實際開發(fā)中我們不光要控制一個用戶能訪問哪些資源，還需要控制用戶只能訪問資源中的某部分數(shù)據(jù)。這就是所謂的數(shù)據(jù)權(quán)限。典型的如列表數(shù)據(jù)權(quán)限，主要通過數(shù)據(jù)權(quán)限控制行數(shù)據(jù)，讓不同的人有不同的查看數(shù)據(jù)規(guī)則。

行業(yè)背景

在互聯(lián)網(wǎng)系統(tǒng)中，權(quán)限一般分為功能權(quán)限和數(shù)據(jù)權(quán)限，功能權(quán)限比較常見，因為通用性和復用性，業(yè)內(nèi)有很多的通用框架和設(shè)計。但對應(yīng)數(shù)據(jù)權(quán)限來說，由于數(shù)據(jù)權(quán)限強依賴客戶組織架構(gòu)和具體業(yè)務(wù)的關(guān)系，往往實現(xiàn)起來會比較復雜，很少有一個設(shè)計架構(gòu)能完全覆蓋住，所以大部分的系統(tǒng)都一致性的遵循此策略：如非必要的盡量不使用數(shù)據(jù)權(quán)限，必須要的則單獨控制。

目前常見數(shù)據(jù)權(quán)限方案基本為硬編碼，具體分為如下兩種：一是拆分功能頁面，即根據(jù)不同數(shù)據(jù)權(quán)限用戶，通過復制拷貝的方式，增加多個類似的菜單，再通過功能權(quán)限配置來給不同用戶設(shè)置不同的菜單，從而實現(xiàn)數(shù)據(jù)權(quán)限的控制；二是在功能對應(yīng)的后端接口里做判斷，對不同數(shù)據(jù)權(quán)限的用戶，過濾不同的數(shù)據(jù)列表透出給用戶。硬編碼的方式顯而易見的優(yōu)點是技術(shù)難度低，實現(xiàn)簡單。

但以上硬編碼的方式，無論選擇用哪一種，都無法解決系統(tǒng)靈活性的問題，每當系統(tǒng)有老的需求要變更或者新的需求要新增，對應(yīng)的開發(fā)人員就不得不去調(diào)整編碼，修改菜單和頁面，由此可見，硬編碼對開發(fā)的成本和運維的成本都比較高。與此同時，行業(yè)內(nèi)常見的通用數(shù)據(jù)權(quán)限控制，大都是給單一業(yè)務(wù)使用，和業(yè)務(wù)耦合度較高，可能在當前業(yè)務(wù)客戶端是通用可擴展的，但是在另一個業(yè)務(wù)客戶端就無法做到無縫接入了。

因此，如何提高數(shù)據(jù)權(quán)限設(shè)置的靈活性，降低耦合性，是本領(lǐng)域技術(shù)人員需要解決的問題。

建設(shè)價值

首先來說一下，為什么我們要做這樣一個多系統(tǒng)的數(shù)據(jù)權(quán)限控制裝置？

大背景是我司當前有多個業(yè)務(wù)系統(tǒng)需要通過數(shù)據(jù)權(quán)限控制業(yè)務(wù)數(shù)據(jù)，它們的用戶體系或相同或不同，控制維度各有定制。

于是產(chǎn)生諸如以下需求：

• 權(quán)限可配置化
• 支持業(yè)務(wù)快速接入
• 模型統(tǒng)一

為了支持以上需求，于是理所當然的出現(xiàn)了如下一套多系統(tǒng)的通用數(shù)據(jù)權(quán)限控制系統(tǒng)。

系統(tǒng)介紹

本系統(tǒng)底層使用統(tǒng)一的一套模型，支持權(quán)限配置化，業(yè)務(wù)方可自定義權(quán)限維度，用戶體系解耦，滿足不同系統(tǒng)快速接入數(shù)據(jù)權(quán)限的業(yè)務(wù)場景。

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

RBAC是經(jīng)典的功能權(quán)限模型，它是 Role-BasedAccess Control 的英文縮寫，意思是基于角色的訪問控制。

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

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

所以，為了解決這個問題，我們基于 RBAC 模型下，又擴展了功能和維度的概念，使系統(tǒng)能基于角色控制用戶的數(shù)據(jù)權(quán)限。如下：

同時，為了做到多系統(tǒng)通用，我們又對系統(tǒng)、功能、權(quán)限做了如下抽象：

模型把每個系統(tǒng)抽象成由一個個業(yè)務(wù)組成，業(yè)務(wù)下分解成多個功能，功能對應(yīng)多個維度:

• 數(shù)據(jù)權(quán)限的顆粒度為到功能，一個功能可包含多個 Rest 接口。
• 功能下分多個維度，所謂的數(shù)據(jù)權(quán)限實際就是控制每個維度，維度最終對應(yīng)的是每個功能業(yè)務(wù)數(shù)據(jù)的篩選字段。
• 最終當所有都配置完成后，每個角色對應(yīng)每個功能下就掛著多個數(shù)據(jù)規(guī)則。當用戶訪問具體功能時，根據(jù)用戶角色的數(shù)據(jù)規(guī)則，返回對應(yīng)數(shù)據(jù)。
• 當固定值不滿足業(yè)務(wù)需求時，提供開放端口給業(yè)務(wù)方，業(yè)務(wù)方可實現(xiàn)對應(yīng)維度的選擇項端口，來達到自定義維度對應(yīng)值的目的。

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

根據(jù)以上描述，顯而易見的，要實現(xiàn)數(shù)據(jù)權(quán)限，最重要的是需要抽象出數(shù)據(jù)規(guī)則。

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

銷售人員只能看自己的數(shù)據(jù)；

a 部門的人只能看自己部門的數(shù)據(jù)；

a 部門的上級部門 A 的人能看自己部門的數(shù)據(jù)和下級 b 部門的人；

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

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

規(guī)則字段：創(chuàng)建人，規(guī)則表達式：= ，規(guī)則值：當前登錄人

規(guī)則字段：所屬部門，規(guī)則表達式：= ，規(guī)則值：a

規(guī)則字段：所屬部門，規(guī)則表達式：in ，規(guī)則值：A,a

即數(shù)據(jù)規(guī)則由【維度 條件表達式 維度對應(yīng)值】組成，業(yè)務(wù)數(shù)據(jù)的數(shù)據(jù)權(quán)限就是由多個數(shù)據(jù)規(guī)則組成的范圍控制。具體模型如下：

接入流程

那么，本套多系統(tǒng)權(quán)限控制系統(tǒng)，到底該如何接入呢？大致流程如下：

按照此通用方案，數(shù)據(jù)控制整體接入過程如下：

1.業(yè)務(wù)確定需要數(shù)據(jù)權(quán)限接入的功能。

2.產(chǎn)品、開發(fā)、業(yè)務(wù)確認功能的維度。

3.運營在開發(fā)的支持下在運營管理端配置數(shù)據(jù)權(quán)限，包括支持的維度、表達式、固定值等等。如需自定義維度對應(yīng)值，實現(xiàn)對應(yīng)端口。

4.各系統(tǒng)管理員登錄各自的數(shù)據(jù)權(quán)限配置端，設(shè)置每個角色的數(shù)據(jù)規(guī)則。

5.客戶訪問系統(tǒng)的具體功能，根據(jù)客戶的角色，獲得數(shù)據(jù)規(guī)則，根據(jù)數(shù)據(jù)規(guī)則組裝業(yè)務(wù)數(shù)據(jù)返回。

接入案例-訂單列表

訂單是很常見的系統(tǒng)功能，當前，需要對不同員工查看訂單的數(shù)據(jù)范圍做控制，根據(jù)員工所屬的部門不同，查看對應(yīng)部門的訂單列表。

步驟一：確定系統(tǒng)、功能、維度

系統(tǒng)：xxx系統(tǒng) 功能：訂單列表 維度：部門

步驟二：管理端配置數(shù)據(jù)權(quán)限

步驟三：業(yè)務(wù)方接入 Sdk，實現(xiàn)自定義維度（部門）選擇項配置端口

示意代碼

/** * 獲取維度選擇項 */List<DimensionOption> getDimensionOptionList(List<String> dimensionCodes);

步驟四: 對應(yīng)api查詢數(shù)據(jù)接口接入 Sdk，完成數(shù)據(jù)過濾

步驟五: 系統(tǒng)管理員配置角色數(shù)據(jù)權(quán)限

只要完成以上5步，就實現(xiàn)了接入數(shù)據(jù)權(quán)限的功能。整個流程只有接入 Sdk 的成本，1天內(nèi)即可完成，快速、高效，極大的降低了成本。同時公司內(nèi)所有系統(tǒng)都擁有了一套完整統(tǒng)一的權(quán)限控制系統(tǒng)。

Sdk 如何進行數(shù)據(jù)權(quán)限控制

那么，底層究竟是如何實現(xiàn)數(shù)據(jù)權(quán)限控制的？

以下是一個請求的控制鏈路：

權(quán)限 Sdk 是真正實現(xiàn)權(quán)限控制的核心組件。

Sdk 中的基石是一個個對外開放的端口，其中最底層的是上下文端口。接入方需實現(xiàn)這個端口接口，根據(jù)當前緩存用戶封裝數(shù)據(jù)權(quán)限上下文。如有自定義維度，需實現(xiàn)自定義維度選擇項端口，返回業(yè)務(wù)自定義的維度選擇項。

數(shù)據(jù)權(quán)限生效實現(xiàn)過程如下：

1.請求 Path 被 Sdk 攔截，通過正則匹配配置的權(quán)限 Api，匹配到說明需要被控制。

2.在功能接口中，Sdk 根據(jù)上下文端口獲取當前請求上下文，根據(jù)上下文獲取對應(yīng)用戶所有角色的數(shù)據(jù)權(quán)限。

3.根據(jù)數(shù)據(jù)權(quán)限設(shè)置的配置，組裝權(quán)限控制的條件。

4.業(yè)務(wù)方查詢時加上權(quán)限控制條件，得到的數(shù)據(jù)，就是控制了數(shù)據(jù)權(quán)限后的數(shù)據(jù)。

ps:本sdk只針對java語言的后端

如果業(yè)務(wù)方使用的是 MyBatis 的 Xml 原生語句， Sdk 會把所有的數(shù)據(jù)權(quán)限組裝成對應(yīng)的 Sql 片段，自動對XML查詢注入該 Sql 片段；如果使用的是 MyBatis-plus 的 QueryWrapper 方式，Sdk 會把所有的數(shù)據(jù)權(quán)限自動注入到生成的 QueryWrapper 條件中。

業(yè)務(wù)方也可以自主使用權(quán)限控制配置查詢數(shù)據(jù)，關(guān)閉 Sdk 的自動注入。

問題

• 當前只能直接對數(shù)據(jù)庫存在的字段進行控制，如果是間接條件，無法控制數(shù)據(jù)權(quán)限
• 自動注入當前只支持 MyBatis 的 Xml 原生語句和 MyBatis-plus 的 QueryWrapper 方式,其他如 Jpa 等不支持

思考

還有更多的類似問題，都是多系統(tǒng)數(shù)據(jù)權(quán)限控制需要解決的。雖然具體到每個小點，單從技術(shù)的角度來說，可能未必很難，但要支持更多系統(tǒng)，具備更好的通用化，還有很長的一段路可走。這是一個會隨著業(yè)務(wù)的發(fā)展，需要持續(xù)改進的工作。

作者:小中

來源:微信公眾號:政采云技術(shù)

出處:https://mp.weixin.qq.com/s/O2THu2T-DsvKb2Nd69g5Rw