Extending RBAC with Fine-Grained Data Permissions Using AOP

RBAC Model Overview

Role‑Based Access Control (RBAC) defines roles, each containing a set of permissions, and assigns users to these roles. The classic RBAC0 model simplifies permission management but only determines whether a user can access a resource, not which rows of data the user may see.

Introducing Data Permissions

Data permissions (row‑level security) restrict users to specific subsets of data within a resource. To implement this, we must abstract data rules that describe the conditions under which data is visible.

Data Rule Elements

Rule field (e.g., creator, region, amount)

Rule operator (e.g., =, <, >)

Rule value (e.g., current user, "Anhui" region, 10000)

Examples:

Creator = current logged‑in user

Region = "Anhui"

Sales amount < 10000

Binding Rules to Resources and Users

A middle table links data rules to resources, allowing each resource to be associated with one or more rules. In the UI, administrators can select predefined data rules when configuring resource permissions.

To give different users distinct data rules, we attach rules to roles. When a role is granted a permission, the corresponding data rules are also linked, effectively giving each user the rules of their roles.

Database example: add a data_rule_ids column to the Role_Permission table to store associated rule IDs (multiple IDs can be delimited).

Implementation with AOP

Create a custom annotation, e.g., PermissionData.

Annotate resource‑handling methods (such as the opportunity list API) with @PermissionData.

Use an AOP interceptor to retrieve all data rules for the current user's roles, dynamically compose SQL WHERE clauses, and apply row‑level filtering at the database layer.

Further Optimization: Rule Groups

When a role needs a composite condition (e.g., region = Anhui AND business unit = Consumer), creating separate rules and roles leads to role explosion. To avoid this, introduce rule groups where multiple rules are combined with logical AND.

In the database, a rule group table stores the group ID and references to its constituent rules, while the role‑permission table references the group ID instead of individual rules.

Summary and Next Steps

By extending the RBAC model with data rules and rule groups, we achieve fine‑grained row‑level security while keeping role management manageable. Further improvements include extracting rule fields and values into dictionary tables to reduce manual entry errors.

Implementing the AOP‑based annotation approach provides a clean separation between business logic and security enforcement, making the solution adaptable to various backend frameworks.