Designing a Flexible Permission Model for WOS: Merging RBAC and PBAC

Introduction

Weimob's original permission model under the new cloud was based on a traditional RBAC approach, which offered limited flexibility. To support the WOS ecosystem, a more adaptable model was required that could handle diverse merchant role assignments and dynamic business scenarios.

Common Permission Models

RBAC

Role‑Based Access Control

RBAC has evolved into variants such as RBAC1, RBAC2, introducing parent‑child roles, static and dynamic separation of duties.

Advantages : Simple structure, easy interaction.

Disadvantages : Limited flexibility for fine‑grained control scenarios.

ABAC & PBAC

Attribute‑Based Access Control

ABAC evaluates access based on subject attributes (e.g., position, department), resource attributes (e.g., file type, tags), environment attributes (e.g., time, location), and action attributes (e.g., read/write) to determine authorization.

PBAC is an advanced form of ABAC; while ABAC often relies on standards like XACML, PBAC policies can be expressed in natural language.

Advantages : High flexibility and extensibility.

Disadvantages : Complex implementation, higher performance demands, lower usability for business users, and greater design effort.

Weimob Permission System Model

Model Selection

Research before building the WOS permission system focused on:

Preserving existing interaction patterns to reduce merchant learning cost.

Recognizing that merchant accounts are numerous but role differences are limited.

Ensuring menu permissions can be flexibly combined across applications, nodes, and channels.

The goal is to allow merchants to configure accounts so that permissions can adapt to varying applications, nodes, channels, or time periods without extensive re‑engineering.

Known special cases include:

Different permissions for the same role across applications or nodes.

Menu variations depending on purchased applications or enabled nodes.

Different permission sets for the same role on PC versus mobile channels.

Model Determination

Based on the research, a hybrid model was created that extends RBAC with PBAC concepts. The core structure follows a "subject – role – permission" pattern, while the "role – permission" link incorporates scenario rules, forming a "subject (role) – policy (scenario rule) – permission" flow. Additional components such as a scenario‑rule transformer and a rule‑matching engine were added.

The model abstracts the subject to reduce computation and improve authorization efficiency, though it can increase maintenance complexity.

By abstracting applications, nodes, and accounts as distinct permission subjects and intersecting their permissions, the system can satisfy the previously listed role‑permission change scenarios with minimal adjustments.

Process Overview

Implementation

Assignment

When applying the model, permission configuration must translate environment and resource attributes into scenario rules.

Authorization

The main authorization logic includes:

Collecting environment and attribute data for context initialization.

Initializing permission filter chains based on business scenarios.

Using a rule engine to uniformly validate scenario rules.

Authorization SDK

Two approaches were considered for unified permission interception in internal systems; the SDK‑based method was chosen because it:

Gives control to the integrator, enabling high autonomy and removing gateway‑level decisions.

Reduces the difficulty of managing centralized mapping updates.

Supports direct Dubbo interactions between applications without passing through the gateway.

Conclusion

The hybrid model enables highly flexible permission assignment through abstracted policy rules, fitting scenarios that require simple allocation and flexible authorization. While it inherits PBAC’s performance challenges as rule complexity grows, improving authorization performance will be a key future optimization direction.