大家好：

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

行業背景

在互聯網系統中，權限一般分為功能權限和數據權限，功能權限比較常見，因為通用性和復用性，業內有很多的通用框架和設計。但對應數據權限來說，由于數據權限強依賴客戶組織架構和具體業務的關系，往往實現起來會比較復雜，很少有一個設計架構能完全覆蓋住，所以大部分的系統都一致性的遵循此策略：如非必要的盡量不使用數據權限，必須要的則單獨控制。

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

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

因此，如何提高數據權限設置的靈活性，降低耦合性，是本領域技術人員需要解決的問題。

建設價值

首先來說一下，為什么我們要做這樣一個多系統的數據權限控制裝置？

大背景是我司當前有多個業務系統需要通過數據權限控制業務數據，它們的用戶體系或相同或不同，控制維度各有定制。

于是產生諸如以下需求：

• 權限可配置化
• 支持業務快速接入
• 模型統一

為了支持以上需求，于是理所當然的出現了如下一套多系統的通用數據權限控制系統。

系統介紹

本系統底層使用統一的一套模型，支持權限配置化，業務方可自定義權限維度，用戶體系解耦，滿足不同系統快速接入數據權限的業務場景。

數據權限

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

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

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

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

圖片

同時，為了做到多系統通用，我們又對系統、功能、權限做了如下抽象：

圖片

模型把每個系統抽象成由一個個業務組成，業務下分解成多個功能，功能對應多個維度:

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

數據規則

根據以上描述，顯而易見的，要實現數據權限，最重要的是需要抽象出數據規則。

比如我們營銷系統的訂單列表，需要從下面幾個維度來控制數據訪問權限。

銷售人員只能看自己的數據；

a 部門的人只能看自己部門的數據；

a 部門的上級部門 A 的人能看自己部門的數據和下級 b 部門的人；

上面的這些維度就是數據規則。

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

規則字段：創建人，規則表達式：= ，規則值：當前登錄人

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

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

即數據規則由【維度+條件表達式+維度對應值】組成，業務數據的數據權限就是由多個數據規則組成的范圍控制。具體模型如下：

圖片

接入流程

那么，本套多系統權限控制系統，到底該如何接入呢？大致流程如下：

圖片

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

1.業務確定需要數據權限接入的功能。

2.產品、開發、業務確認功能的維度。

3.運營在開發的支持下在運營管理端配置數據權限，包括支持的維度、表達式、固定值等等。如需自定義維度對應值，實現對應端口。

4.各系統管理員登錄各自的數據權限配置端，設置每個角色的數據規則。

5.客戶訪問系統的具體功能，根據客戶的角色，獲得數據規則，根據數據規則組裝業務數據返回。

接入案例-訂單列表

訂單是很常見的系統功能，當前，需要對不同員工查看訂單的數據范圍做控制，根據員工所屬的部門不同，查看對應部門的訂單列表。

步驟一：確定系統、功能、維度

系統：xxx系統 功能：訂單列表 維度：部門

步驟二：管理端配置數據權限

圖片

步驟三：業務方接入 Sdk，實現自定義維度（部門）選擇項配置端口

示意代碼

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

步驟四: 對應api查詢數據接口接入 Sdk，完成數據過濾

步驟五: 系統管理員配置角色數據權限

只要完成以上5步，就實現了接入數據權限的功能。整個流程只有接入 Sdk 的成本，1天內即可完成，快速、高效，極大的降低了成本。同時公司內所有系統都擁有了一套完整統一的權限控制系統。

Sdk 如何進行數據權限控制

那么，底層究竟是如何實現數據權限控制的？

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

圖片

權限 Sdk 是真正實現權限控制的核心組件。

圖片

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

數據權限生效實現過程如下：

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

2.在功能接口中，Sdk 根據上下文端口獲取當前請求上下文，根據上下文獲取對應用戶所有角色的數據權限。

3.根據數據權限設置的配置，組裝權限控制的條件。

4.業務方查詢時加上權限控制條件，得到的數據，就是控制了數據權限后的數據。

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

如果業務方使用的是 MyBatis 的 Xml 原生語句， Sdk 會把所有的數據權限組裝成對應的 Sql 片段，自動對XML查詢注入該 Sql 片段；如果使用的是 MyBatis-plus 的 QueryWrapper 方式，Sdk 會把所有的數據權限自動注入到生成的 QueryWrapper 條件中。

業務方也可以自主使用權限控制配置查詢數據，關閉 Sdk 的自動注入。

問題

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

思考

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