-
Notifications
You must be signed in to change notification settings - Fork 40.2k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Align reactive web security more closely with servlet web security
There are some notable differences in the behavior of Spring Security's reactive and servlet-based web security. Notably, Servlet-based web security (`@EnableWebSecurity`) works without any authentication manager, rejecting requests as not authorized. By contrast reactive-based web security (`@EnableWebFluxSecurity`) fails to start up when there's no authentication manager, either provided directly as a bean or derived from a ReactiveUserDetailsService. There are also further differences at runtime where empty Monos from all ReactiveAuthenticationManagers results in an internal error and a 500 response whereas a similar situation in the servlet implementation results in a 401. Previously, to accommodate these differences in behavior, Spring Boot's auto-configuration would behave differently. In the Servlet case, web security would be enabled whenever the necessary dependencies were on the classpath. In the reactive case, web security would back off in the absence of an authentication manager to prevent a start up failure. While this difference is rooted in Spring Security, it is undesirable and something that we want to avoid Spring Boot users being exposed to where possible. Unfortunately, the situation is more likely to occur than before as ReactiveUserDetailsServiceAutoConfiguration now backs off more readily (gh-35338). This makes it more likely that the context will contain neither a reactive authetication manager not a reactive user details service. This commit reworks the auto-configurations related to reactive security. ReactiveSecurityAutoConfiguration will now auto-configure an "empty" reactive authentication manager that denies access through Mono.error in the absence of a ReactiveAuthenticationManager, ReactiveUserDetailsService, or SecurityWebFilterChain. The last of these is to allow for the situation where a filter chain has been defined with an authentication manager configured directly on it. This configuration of an authentication manager allows `@EnableWebFluxSecurity` to be auto-configured more readily, removing one of the differences between reactive- and Servlet-based security. Corresponding updates to the auto-configurations for reactive OAuth2 support have also been made. They no longer try to auto-configure `@EnableWebFluxSecurity`, relying instead upon ReactiveSecurityAutoConfiguration, which they are ordered before, to do that instead. Closes gh-38713
- Loading branch information
1 parent
964ccbb
commit afad358
Showing
6 changed files
with
29 additions
and
61 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters