Actual combat! Spring Cloud Gateway integrates the RBAC permission model for dynamic permission control!

This article introduces how the gateway layer integrates RBAC permission model for authentication. The contents of the article are as follows:

What is the RBAC permission model?

Role-based Access Control (RBAC) is the most widely used permission model.

I’m sure you’re familiar with this permission model. This model has three users, roles and permissions. In the traditional permissions model, users are directly associated with the role layer, which decouples the users and permissions, making the permissions system have clearer responsibility division and higher flexibility.

The SQL of the above five tables will not be posted in detail, but will be placed in the doc directory of the case source code, as shown below:

Design ideas

The RBAC permission model is role-based, so permissions in Spring Security are roles. The specific authentication and authorization process is as follows:

1. The user logs in to request a token
2. Use the UserDetailService command to query and load user information, such as password and permission (role)…. Encapsulate to UserDetails
3. Token request successful, access resource with token
4. The gateway level compares whether the permissions required to access the URL (in Redis) overlap with the permissions that the current token has. If there is an intersection, the user has the permission to access the URL.
5. If the user has the permission, the user will access it. Otherwise, the user will be denied

The above is just the general process, there are still some details to be discussed, as follows:

1. How to maintain the permissions corresponding to URLS?

This is relatively easy to implement, involving three tables of RBAC permission mode, namely, permission table, role table, and permission role mapping table. The specific implementation process is as follows:

1. The mapping between permissions (urls) and roles is loaded into Redis at project startup.
2. For the management interface related to the URL corresponding relationship changes to Redis in real time.

For example, the permission has the following data:

The /order/info URL is a permission that the administrator can assign to a specific role.

2. How to implement Restful permission control?

Restful interface urls are the same except for the request methods. Therefore, request methods, such as POST, GET, PUT, and DELETE…., need to be reserved for precise permission control

You can place a method identifier in the URL field of the permission table, such as POST, where the full URL is: POST:/order/info

Of course the *:/order/info asterisks indicate that all requests are fulfilled.

3. Can dynamic permission control be achieved in this way?

There are many ways to control permissions, such as Security’s own annotations, method intercepts, and extending Spring Security to implement dynamic permissions. This will be covered separately in a later article!

Chen this article is the permission, role corresponding relationship stored in Redis, so want to achieve dynamic permission control only need to maintain this relationship in Redis. The data in Redis is as follows:

Case implementation

This article is still modified based on the following three modules. If it is not clear, you can check Chen’s previous articles.

The change directories involved are shown below:

1. Load URL<-> role mapping from database to Redis

At the start of the project directly read the database permissions loaded into Redis, of course, there are many methods, according to their own situation. The code is as follows:

The code here is under the oAuth2-Cloud-Auth-server module.

2. Implement the loading permission of UserDetailsService

The UserDetailsService, which I’m sure you’re familiar with, loads user details from the database based on the user name.

The code is as follows:

The code at ① is to query user information from the database through JPA and assemble roles, which must start with ROLE_.

(2) Encapsulate the acquired role into authorities and pass it down.

The code here is under the oAuth2-Cloud-Auth-server module.

The source code of the case has been uploaded to GitHub, concerned public number: code ape technology column, reply keywords: 9529 access!

3. Verify permissions in the authentication manager

In the last article actual combat dry goods! Spring Cloud Gateway integrates OAuth2.0 to achieve distributed unified authentication and authorization! The role of the authentication manager is described in detail, but I won’t go into details here. The code is as follows:

The code at ① is to assemble the request URL in a restful style, such as POST:/order/info

The code at ② is to take the URL and role correspondence from Redis to traverse, and compare with AntPathMatcher to obtain the role required by the current URL request.

(3) The code is to compare the role required by the current URL and the role of the current user, divided into two steps:

• If the administrator is a super administrator, permission is granted without permission comparison
• If you are not a super administrator, you need to compare roles and allow access only when there is an intersection

The code here is in the oauth2-Cloud-gateway module.

4, summarize

Key code is the above three, in addition to some DAO layer related code will not be posted, their own download source to see!

Additional changes

This article also incidentally puts the client information in the database, whereas the previous articles put it in memory.

Create a new table in the database, SQL as follows:

CREATE TABLE `oauth_client_details` (
  `client_id` varchar(48) NOT NULL COMMENT 'Client ID',
  `resource_ids` varchar(256) DEFAULT NULL COMMENT 'Id of resource, separated by commas',
  `client_secret` varchar(256) DEFAULT NULL COMMENT 'Client key',
  `scope` varchar(256) DEFAULT NULL COMMENT 'Client permissions, separated by commas',
  `authorized_grant_types` varchar(256) DEFAULT NULL COMMENT 'Types of authorization, five, comma separated.',
  `web_server_redirect_uri` varchar(256) DEFAULT NULL COMMENT 'Jump URI for authorization code pattern',
  `authorities` varchar(256) DEFAULT NULL COMMENT 'Permissions, multiple separated by commas',
  `access_token_validity` int(11) DEFAULT NULL COMMENT 'Expiration time of access_token, in milliseconds, overriding hard-coded',
  `refresh_token_validity` int(11) DEFAULT NULL COMMENT 'Expiration time of refresh_token in milliseconds, overriding hard coding',
  `additional_information` varchar(4096) DEFAULT NULL COMMENT 'Extended field, JSON',
  `autoapprove` varchar(256) DEFAULT NULL COMMENT 'Default false, automatic authorization or not'.PRIMARY KEY (`client_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Copy the code

The configuration file of OAuth2.0 in authentication service loads the client information from the database. The implementation class is JdbcClientDetailsService, and the key codes are as follows:

	@Override
    public void configure(ClientDetailsServiceConfigurer clients) throws Exception {
        // Use JdbcClientDetailsService to load the client information from the database
        clients.withClientDetails(new JdbcClientDetailsService(dataSource));
    }
Copy the code

conclusion

This article introduces the gateway integrated RBAC authority model for authentication and authentication. The core idea is to load the authority information into Redis cache and verify the authority in the gateway authentication manager, which also integrates Restful URL.