Why This Permission System Is So Elegant: A Comprehensive Guide to RBAC Design

Why Permission Management Is Needed

New employees frequently request access to networks, code repositories, monitoring platforms, and data dashboards. Ad‑hoc approvals are slow and can expose sensitive data. An example from a payment‑company backend shows that unrestricted access to merchant, legal‑representative, transaction, and rate‑configuration data would allow any employee to modify fees, potentially causing large losses. Leaking confidential merchant data to competitors also poses severe risks. Permission management aims to let each role perform its duties without over‑exposure.

Permission Model Design

Permission Design

Permissions are classified by business function (e.g., view, edit) and mapped to page, menu, and button rights. Menus are hierarchical (level‑1, level‑2, level‑3). Designing permissions as a tree makes the required menu or button obvious during access requests.

Example diagram (two‑level menu similar to a CSDN article editor) shows buttons under each submenu.

In this hierarchy, a button’s parent is a level‑2 menu, whose parent is a level‑1 menu, providing a clear view of required permissions.

Why Roles Are Needed

When the user base is small, permissions can be assigned directly to users. As the number of users grows, the user‑permission matrix becomes unmanageable: each user must be assigned multiple permissions, and each permission may be shared by many users, leading to high administrative overhead.

Introducing a third entity—role—allows grouping common permissions and assigning the role to users, dramatically reducing effort.

Evolution of Permission Models

Classic RBAC

Roles act as a bridge between users and permissions. A permission can belong to multiple roles, a role can have multiple permissions, and a user can have multiple roles. This many‑to‑many user‑role‑permission diagram scales: a few hundred roles can cover tens of thousands of users because many users share the same permissions.

Role‑Inheritance RBAC (RBAC1)

Roles can inherit permissions from lower‑level roles. For example, a finance supervisor inherits all permissions of a cashier, and a finance director inherits those of the supervisor plus additional rights. Two inheritance structures are illustrated:

Tree‑shaped hierarchy where each lower‑level role has a single parent.

Directed acyclic graph (DAG) where a role may have multiple parents.

Constrained RBAC (RBAC2)

Real‑world security policies impose constraints on role assignment:

Role mutual exclusion : Roles A and B cannot be assigned to the same user simultaneously.

Cardinality constraint : Limit the number of users that can hold a particular role (e.g., only one super‑admin) or limit the number of roles per user.

Prerequisite constraint : To obtain a higher‑level role, a user must first hold the lower‑level role.

User Grouping Strategies

User Groups

When many users need the same role, creating a user group (e.g., all customer‑service staff) and assigning the role to the group reduces repetitive work. A user group is a collection of users; a role remains the bridge between users and permissions.

Organization‑Based Assignment

Permissions can be aligned with the company’s organizational hierarchy. When a new employee joins an organizational unit, they automatically inherit the unit’s roles, eliminating manual assignment. Tying roles to organizations also enables data‑level isolation so members only see data belonging to their own unit.

Position‑Based Assignment

Within an organization, positions (e.g., finance director, accountant) have distinct permission needs. Positions are usually one‑to‑one with users, while a position can map to multiple roles.

Permission System Table Design

Standard RBAC Tables

The minimal schema includes six tables: user, role, permission, plus two junction tables user_role and role_permission to represent the many‑to‑many relationships.

Ideal RBAC Tables

When business complexity grows, the schema expands to include role inheritance, constraints, user groups, organizations, and positions. Additional tables capture role hierarchy, mutual‑exclusion constraints, and group‑role mappings.

Conclusion

Permission models should be chosen based on company size, business complexity, and user count. For teams under a thousand users, classic RBAC is sufficient; larger organizations benefit from role inheritance, constraints, user groups, organization‑based and position‑based assignments. The model should serve the problem, avoiding unnecessary over‑engineering.