How to Build a Flexible Multi‑System Data Permission Framework for Java Backends

Industry Background

In internet systems, permissions are divided into functional permissions and data permissions. Functional permissions are common and supported by many generic frameworks, while data permissions depend heavily on organizational structures and business logic, making them difficult to implement generically.

Typical data‑permission solutions are hard‑coded in two ways: duplicating menus for different data‑permission groups or adding filtering logic in backend APIs. Although easy to implement, these approaches lack flexibility and increase development and maintenance costs when requirements change.

The core problem is how to make data‑permission settings more flexible and less coupled with specific business modules.

Value Proposition

Our company operates multiple business systems with varying user hierarchies and custom data‑permission dimensions. The required capabilities are:

Configurable permissions

Rapid business integration

Unified model across systems

To meet these needs we designed a generic multi‑system data‑permission control system.

System Overview

The system is built on a unified model that allows permission configuration, custom dimension definition, and decoupled user hierarchies, enabling quick data‑permission integration for different systems.

Data Permission Model

We start from the classic RBAC (Role‑Based Access Control) model, where roles aggregate permissions and users can belong to multiple roles. RBAC alone cannot enforce “row‑level” restrictions (e.g., user A should only see data belonging to user B).

To solve this, we extend RBAC with the concepts of function and dimension , allowing role‑based control over specific data dimensions.

For multi‑system applicability we further abstract system , function , and permission as follows:

The model treats each system as a collection of business modules, each module decomposes into functions, and each function contains multiple dimensions. Data permission granularity is at the function level, and each dimension maps to a filtering field for that function’s data.

When all configurations are completed, each role holds multiple data rules under each function.

If fixed values do not satisfy business needs, an open port is provided for the business side to implement custom dimension value providers.

Data Rules

Data rules consist of three elements: dimension , condition expression , and value . For example, in a marketing order list:

Salesperson can only see their own orders → field: creator, expression: =, value: current user.

Department A members can only see data from department A → field: department, expression: =, value: A.

Managers of department A can see data from their own department and sub‑departments → field: department, expression: in, value: A, a.

The overall rule model is illustrated below:

Integration Process

The integration workflow consists of the following steps:

Business identifies the functions that require data‑permission control.

Product, development, and business confirm the dimensions for each function.

Operations configure data‑permission rules (dimensions, expressions, fixed values) in the management console, implementing custom dimension providers if needed.

System administrators log into the permission‑configuration portal and set rules for each role.

When a client accesses a function, the SDK retrieves the user’s roles, assembles the corresponding data rules, and filters the business data accordingly.

Case Study: Order List

We demonstrate the process with an order‑list feature where visibility depends on the employee’s department.

Identify system, function, and dimension: System = XXX, Function = Order List, Dimension = Department.

Configure data‑permission rules in the management console (see screenshot).

Implement a custom SDK port to provide department selection options.

Integrate the SDK into the API layer so that queries automatically include the permission filter.

System administrators assign the appropriate data rules to roles.

With these five steps, the data‑permission feature can be integrated within a day, offering rapid, cost‑effective deployment across all internal systems.

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

How the SDK Enforces Permissions

The SDK intercepts incoming requests, matches them against configured permission APIs using regular expressions, and retrieves the user’s role‑based data rules via a context port.

It then assembles the corresponding SQL or QueryWrapper conditions:

If the business uses MyBatis XML, the SDK injects the permission fragment into the XML query.

If the business uses MyBatis‑Plus QueryWrapper, the SDK adds the conditions to the wrapper automatically.

Developers may also choose to apply the permission rules manually and disable automatic injection.

Current Limitations

Only direct database fields can be controlled; indirect conditions are unsupported.

Automatic injection currently supports only MyBatis XML and MyBatis‑Plus; other ORM frameworks such as JPA are not covered.

Future Considerations

Many similar challenges remain for multi‑system data‑permission control. While each technical problem may be solvable, achieving a truly universal, low‑coupling solution across diverse systems will require ongoing research and development.