Mastering Permission Management: From Basic RBAC to Advanced Role Inheritance

1 Why Permission Management Is Needed

In daily work, developers constantly request various permissions—network access, code repository, monitoring platform, data query, etc. While these requests can be cumbersome, strict permission control protects sensitive data such as merchant information, transaction details, and fee configurations, preventing accidental changes or data leaks.

Effective permission management ensures each role accesses only the data and actions required for its responsibilities.

2 Permission Model

2.1 Permission Design

Permissions can be classified by business type (view, modify) and mapped to system elements like pages, menus, and buttons. A tree‑structured menu hierarchy (e.g., first‑level and second‑level menus) makes permission requests clear.

2.2 Why Roles Are Needed

Directly assigning multiple permissions to each user becomes inefficient as the user base grows. Introducing a role as an intermediary (RBAC) allows many users to share the same set of permissions.

2.3 Evolution of Permission Models

2.3.1 RBAC Model

The classic role‑based access control (RBAC) links users, roles, and permissions in many‑to‑many relationships, reducing maintenance effort.

2.3.2 Role‑Inheritance RBAC (RBAC1)

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

2.3.3 Constrained RBAC (RBAC2)

Constraints such as role mutual exclusion, cardinality limits, and prerequisite roles improve security—for example, a user cannot be both accountant and auditor simultaneously.

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

2.4 User Grouping

2.4.1 User Groups

Creating a user group (e.g., all customer‑service staff) allows a role to be assigned to the group, automatically granting its members the same permissions.

2.4.2 Organizations

Mapping roles to organizational units enables automatic permission assignment when users join or move between departments.

2.4.3 Positions

Positions (e.g., finance director, accountant) can be linked to roles; a user’s position determines the set of roles they inherit.

2.5 Ideal RBAC Model

Combining RBAC, RBAC1, RBAC2, user groups, organizations, and positions yields a comprehensive model that can handle large data volumes and complex business scenarios.

3 Permission System Table Design

3.1 Standard RBAC Tables

The standard RBAC schema includes six tables: users, roles, permissions, user‑role mapping, role‑permission mapping, and optionally a permission hierarchy.

3.2 Ideal RBAC Tables

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

4 Conclusion

Permission models should be chosen based on company size, business complexity, and team structure; for most companies under a thousand employees, a simple RBAC model suffices, while larger organizations may benefit from the more elaborate ideal RBAC architecture.