Mastering RBAC: From Basic Access Control to Advanced Role Inheritance Models

Why Permission Management Is Needed

Developers frequently need to request various permissions (network access, code repository commits, monitoring dashboards, data queries). Without a systematic approach, urgent data access can be delayed by lengthy approval processes, and uncontrolled permission distribution creates security risks such as unauthorized configuration changes or leakage of confidential merchant data.

Strict permission management ensures that only appropriate roles can view or manipulate specific data, protecting company assets and complying with regulatory requirements.

Permission Models

Permission Design

Permissions are classified by business operation (e.g., view, edit) and mapped to system elements such as pages, menus, and buttons. A hierarchical menu structure (first‑level, second‑level, third‑level) should be represented as a tree so that applicants can clearly see which permissions they need.

Why Roles Are Needed

When the number of users grows, assigning permissions individually becomes inefficient. Introducing roles allows many users to share the same set of permissions, reducing administrative overhead.

Direct user‑permission mapping still scales poorly because each user‑permission pair must be maintained, leading to high maintenance cost.

Evolution of Permission Models

RBAC Model

Roles act as a bridge between users and permissions: a user can have multiple roles, a role can contain multiple permissions, and a permission can belong to multiple roles. This many‑to‑many relationship dramatically reduces management effort in large organizations.

Role‑Inheritance RBAC Model (RBAC1)

This model lets higher‑level roles inherit all permissions of lower‑level roles while adding extra privileges, matching typical corporate hierarchies (e.g., finance supervisor inherits cashier permissions).

Inheritance can be represented as a tree (single parent) or a directed acyclic graph (multiple parents).

Constrained RBAC Model (RBAC2)

Additional security constraints are added to the basic RBAC model:

Role mutual exclusion – a user cannot hold two conflicting roles simultaneously.

Cardinality constraints – limit the number of users that can be assigned a particular role (e.g., only one super‑admin).

Prerequisite constraints – a user must possess a lower‑level role before being granted a higher‑level role.

User Segmentation

User Groups

When many users share the same set of permissions, a user group can be created; assigning a role to the group automatically grants the role to all its members, simplifying bulk permission management.

User groups are collections of users, whereas roles map users to permissions.

Organizations

Aligning permissions with an organization’s hierarchy allows automatic permission assignment when a user joins or moves between departments, ensuring they only see data relevant to their organization.

Positions

Positions (e.g., finance director, accountant) have distinct permission needs; linking positions to roles creates a one‑to‑one user‑position relationship and a many‑to‑many position‑role relationship.

Permission System Table Design

Standard RBAC Table Design

The classic RBAC schema consists of six tables: users, roles, permissions, a user_role mapping table, a role_permission mapping table, and an optional role_hierarchy table for inheritance.

Ideal RBAC Table Design

The extended model adds tables for role inheritance, constraint definitions, user groups, organizations, and positions, providing a comprehensive framework for large‑scale, complex permission requirements.

This comprehensive model can address most permission‑related challenges; smaller organizations may still opt for the simpler user‑permission approach.