Information Security 10 min read

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.

NetEase Cloud Music Tech Team
NetEase Cloud Music Tech Team
NetEase Cloud Music Tech Team
Permission System Design and RBAC Implementation Practice in Backend Applications

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.

Access ControlRBACPermission SystemRole-Based Access Controlbackend securityData PermissionsEgg Framework
NetEase Cloud Music Tech Team
Written by

NetEase Cloud Music Tech Team

Official account of NetEase Cloud Music Tech Team

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.