Designing Permission Management and RBAC Models

In daily work developers constantly request various permissions such as network access, code repository, monitoring platform, and data analysis, and strict permission management is required to protect sensitive data like merchant information, transaction details, and rate configurations, preventing accidental changes or data leaks.

Permissions can be classified by business type (view, modify) and system type (page, menu, button). Designing a tree‑shaped permission hierarchy—where buttons are children of second‑level menus, which are children of first‑level menus—makes the request process clear.

When the number of users grows, assigning permissions directly to each user becomes inefficient; a role acts as a bridge, allowing many users to share the same set of permissions, which is the core idea of the Role‑Based Access Control (RBAC) model.

用户-角色-权限 relationships are many‑to‑many, as illustrated by the RBAC diagram, enabling flexible assignment of multiple roles to a user and multiple permissions to a role.

Role inheritance (RBAC1) extends RBAC by allowing higher‑level roles to inherit all permissions of lower‑level roles while adding extra privileges, suitable for hierarchical organizations such as finance departments.

Constrained RBAC (RBAC2) adds security constraints like mutual exclusion (a user cannot hold two conflicting roles), cardinality limits (only one super‑admin), and prerequisite conditions (a senior role requires the junior role first).

User groups, organizations, and positions further simplify permission assignment: groups aggregate users with similar duties, organizations map roles to departmental structures for automatic permission propagation, and positions link specific job titles to appropriate roles.

The ideal RBAC model combines standard RBAC, role inheritance, constraints, user groups, organizations, and positions into a comprehensive schema capable of handling large data volumes and complex business scenarios.

Database design for the standard RBAC model requires six tables (user, role, permission, user‑role, role‑permission, and optional role‑permission constraints). The ideal RBAC model expands this with additional tables for role inheritance, constraints, groups, organizations, and positions, as shown in the accompanying ER diagrams.

In practice, choose the simplest model that fits the company size and complexity; for small teams a basic user‑permission mapping may suffice, while larger enterprises benefit from the full-featured RBAC architecture described above.