Mastering Permission Management: From Basic RBAC to Advanced Role‑Inheritance Models

Why Permission Management Is Needed

New employees often need to request various permissions (network access, code repository write rights, monitoring dashboard logins, data‑query privileges, etc.). Missing permissions cause delays and can expose sensitive data such as merchant information, fee configurations, and personal details. Strict permission control limits data exposure to only the roles that require it, reducing the risk of accidental or malicious misuse.

Permission Model Overview

Permission Design

Permissions are categorized by business type (e.g., data‑view, data‑modify) and mapped to system elements such as page permissions, menu permissions, and button permissions. Menus are hierarchical (level‑1, level‑2, level‑3). A tree‑shaped permission structure makes it easy to see required permissions when applying.

Why Roles Are Needed

When the number of users grows, assigning permissions one‑by‑one becomes inefficient. Introducing a role as an intermediary allows many users to share the same set of permissions, reducing administrative overhead.

Evolution of Permission Models

RBAC Model

The classic role‑based access control (RBAC) links users to roles and roles to permissions. Both relationships are many‑to‑many, enabling flexible assignment.

Role‑Inheritance RBAC (RBAC1)

Roles can inherit permissions from lower‑level roles. For example, a finance director inherits all permissions of a finance manager, who inherits those of a cashier. This hierarchy reduces duplication.

Constrained RBAC (RBAC2)

Additional constraints improve security, such as mutually exclusive roles, cardinality limits (e.g., only one super‑admin), and prerequisite roles (a senior role requires the junior role). These constraints are stored in separate tables.

User Grouping and Organization

User Groups

When many users share the same role (e.g., a 500‑person customer‑service team), a user group can be created and the role assigned to the group, automatically granting the role to all members.

Organization Mapping

Mapping roles to organizational units enables automatic permission assignment when a user joins or moves between departments. Data visibility can also be limited to the user's organization.

Position Mapping

Positions (e.g., finance director, manager) can be linked to roles. Since a person holds a single position, the user‑position relationship is one‑to‑one, while position‑role remains many‑to‑many.

Permission System Table Design

Standard RBAC Tables

Four core tables are required: users, roles, permissions, plus two junction tables user_role and role_permission. The ER diagram shows the many‑to‑many relationships.

Ideal RBAC Tables

When data volume and business complexity increase, the model expands to include role inheritance, constraints, user groups, organizations, and positions. The resulting ER diagram supports all required relationships.

Conclusion

Permission management is a cornerstone of data security. Small teams (< 100 people) may use a simple user‑permission table, but as the organization grows, adopting RBAC, role inheritance, constraints, user groups, and organizational mapping becomes essential. The optimal model balances company size, business complexity, and operational needs.