Spring Security provides support for authorizing the incoming HTTP requests. By default, Spring Security’s authorization will require all requests to be authenticated. The explicit configuration looks like:
- Java
-
@Bean SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) { http .authorizeExchange(exchanges -> exchanges .anyExchange().authenticated() ) .httpBasic(withDefaults()) .formLogin(withDefaults()); return http.build(); }
- Kotlin
-
@Bean fun springSecurityFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain { return http { authorizeExchange { authorize(anyExchange, authenticated) } formLogin { } httpBasic { } } }
We can configure Spring Security to have different rules by adding more rules in order of precedence.
- Java
-
import static org.springframework.security.authorization.AuthorityReactiveAuthorizationManager.hasRole; // ... @Bean SecurityWebFilterChain springWebFilterChain(ServerHttpSecurity http) { // @formatter:off http // ... .authorizeExchange((authorize) -> authorize // (1) .pathMatchers("/resources/**", "/signup", "/about").permitAll() // (2) .pathMatchers("/admin/**").hasRole("ADMIN") // (3) .pathMatchers("/db/**").access((authentication, context) -> // (4) hasRole("ADMIN").check(authentication, context) .filter(decision -> !decision.isGranted()) .switchIfEmpty(hasRole("DBA").check(authentication, context)) ) .anyExchange().denyAll() // (5) ); // @formatter:on return http.build(); }
- Kotlin
-
@Bean fun springSecurityFilterChain(http: ServerHttpSecurity): SecurityWebFilterChain { return http { authorizeExchange { // (1) authorize(pathMatchers("/resources/**", "/signup", "/about"), permitAll) // (2) authorize("/admin/**", hasRole("ADMIN")) // (3) authorize("/db/**", { authentication, context -> // (4) hasRole("ADMIN").check(authentication, context) .filter({ decision -> !decision.isGranted() }) .switchIfEmpty(hasRole("DBA").check(authentication, context)) }) authorize(anyExchange, denyAll) // (5) } // ... } }
-
There are multiple authorization rules specified. Each rule is considered in the order they were declared.
-
We specified multiple URL patterns that any user can access. Specifically, any user can access a request if the URL starts with "/resources/", equals "/signup", or equals "/about".
-
Any URL that starts with "/admin/" will be restricted to users who have the authority "ROLE_ADMIN". You will notice that since we are invoking the
hasRole
method we do not need to specify the "ROLE_" prefix. -
Any URL that starts with "/db/" requires the user to have both "ROLE_ADMIN" and "ROLE_DBA". This demonstrates the flexibility of providing a custom
ReactiveAuthorizationManager
allowing us to implement arbitrary authorization logic. For simplicity, the sample uses a lambda and delegate to the existingAuthorityReactiveAuthorizationManager.hasRole
implementation. However, in a real world situation applications would likely implement the logic in a proper class implementingReactiveAuthorizationManager
. -
Any URL that has not already been matched on is denied access. This is a good strategy if you do not want to accidentally forget to update your authorization rules.