Designing Scalable Permission Models: From Basic RBAC to Advanced Role Inheritance

Why Permission Management Is Needed

Developers regularly need permissions such as network access, repository push rights, monitoring platform logins, and data‑query privileges. Missing permissions trigger lengthy approval processes, while strict permission control prevents security incidents.

Example: In a payment company, the operations backend can view all merchant, legal‑representative, transaction, and rate‑configuration data. If every employee could access this data, a marketer could unintentionally modify merchant rates, causing massive losses.

Another example: merchant information is highly confidential. A rogue employee leaking it to a competitor would severely damage the merchant. Even though such breaches stem from individual misconduct, a well‑designed permission system can block many illegal actions by limiting data exposure.

Enabling each role to perform its duties without over‑exposure is the core problem permission management solves.

Permission Model

Permission Design

Permissions are classified by business type (data‑view, data‑modify, etc.) and map to page, menu, and button permissions. Menus often have multiple levels; for example, a CSDN article editor uses a two‑level menu. Designing permissions as a tree makes the request process transparent.

Typical menu‑button hierarchy:

The button’s parent is a second‑level menu, whose parent is a first‑level menu, allowing users to see exactly which permissions they need.

Why Roles Are Needed

When the permission hierarchy is clear, permissions must be assigned to users. With few users, direct assignment works, but each user can have many permissions and each permission can belong to many users, creating a many‑to‑many mapping that becomes costly as the user base grows.

Because many users share the same permission set, a third entity—**role**—is introduced to group those permissions. This is the classic Role‑Based Access Control (RBAC) model.

Evolution of Permission Models

RBAC Model

Roles aggregate permissions, reducing administrative effort. A large enterprise with tens of thousands of employees may need only a few hundred roles.

However, many businesses have hierarchical authority: higher‑level staff need all lower‑level permissions plus extra ones. This leads to the role‑inheritance RBAC model.

Role‑Inheritance RBAC (RBAC1)

In RBAC1, a senior role inherits the permissions of its subordinate role and can also have exclusive permissions. For example, a finance director inherits all permissions of a finance supervisor, who inherits those of a cashier.

Two hierarchy structures are possible:

Tree‑shaped: each lower‑level role has a single parent, while a parent can have many children.

Directed acyclic graph (DAG): a role may have multiple parents and multiple children.

Constrained RBAC (RBAC2)

To enforce business rules, constraints are added. Common constraints include role mutual exclusion, cardinality limits, and prerequisite conditions.

Typical constraints: role mutual exclusion, cardinality, prerequisite.

Role mutual exclusion: If Role A and Role B are mutually exclusive, a user cannot hold both simultaneously. For instance, a user assigned the “Accountant” role must remove it before acquiring the “Auditor” role.

Cardinality constraints: Limit the number of users that can hold a particular role (e.g., only one Super‑Admin) or limit how many roles a user may have.

Prerequisite constraints: To obtain a higher‑level role, a user must already possess the lower‑level role (e.g., a Technical Lead must first have the Developer role).

User Segmentation

User Groups

When many users need the same role, a **user group** can be created. Assign the role to the group, then add users to the group. This avoids assigning the same role individually to hundreds of users (e.g., 500 customer‑service staff).

Difference: a user group is a collection of users; a role is the bridge between users and permissions.

Organization

Permissions can be aligned with the company’s organizational hierarchy. Users in the same department often need the same baseline permissions (e.g., HR sees recruitment data, Marketing sees market‑analysis data). Linking roles to organizations enables automatic permission assignment when a new employee joins or changes department.

Organizations also enforce data‑scope limits: members can only view data belonging to their own organization.

Position

Positions (e.g., Finance Director, Finance Supervisor, Accountant) map one‑to‑one with users, while positions can map many‑to‑many with roles. This allows role assignment based on a fixed job title.

Ideal RBAC Model

Combining RBAC, RBAC1, RBAC2, user groups, organizations, and positions yields a comprehensive model capable of handling large data volumes and complex business rules.

The model is optional for small teams (under ten people); a simple user‑permission table suffices. It becomes valuable as the organization grows and the permission landscape becomes intricate.

Permission System Table Design

Standard RBAC Tables

The standard RBAC schema uses six tables to represent the user‑role‑permission relationships: user, role, permission, plus two junction tables user_role and role_permission.

Ideal RBAC Tables

The ideal model extends the standard schema with additional tables for role constraints, user groups, organizations, positions, and permission groups. The ER diagram includes a role‑mutual‑exclusion table, which can be attached to either roles or permissions depending on business needs.

Conclusion

The permission‑model design progresses from basic RBAC to an ideal, extensible architecture. Choose the model that matches company size, business complexity, and personnel count: simple RBAC suffices for small teams, while larger enterprises benefit from the layered, hierarchical approach described above.