Shulou(Shulou.com)06/01 Report--

This article introduces the relevant knowledge of "how to make superiors have all the permissions of subordinates in Spring Security". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

1. Role inheritance case

Let's start with a simple permission case.

Create a Spring Boot project, add Spring Security dependencies, and create two test users, as follows:

@ Override

Protected void configure (AuthenticationManagerBuilder auth) throws Exception {

Auth.inMemoryAuthentication ()

.withUser ("javaboy")

.password ("{noop} 123") .password ("admin")

.and ()

.withUser ("A little rain in the south of the Yangtze River")

.password ("{noop} 123")

.customers ("user")

}

Then prepare three test interfaces, as follows:

@ RestController

Public class HelloController {

@ GetMapping ("/ hello")

Public String hello () {

Return "hello"

}

@ GetMapping ("/ admin/hello")

Public String admin () {

Return "admin"

}

@ GetMapping ("/ user/hello")

Public String user () {

Return "user"

}

}

Our plan for these three test interfaces is as follows:

/ hello is an interface that anyone can access / admin/hello is an interface that can only be accessed by people with admin status / user/hello is an interface that can only be accessed by people with user status, all resources that user can access and admin can access

Note that the fourth specification means that all people with the status of admin automatically have the identity of user.

Next, let's configure the blocking rules for permissions. In the configure (HttpSecurity http) method of Spring Security, the code is as follows:

Http.authorizeRequests ()

.antMatch ("/ admin/**") .hasRole ("admin")

.antMatch ("/ user/**") .hasRole ("user")

.anyRequest () .authenticated ()

.and ()

...

...

Here we use the Ant-style path matchmaker. The Ant-style path matchmaker is widely used in the Spring family, and its matching rules are very simple:

Wildcard meaning * * match multi-layer path * match one-layer path? Match any single character

The meaning of the above configuration is:

If the request path meets the / admin/** format, the user needs to have the admin role. If the request path meets the / user/** format, the user needs to have the user role. The remaining request paths in other formats can be accessed only after authentication (login).

Note that the order of the three rules configured in the code is very important. Similar to Shiro, Spring Security matches in the order from top to bottom. Once the match is reached, it will not continue to match, so the order of the interception rules cannot be written wrong.

If you use role inheritance, this feature is easy to implement, we only need to add the following code to SecurityConfig to configure the role inheritance relationship:

@ Bean

RoleHierarchy roleHierarchy () {

RoleHierarchyImpl hierarchy = new RoleHierarchyImpl ()

Hierarchy.setHierarchy ("ROLE_admin > ROLE_user")

Return hierarchy

}

Note that when configuring, you need to manually prefix the role with ROLE_. The above configuration indicates that ROLE_admin automatically has permissions for ROLE_user.

Next, we start the project for testing.

After the successful launch of the project, we first logged in as a little rain in the south of the Yangtze River:

After logging in successfully, access the / hello,/admin/hello and / user/hello interfaces respectively, where:

/ hello can be accessed after login, and the access to this API is successful. / admin/hello requires admin identity, so the access failed. / user/hello requires user identity, so the access is successful.

Log in as javaboy again. After logging in successfully, we find that javaboy can also access / user/hello this interface, indicating that there is no problem with our role inheritance configuration!

two。 Principle analysis

The core of the configuration here is that we provide an instance of RoleHierarchy, so our analysis starts with this class.

RoleHierarchy is an interface in which there is only one method:

Public interface RoleHierarchy {

Collection

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.