Integrating RBAC Permission Model into Spring Cloud Gateway for Authentication and Authorization

This article introduces the RBAC (Role‑Based Access Control) permission model and demonstrates how to integrate it into the gateway layer of a Spring Cloud micro‑service system for authentication and authorization.

What is RBAC? RBAC separates users, roles, and permissions, allowing flexible assignment of URLs (permissions) to roles and decoupling users from direct permission management.

Design Idea The gateway checks the required permission of the requested URL (stored in Redis) against the roles contained in the JWT token; access is granted when there is an intersection.

URL‑Role Mapping Three tables (permission, role, permission_role) store the relationships. At application startup the mappings are loaded into Redis, and any changes from the admin UI are synchronized to Redis in real time.

Example permission entry: /order/info is a URL permission that can be assigned to specific roles.

Restful Permission Control The permission table can store an HTTP method (e.g., POST:/order/info) to distinguish actions; a wildcard *:/order/info matches all methods.

Dynamic Permission By keeping the URL‑role map in Redis, dynamic updates are possible without restarting services.

Implementation Steps

Load URL‑role relationships from the database into Redis at startup. The relevant code resides in the oauth2-cloud-auth-server module.

Implement UserDetailsService to load user details and roles (prefixed with ROLE_) from the database and assemble them into authorities.

In the gateway’s authentication manager, construct the request key (e.g., POST:/order/info), retrieve the required roles from Redis, and compare them with the user’s roles. Super‑admin users bypass the check.

Key code snippets:

@Override
public void configure(ClientDetailsServiceConfigurer clients) throws Exception {
    // Load client details from the database using JdbcClientDetailsService
    clients.withClientDetails(new JdbcClientDetailsService(dataSource));
}

The SQL for the additional oauth_client_details table is provided to store OAuth2 client information, including client ID, secret, scopes, grant types, and token validity periods.

Conclusion By loading permission data into Redis and performing the check in the gateway layer, the system achieves centralized, dynamic RBAC enforcement while supporting Restful URL patterns and OAuth2.0 authentication.