Design and Implementation of a Multi‑System Data Permission Control System

In modern internet applications, controlling not only which resources a user can access but also which parts of the data within those resources is essential; this is referred to as data permission, typically implemented as row‑level access control.

Industry background: Permission is usually divided into functional permission and data permission. Functional permission is widely supported by generic frameworks, while data permission is tightly coupled with organizational structures and business logic, making hard‑coded solutions common but inflexible.

Hard‑coded approaches—either duplicating menus for different data‑permission groups or filtering data in backend APIs—are easy to implement but lead to high development and maintenance costs and poor reusability across business domains.

Value proposition: To improve flexibility and reduce coupling, a configurable multi‑system data‑permission control device is proposed, supporting permission configurability, rapid business integration, and unified modeling.

System overview: The system uses a unified model that abstracts systems into business modules, each containing functions and dimensions. Permissions are defined per role, per function, and per dimension, allowing fine‑grained data filtering.

Data permission model: Based on the classic RBAC (Role‑Based Access Control) model, the system extends it with the concepts of function and dimension, enabling role‑based data filtering (horizontal permission management).

The model abstracts each system as a collection of business units, each business unit into multiple functions, and each function into multiple dimensions. Data permission granularity is at the function level, with each function potentially exposing several REST endpoints.

Data rules consist of a dimension, an expression, and a value (e.g., creator = current_user , department = 'A' , department IN ('A','a') ), and multiple rules together define the accessible data range.

Integration process: The typical integration steps are:

Identify the system, function, and dimensions that require data permission.

Confirm dimensions with product, development, and business stakeholders.

Configure data permission (dimensions, expressions, fixed values) in the operation management console, implementing custom dimension ports if needed.

System administrators set data rules for each role via the permission configuration UI.

When a user accesses a function, the system retrieves the role’s data rules and applies them to the business query.

Case study – Order list: For an order‑listing feature, the dimension is "department". After configuring the rule (e.g., department = user's department), the SDK provides a method to fetch dimension options:

/**
 * Get dimension selection options
 */
List<DimensionOption> getDimensionOptionList(List<String> dimensionCodes);

The SDK intercepts API requests, matches them against configured permission APIs, obtains the current user’s context, assembles the permission conditions, and injects them into MyBatis XML or MyBatis‑Plus QueryWrapper queries.

Technical notes: The SDK currently supports Java back‑ends, MyBatis XML, and MyBatis‑Plus. It cannot control indirect conditions or frameworks such as JPA.

Overall, the framework provides a unified, extensible way to manage data permissions across multiple systems, reducing coupling and development overhead while ensuring secure, fine‑grained access control.