You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the extreme majority of Spring Boot applications, @EnableGlobalAuthentication is turned on, either through explicit use @EnableWebSecurity or the SpringBootWebSecurityConfiguration auto-configuration.
By default, this wires a UserDetailsService or AuthenticationProvider bean into a global ProviderManager, that is used as a parent of all other managers.
This approach comes with edge-cases that are often surprising to users (gh-14663), e.g. when there is a UserDetailsService+AuthenticationProvider bean, one takes precedence. We've added some logging to help user discover their misconfigurations (gh-14711), but we have an opportunity to make things more predictable.
It is difficult to discover how username+password based authentication is configured. When looking at OAuth2LoginConfigurer, Saml2LoginConfigurer or X509Configurer, users can infer which AuthenticationProvider is required and how they can extend existing behavior (e.g. applying postProcess). It is not the case with FormLoginConfigurer or HttpBasicConfigurer. Users need to be aware that HttpSecurity has a ProviderManager, and that the ProviderManager has a parent, etc. This contrasts with the Reactive security configuration, where configuration is much more explicit.
While shared logic between SecurityFilterChains may be desirable, it may not the desired default behavior. Global authentication can also be enabled more explicitly.
In the extreme majority of Spring Boot applications,
@EnableGlobalAuthentication
is turned on, either through explicit use@EnableWebSecurity
or theSpringBootWebSecurityConfiguration
auto-configuration.By default, this wires a
UserDetailsService
orAuthenticationProvider
bean into a globalProviderManager
, that is used as a parent of all other managers.This approach comes with edge-cases that are often surprising to users (gh-14663), e.g. when there is a
UserDetailsService
+AuthenticationProvider
bean, one takes precedence. We've added some logging to help user discover their misconfigurations (gh-14711), but we have an opportunity to make things more predictable.It is difficult to discover how username+password based authentication is configured. When looking at
OAuth2LoginConfigurer
,Saml2LoginConfigurer
orX509Configurer
, users can infer whichAuthenticationProvider
is required and how they can extend existing behavior (e.g. applyingpostProcess
). It is not the case withFormLoginConfigurer
orHttpBasicConfigurer
. Users need to be aware that HttpSecurity has aProviderManager
, and that theProviderManager
has a parent, etc. This contrasts with the Reactive security configuration, where configuration is much more explicit.While shared logic between
SecurityFilterChain
s may be desirable, it may not the desired default behavior. Global authentication can also be enabled more explicitly.Related gh-13266, gh-13270
The text was updated successfully, but these errors were encountered: