Integrating Data Permissions into RBAC: A Practical Guide

In real‑world projects we need to control not only which resources a user can access but also which part of the data within those resources the user may see.

RBAC Model

RBAC (Role‑Based Access Control) defines roles, each role being a collection of permissions, and assigns users to one or more roles, greatly simplifying permission management.

The classic RBAC0 database design is shown below:

RBAC alone cannot decide whether user A can access data that belongs to user B, a problem known as “horizontal permission management”.

Data Permissions

Data permissions control row‑level access so that different people see different data according to abstracted data rules.

Data Rules

Typical rule dimensions for a sales opportunity system include:

Salesperson can only see their own records.

Regional sales managers can only see opportunities in their region (e.g., Anhui manager sees Anhui data).

Finance staff can only see records with amount less than 10,000.

The essential elements of a data rule are:

Rule field

Rule expression

Rule value

Corresponding examples:

Field: creator, Expression: =, Value: current logged‑in user.

Field: region, Expression: =, Value: Anhui.

Field: amount, Expression: <, Value: 10000.

Rule field configuration description:
Condition expression: >, >=, <, <=, =, contains, fuzzy, !=
Rule value: specified value (fixed value / system context variable)

Associating Resources and Users

Data rules are linked to resources via a simple junction table:

In application design a separate data‑rule management feature is needed so that administrators can create rules and bind them to resources (e.g., a sales opportunity list).

To give different users different data rules, we attach data rules to roles when granting permissions. For example, salespeople, regional managers, and finance staff share the “opportunity list” permission, but each role is bound to its specific data rules. In the Role_Permission table we add a column to store associated rule IDs (multiple IDs can be delimited).

Evolving the RBAC Model

The resulting model is illustrated below:

To avoid role explosion when multiple rule conditions are needed (e.g., region = Anhui AND business unit = Consumer), we introduce the concept of a data‑rule group, where several rules are combined with AND.

The database design for rule groups is shown below:

Conclusion

By designing eight tables we combine RBAC with fine‑grained data permissions. Further improvements include extracting rule fields and values into dictionary tables so that administrators select from predefined options, reducing configuration errors.

Data permissions are complex; this article shows one way to extend RBAC. Feel free to share alternative solutions.