How to Build a Low‑Code, Visual RBAC Permission System with Spring Cloud

Background

As enterprise applications increase, isolated user data management creates information silos; a unified, low‑code, visual permission control configuration simplifies integration, reduces development and maintenance costs, and enhances overall system experience.

Terminology

RBAC: Role‑Base Access Control.

Permission predicate: expression describing permission characteristics or relationships.

Overview

Main Features

Non‑intrusive : unified permission verification service and filter.

Easy to configure : simple permission expression files.

Maintainable : add new services or resources by updating expression files.

Loose coupling : decoupled from business services for easy integration.

Fine‑grained : expression supports data‑level control.

Scalable : easy integration without extensive code changes.

Permission Architecture

The core uses an RBAC model where users are linked to roles and permissions in a many‑to‑many relationship.

It consists of user management, role management, menu management, and permission management (functional menu, operation, data permissions). Permissions are composed of functional permissions (UI, menu, operation) and data permissions.

Technical Architecture

The system is built on a micro‑service architecture. The security module follows OAuth2, tokens use the JWT standard, and the stack includes SpringCloud, SpringGateway, SpringSecurity with custom permission expressions.

OAuth2 defines an open, simple standard for user resource authorization without exposing passwords.

JWT is a compact, secure token format suitable for distributed SSO scenarios. Its claims convey authenticated user identity between identity and resource providers and may include additional business claims.

Permission Configuration

Key Configuration

The system complies with OAuth2, uses RSA asymmetric encryption for tokens, and MD5 for user passwords.

Permission Expression File

Located at resources/security.yml.

Permission expressions consist of HTTP method, URL path, and permission predicate. URL paths support wildcards, and predicates use logical operators (&&, ||, !).

Expression Syntax

Two types are supported: functional permission expressions and data permission expressions.

Functional Permission Expression

Format:

HTTP_METHOD URL_PATH=PERMISSION_PREDICATE

Red: HTTP method (GET, POST, PUT, DELETE, etc.)

Yellow: space placeholder

Green: URL pattern, e.g. /app/*/users or app/** Orange: equals sign linking resource to permission

Blue: permission predicate, e.g.

(view&&export)||edit

Data Permission Expression

Format:

HTTP_METHOD URL_PATH_PARAM=PERMISSION_PREDICATE_PARAM

Parameters (e.g. {userId}) identify row‑level data; multiple parameters or batch identifiers are supported.

URL Path Expressions

Three wildcard matching methods can be combined to create flexible patterns.

Example:

Permission Predicates

Support logical AND, OR, NOT, e.g. a&&b, a||b, !a, (a&&b)||(c&&d).

Parameters

Single‑parameter placeholders ({param}) or composite placeholders ([param]) identify data rows for fine‑grained control.

Examples of single and composite parameters are shown.

Element Configuration

Permission configuration includes whitelist (permit‑paths), guest users (jwt‑users), and resources (authorities, data‑authorities).

Whitelist (permit‑paths)

Requests that bypass permission filtering; configured with path expressions.

Resource Permissions

Core elements: functional authorities and data authorities. Functional authorities control API endpoints; data authorities add row‑level checks.

Functional Authorities

Control UI‑level business function interfaces such as list, add, delete, update.

Data Authorities

Fine‑grained control over row‑level data, e.g., users can only operate on their own records.

Micro Frontend

Micro‑frontend architecture applies the micro‑service concept to the browser, splitting a web app into independently developed and deployed small applications.

Front‑end integration uses a loader, routing, and dynamic loading to assemble the main page from micro‑frontends, reducing integration complexity.

External front‑end applications are packaged and deployed independently, then integrated via configuration and lifecycle management.

Conclusion

Implementing permission control via expressions enables easy integration of subsystems, isolates security concerns, and simplifies maintenance, though manual configuration of large permission datasets remains cumbersome.