How DuoLiXiong Built a Scalable Multi‑Platform RBAC Permission System

System Architecture

DuoLiXiong, a Baidu‑backed local‑life platform, operates three logical layers:

Ecology scene layer (WeChat mini‑program, Baidu engines, etc.)

Platform support layer (merchant, operation, audit, editor, distribution platforms)

Infrastructure layer (service‑governance solutions such as Tianlu, Tianyan, BRCC, and Baidu middle‑platform services)

Each platform maintains its own account system, so the permission service must provide isolation, data compliance, and language‑agnostic integration.

RBAC Foundations

The design starts from the classic Role‑Based Access Control (RBAC) model, which defines four core elements:

S (Subject) : a user or automated agent.

R (Role) : an authorized job title or position.

SE (Session) : the mapping between S, R and permissions during a session.

P (Permissions) : the ways to access resources.

RBAC enforces three rules:

Role assignment – a subject can act only after a role is assigned.

Role authorization – the active role must be authorized for the subject.

Permission authorization – permissions are granted only to the subject’s active role.

Four RBAC variants were evaluated:

Flat RBAC – simple user‑to‑role and role‑to‑permission mapping.

Hierarchical RBAC – roles inherit permissions from higher‑level roles.

Constrained RBAC – adds separation‑of‑duty constraints.

Symmetric RBAC – requires role‑review before permission assignment.

Why Flat RBAC Was Chosen

The business does not require complex role hierarchies or dynamic constraints, so a flat design minimizes management overhead while satisfying all functional requirements.

Core Functional Requirements

Menu‑level permission control.

Function‑group permission control.

Button‑level permission control.

Support for multiple independent business lines.

Isolation Across Business Lines

A dedicated product line table stores a prod_id. All user, role, and function tables include this foreign key, guaranteeing that data for each line remains isolated.

User Management

DuoLiXiong integrates three distinct user systems: merchant‑side accounts, internal O‑side accounts (operations/BD), and editor accounts. The user table therefore contains prod_id, user_type, and login_id as a composite unique key.

Role Definition

Because the current business does not need role inheritance, the role table follows a flat design. Its unique key is the combination of prod_id and en_name.

Permission Tree

All functional permissions are stored in a single function table that mirrors the front‑end page hierarchy. This enables a hierarchical permission tree that can be directly mapped to UI components (menus, function groups, buttons).

Data‑Level Permissions

Beyond functional rights, DuoLiXiong must restrict access to specific rows and columns:

Row permissions limit a user to his own department, organization, or a data range (e.g., contracts above a certain amount).

Column permissions hide sensitive fields; for example, only VIP users can see full content.

A separate data rule management module defines rules independently, then binds them to resources and roles. During RBAC evaluation, a role can be granted both functional permissions and data rules, producing a per‑user data‑access profile enforced at the storage layer.

Integration with Micro‑Service Framework

The permission service is exposed as a micro‑service and is invoked by B‑side, O‑side, and editor platforms. This interaction diagram illustrates the call flow:

Implementation Walk‑through

Define product lines : Insert rows into the product line table (fields: prod_id, name, description).

Populate user table : For each external account system, map its identifier to login_id, set user_type (e.g., MERCHANT, INTERNAL, EDITOR), and associate the appropriate prod_id.

Create roles : Insert role records with prod_id and a unique English name ( en_name). No parent‑role field is needed.

Build permission tree : Insert function records that reflect the UI hierarchy (menu → function group → button). Each record stores func_id, parent_id, name, and type (MENU, GROUP, BUTTON).

Assign permissions : Link roles to function IDs via a role‑function mapping table. Because the tree is hierarchical, a role that receives a parent node implicitly gains access to all descendant nodes.

Define data rules : Create rule entries (e.g., dept_id = 5 or amount > 10000) and bind them to roles through a role‑rule table.

Runtime evaluation : When a user logs in, the permission service resolves the user’s roles, aggregates functional permissions from the tree, and applies any bound data rules to generate the final access set.

Business‑Line Application Example

In the commerce‑operation system, the workflow to grant a new “Merchant Onboarding” role proceeds as follows:

Identify the target product line (e.g., prod_id = 3 for the merchant platform).

Create a role merchant_onboard with prod_id = 3.

Assign functional permissions: menu Merchant Management, function group Onboarding, button Submit Application.

Define a row rule org_id = user.org_id so onboarding staff can only see merchants belonging to their organization.

Bind the rule to the role.

When a staff member logs in, the service returns the menu, function group, and button permissions together with the row filter, ensuring the UI displays only authorized items and the backend query automatically includes WHERE org_id = ?.

Future Work

The permission system currently supports the main B‑side and O‑side platforms and is being extended to the editor platform. Planned enhancements include:

Onboarding additional business lines by adding new prod_id entries.

Refining data‑rule binding strategies to support more complex column‑level masking.

Adding audit logging for permission changes.

Reference: NIST RBAC model paper – https://csrc.nist.gov/CSRC/media/Publications/conference-paper/2000/07/26/the-nist-model-for-role-based-access-control-towards-a-unified-/documents/sandhu-ferraiolo-kuhn-00.pdf