Comprehensive RBAC Permission System Design: Models, Constraints, and Database Schemas

Why Permission Management Is Needed

New employees must request many permissions (network access, code repository, monitoring dashboards, data queries, etc.). The process can delay urgent work. Strict permission control protects sensitive data such as merchant information, transaction details, and fee configurations, preventing accidental changes or leakage.

Permission management ensures that each role sees only the data it should and can perform only the operations it is authorized for.

Permission Model

Permission Design

Permissions are classified by business function (view, modify) and mapped to UI elements: page, menu, button. Menus are hierarchical (e.g., a two‑level menu in a CSDN article editor). Designing permissions as a tree makes the request process clear because the parent of a button is a second‑level menu, whose parent is a first‑level menu.

Why Roles Are Needed

Direct user‑permission assignment works for a few users but becomes unmanageable as the user base grows. Introducing a mediating entity—roles—allows many users to share the same set of permissions.

Evolution of Permission Models

Classic RBAC

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

Role‑Inheritance RBAC (RBAC1)

Higher‑level roles inherit all permissions of lower‑level roles and may have additional permissions (e.g., a finance director inherits a finance supervisor’s rights). The inheritance hierarchy can be a tree (single parent) or a directed acyclic graph (multiple parents).

Constrained RBAC (RBAC2)

Additional constraints improve security, such as role mutual exclusion, cardinality limits, and prerequisite conditions.

Common constraints: role mutual exclusion, cardinality limits, prerequisite conditions.

Role Mutual Exclusion: A user cannot simultaneously hold two mutually exclusive roles (e.g., accountant vs. auditor).

Cardinality Constraint: Limit the number of users assigned to a role (e.g., only one super‑admin) or 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

User Groups

When many users share the same role, a user group can be created; assigning the role to the group automatically grants it to all members, reducing manual effort.

Groups differ from roles: groups are collections of users, while roles link users to permissions.

Organizations

Mapping roles to organizational units enables automatic permission assignment when a user joins or moves between units. Organizations also restrict data visibility to the belonging unit.

Positions

Positions (e.g., finance director, supervisor) have fixed mappings to roles; a user’s position determines the roles they receive.

Ideal RBAC Model

The ideal model combines standard RBAC, role inheritance, constraints, user groups, organizations, and positions to handle large data volumes and complex business scenarios. It is suitable for companies with thousands of users; smaller teams may stick with a simple user‑permission model.

Permission System Table Design

Standard RBAC Tables

To represent the 用户-角色-权限 relationships, create six tables: user, role, permission, user‑role, role‑permission, and a linking table for many‑to‑many associations.

Ideal RBAC Tables

The expanded model adds tables for role mutual exclusion, constraints, user groups, organizations, and positions, resulting in a more complex ER diagram.

Role‑mutual‑exclusion can be stored either on the role side or the permission side, depending on requirements.

Conclusion

The article provides a step‑by‑step guide from basic to advanced RBAC designs, emphasizing that the choice of model should match company size, business complexity, and personnel count. For organizations with fewer than ten people, a simple user‑permission approach suffices; larger enterprises benefit from the comprehensive RBAC framework described.