Design of Zhuanzhuan's Unified Permission Management System – Part 1: Architecture and Models

At the end of last year, Zhuanzhuan launched the construction of a unified permission management system, which is now used by most of the company's business systems. This series is divided into three parts; the first part focuses on the design.

Table of Contents

Problems and status of the old permission system

Industry mainstream models 2.1 RBAC model 2.2 ABAC model

Design ideas of the new permission system

Core modules of the new permission system

Summary and outlook

Problems and Status of the Old Permission System

Zhuanzhuan previously lacked a unified permission system; each business developed its own or reused others', leading to duplicated effort, high maintenance cost, fragmented solutions, and difficulty tracing authorizations.

Industry Permission System Design Approaches

Two mainstream models are introduced:

Role‑Based Access Control (RBAC)

Attribute‑Based Access Control (ABAC)

RBAC Model

RBAC assigns permissions to roles rather than individual users, simplifying management. A diagram (image) illustrates the user‑role‑permission relationship.

When using the RBAC模型 , users obtain permissions through the 用户 -> 角色 -> 权限 chain, eliminating the need to manage each user's permissions directly.

Example: In a GitLab‑like system, roles such as Admin , Maintainer , and Operator each have distinct permissions; assigning a user the Admin role grants repository creation and deletion rights.

ABAC Model

ABAC evaluates access based on attributes of the subject, resource, action, and environment, offering finer‑grained control for scenarios like time‑based or location‑based restrictions.

Typical ABAC scenarios include granting edit rights to a specific book, allowing access when a user's department matches the document's department, or restricting access before 9 AM for a certain department.

Because RBAC cannot express such conditional rules, ABAC is preferred for dynamic, attribute‑driven policies.

Design Ideas of the New Permission System

Considering Zhuanzhuan's business, RBAC satisfies most cases with lower development cost, so the new system adopts a core RBAC model while temporarily not supporting scenarios that require ABAC.

The standard RBAC chain 用户 -> 角色 -> 权限 is extended to allow direct permission assignment to users, resulting in the final permission set being the union of role‑derived permissions and individually assigned permissions.

New permission model: User permissions = permissions from assigned roles + directly assigned permissions.

Core Module Design

The system supports unified login, organization‑based user management, multi‑system permission handling, and separate menu and data permissions.

Roles are created per system (e.g., store manager) and users receive permissions either by role assignment or direct permission addition.

Permission System's Own Access Control

Three internal user types are defined: Super Administrator (full access), Permission Operator (admin role in at least one integrated system), and Regular User (can request access).

Permission Types

Two main categories: Menu/Function permissions (navigation, buttons, APIs) and Data permissions (access scope, often called “organization”).

Default Role Classification

Each system provides three default roles: Super Administrator (all permissions), System Administrator (can grant permissions but has none itself), and Authorization Administrator (can grant permissions within its own scope).

System/Menu/Data Permission Management

Integrating a new system involves creating the system, configuring menu permissions, configuring data permissions, and creating system roles.

System codes act as unique identifiers and prefix menu and data permission codes to ensure global uniqueness.

Menu Management

Menus are categorized into Directory, Menu, and Operation, each with distinct UI representation.

Two modes for menu permission usage: Dynamic (menus managed by the permission system) and Static (menus controlled by the front‑end, permission system only provides access checks).

Role and User Management

Roles and users can be batch‑processed; users can be assigned roles or individual menu/data permissions.

Permission Application

Users can request permissions through an approval workflow, with the ability to select required permissions by reverse‑looking up roles from chosen menu or data points.

Operation Logs

Two log types: operation transaction logs (searchable) and service logs (high volume, less searchable). Logs record who, when, target, module, and action for create, update, delete operations.

Summary and Outlook

The new permission system’s design and modules have been introduced; it is already used extensively within Zhuanzhuan, simplifying permission management and supporting future business growth.

References

[1] Choosing the right access control model: https://docs.authing.cn/v2/guides/access-control/choose-the-right-access-control-model.html