Permission System Design and RBAC Implementation Practice in Backend Applications
The article explains permission system fundamentals, classifies page, function, and data permissions, compares DAC, MAC, RBAC, and ABAC models, details RBAC variants, and demonstrates a practical Egg framework plugin implementation that configures roles, resources, and data rules to achieve flexible, secure backend access control.
Permission management is an essential component of any backend system, especially when dealing with sensitive data that requires different personnel to manage different aspects according to their responsibilities. A well-designed permission system ensures smooth business data processing, reduces operational risks, and protects data security.
This article provides a comprehensive guide to permission systems, covering fundamental concepts, classification, models, and practical implementation. Permission essentially represents access control—determining whether a subject can perform a specific operation on a resource based on certain rules. The three core elements of permissions are: subject, resource, and operation.
Permissions can be classified into three categories: Page Permissions (access to pages, modules, menus), Function Permissions (associated with page permissions, including CRUD operations, potentially down to interface-level control), and Data Permissions (controlling which data different subjects can view, the most complex part that varies by system, including row-level and column-level permissions).
Four classic permission models are discussed: DAC (Discretionary Access Control), MAC (Mandatory Access Control), RBAC (Role-Based Access Control), and ABAC (Attribute-Based Access Control). RBAC is the most widely used model, introducing the concept of role between users and permissions to achieve decoupling.
The RBAC family includes: RBAC0 (core concept with user-role-permission many-to-many relationships), RBAC1 (adds role inheritance), RBAC2 (adds constraints with static and dynamic separation of duties), and RBAC3 (combines RBAC1 and RBAC2).
The article then presents a practical implementation using an Egg framework plugin. The implementation uses an Access Control List (ACL) configuration approach to define relationships between resources, roles, and permissions. The configuration includes:
Initial roles definition: ['admin', 'music_bridge_ios_developer', 'music_bridge_admin', 'music_link_developer']
Resource-permission mappings with allowed actions
Data permission rules with attributes and where conditions
URL-level role associations
The plugin provides features including: database configuration and schema definition, automatic table generation (roles, permissions, role-permission associations, URL-role associations), super administrator support, URL and API-level interception, customizable data permission filtering rules, API-based user-role-permission management, parent role support, custom error messages, and role deletion validation.
The key insight is that permission design should start from actual use cases—business logic determines functional logic, and appropriate granularity of permissions leads to a flexible and efficient permission system.
NetEase Cloud Music Tech Team
Official account of NetEase Cloud Music Tech Team
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.