Why Effective Permission Management Matters and How to Build Scalable RBAC Models

Why Permission Management Is Needed

In daily work, developers constantly request various permissions—network access, code repository, monitoring platforms, data queries, etc. While the process can be cumbersome, strict permission management protects sensitive data such as merchant information, fee configurations, and personal details, preventing accidental changes and data leaks.

Effective permission management ensures that each role sees only the data it needs.

Permission Model

Permission Design

Permissions can be classified by business type (view, modify) and mapped to page, menu, and button permissions. A tree‑structured design makes the hierarchy clear, allowing users to request exactly the permissions they need.

Why Roles Are Needed

Direct user‑permission assignment becomes unmanageable as the number of users grows. Introducing a third entity—roles—allows multiple users to inherit the same set of permissions, forming the classic RBAC model.

Evolution of Permission Models

RBAC Model

Roles act as bridges between users and permissions, supporting many‑to‑many relationships and reducing administrative overhead.

Role‑Inheritance RBAC (RBAC1)

Higher‑level roles inherit all permissions of lower‑level roles and can add extra permissions, matching hierarchical organizational structures.

Constrained RBAC (RBAC2)

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

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

Role mutual exclusion: A user cannot hold two mutually exclusive roles simultaneously.

Cardinality constraint: Limits the number of users for a specific role (e.g., only one super‑admin).

Prerequisite constraint: A user must hold a lower‑level role before being assigned a higher‑level role.

User Segmentation

User Groups

Groups aggregate users with similar permission needs, allowing a role to be assigned to the entire group, which simplifies large‑scale permission distribution.

Organizations

Linking roles to organizational units enables automatic permission assignment when users join or move between units, and enforces data visibility limits per organization.

Positions

Positions (e.g., finance director, accountant) map one‑to‑one with users and many‑to‑many with roles, allowing fine‑grained permission control based on job titles.

Ideal RBAC Model

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

Permission System Table Design

Standard RBAC Table Design

The standard RBAC schema includes six tables: users, roles, permissions, user‑role mapping, role‑permission mapping, and optionally a user‑permission table. The core relationship is represented by the

用户-角色-权限

triple.

Ideal RBAC Table Design

The ideal schema extends the standard model with additional tables for role constraints, groups, organizations, and positions, providing a flexible foundation for large‑scale enterprises.

Conclusion

The article offers a detailed, step‑by‑step guide to permission model design, emphasizing that companies with fewer than a few dozen employees can often rely on simple user‑permission mappings, while larger organizations benefit from the full RBAC hierarchy and its extensions.