Understanding Permission Management and RBAC Models

1. Why Permission Management Is Needed

In daily work, developers constantly request various permissions—network access, code repository, monitoring platform, data analysis, etc. While these requests can be cumbersome, strict permission management is crucial to prevent unauthorized data access, accidental configuration changes, and data leaks, thereby safeguarding company data security.

For example, a payment company's operations backend contains merchant, legal, transaction, and rate configuration data; unrestricted access could allow anyone to modify rates, causing huge losses.

Similarly, exposing confidential merchant information could enable malicious insiders to sell data to competitors. Even though such abuses are individual, a well‑designed permission system can prevent many violations by limiting data exposure.

Overall, permission management ensures that different roles see only the data they need and can perform only the operations appropriate to their responsibilities.

Permission management solves the problem of letting each role perform its duties within the system.

2. Permission Model

2.1 Permission Design

Permissions can be classified by business type (view, edit, etc.) and mapped to system elements such as page, menu, and button permissions. Menus may have multiple levels; designing permissions as a tree structure makes it easy to see required permissions at a glance.

Below is an illustration of a two‑level menu hierarchy where buttons are children of second‑level menus.

With this structure, users can clearly see which menus and buttons they need to request.

2.2 Why Roles Are Needed

After clarifying the permission hierarchy, we must decide how to assign permissions to users. Direct user‑permission assignment works for few users but becomes unmanageable as the user base grows.

The user‑permission many‑to‑many model is shown below:

When many users share the same set of permissions, a role can act as an intermediary, grouping common permissions and linking users to that role—this is the classic RBAC model.

2.3 Evolution of Permission Models

2.3.1 RBAC Model

Roles bridge users and permissions: a permission can belong to multiple roles, a role can have multiple permissions, and a user can be assigned multiple roles.

This many‑to‑many relationship dramatically reduces administrative overhead, especially in large organizations.

However, real‑world businesses often require additional nuances, such as hierarchical privileges where higher‑level positions inherit lower‑level permissions.

That leads to the role‑inheritance RBAC model .

2.3.2 Role‑Inheritance RBAC Model (RBAC1)

In hierarchical organizations, senior roles inherit the permissions of junior roles and may have extra privileges. The diagram below shows that lower‑level role permissions are automatically granted to higher‑level roles.

Two possible structures exist: a tree where each sub‑role has a single parent, or a directed acyclic graph where roles can have multiple parents.

2.3.3 Constrained RBAC Model (RBAC2)

Additional business constraints can be expressed, such as mutually exclusive roles, cardinality limits, and prerequisite conditions.

Common constraints include role mutual exclusion, cardinality constraints, and prerequisite constraints.

Role mutual exclusion: a user cannot hold both Role A and Role B simultaneously.

For instance, a user assigned the “accountant” role cannot also be assigned 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: a user must possess a lower‑level role before being granted a higher‑level role.

2.4 User Segmentation

2.4.1 User Groups

Groups aggregate users with similar responsibilities, allowing a role to be assigned to the entire group, which simplifies bulk permission management.

In short, a user group is a collection of users, while a role is the bridge between users and permissions.

2.4.2 Organizations

Mapping roles to organizational units enables automatic permission assignment when a user joins or moves between departments, and restricts data visibility to the user's organization.

2.4.3 Positions

Positions (e.g., finance director, accountant) have fixed permission requirements; a one‑to‑one relationship links a user to a position, while positions can be linked to multiple roles.

2.5 Ideal RBAC Model

The ideal model combines RBAC, RBAC1, RBAC2, user groups, organizations, and positions to handle large data volumes and complex business scenarios.

This comprehensive model can be adapted to specific business needs, with organization and position relationships being typically one‑to‑many but occasionally many‑to‑many.

3. Permission System Table Design

3.1 Standard RBAC Table Design

The standard RBAC schema consists of six tables: users, roles, permissions, user‑role mapping, role‑permission mapping, and optionally a permission hierarchy. The ER diagram is shown below.

3.2 Ideal RBAC Table Design

The ideal RBAC schema extends the standard model with additional tables for role inheritance, constraints, user groups, organizations, and positions, as illustrated below.

Note that a role‑mutual‑exclusion table can be attached to either roles or permissions depending on business requirements.

4. Conclusion

This article provides a step‑by‑step guide to designing permission models, from simple RBAC to sophisticated, hierarchical structures. For companies with fewer than a thousand employees, a basic RBAC model is usually sufficient; more complex models should be adopted only when data volume and business complexity justify the added overhead.