Mastering Permission Design: From RBAC Basics to Advanced Strategies

1. The Headache of Permission Design

Designers often abstract multiple roles that reflect product demands, then map usage scenarios to each role. When role scenarios do not conflict, a single solution can serve all, such as NetEase Cloud Music offering both song and radio features. When scenarios are completely disjoint, separate systems are built, like Didi’s driver and passenger apps. Most B‑side products fall between these extremes, requiring a permission system to balance shared and isolated functionality.

Designers may feel intimidated by permission systems because they are backend‑heavy, hard to dissect during competitor analysis, and mistakes can break entire workflows.

2. Designing with the RBAC Model

The widely adopted Role‑Based Access Control (RBAC) model assigns permissions to roles, then links users to roles, reducing management overhead.

2.1 Basic RBAC Without roles, each user must be granted permissions individually, leading to massive cost. Introducing roles allows many‑to‑many relationships between users and roles, and a user’s permissions become the union of its roles.

2.2 RBAC with User Groups For large platforms, creating a role for thousands of users is still costly. Grouping users with similar scenarios into a user group lets you assign roles and permissions to the group, simplifying bulk changes.

2.3 Role Inheritance RBAC When roles form a hierarchy (e.g., design lead → design member), higher‑level roles inherit all permissions of lower‑level roles and can add extra ones. Inheritance can be represented as a tree or a directed acyclic graph.

2.4 Restricted RBAC Some roles must be mutually exclusive (e.g., a user cannot be both “athlete” and “referee”). Within a role group only one role can be assigned, while different groups may coexist. Restrictions can also be quantitative, such as limiting the number of administrators in a team.

3. Splitting and Designing Permissions

Permissions typically consist of page, operation, and data elements. Page permissions are prerequisite for operation permissions, and data permissions govern CRUD actions. Design should modularize each page and operation with independent interfaces, ensuring smooth user experience even when some actions are hidden.

Key design points:

Determine whether permissions are configured in the backend (fixed roles) or exposed to the front‑end for dynamic, tenant‑specific customization.

Break down each object into basic units (e.g., view, add, delete, edit) and combine inseparable actions into a single unit when necessary.

Prioritize page permissions before operation and data permissions.

Ensure view permission is granted before any modify permissions.

Recognize that role‑permission relationships go beyond simple yes/no, encompassing data scopes, limits, and field‑level restrictions.

4. Practical Tips

4.1 Hidden admin Reserve an admin role for initial system setup; it may be visible as a “super admin” or kept invisible for internal staff.

4.2 Initial permission assignment Provide default roles (e.g., guest) for new users and optionally map initial permissions to user attributes such as job title.

4.3 Self‑management in user administration Prevent a sole admin from deleting or demoting themselves, which would leave the system without management capability.

4.4 No‑page‑permission prompts When a user accesses a URL without the required page permission, display a clear “no permission” message instead of a silent failure.

5. Summary

Permission system design is about defining nodes and their relationships:

Nodes

User

User group

Role

Role group

Permission (page, operation, data)

Permission group (page, operation, data)

Relationships

Yes/No (assignment)

Inheritance

Restrictions (mutual exclusion, range, boundary, field)

Clarifying all logic and flexibly combining these nodes enables hundreds of viable permission‑design solutions.