-
Notifications
You must be signed in to change notification settings - Fork 6.1k
Description
With the following issues closed we've added the ability to configure the security of an application without needing the WebSecurityConfigurerAdapter
.
Related issues:
- Configure HTTP Security without extending WebSecurityConfigurerAdapter #8804
- Configure WebSecurity without WebSecurityConfigurerAdapter #8978
- HttpSecurity DSL should accept an AuthenticationManager #10040
- Add LDAP AuthenticationManager factory #10138
Background
Below is additional information on why WebSecurityConfigurerAdapter
is being deprecated.
WebSecurityConfigurerAdapter
and HttpSecurity
DSL were created to work around spring-projects/spring-framework#18353 Unfortunately, WebSecurityConfigurerAdapter
design is flawed causing quite a few problems that cannot be properly fixed.
Does Not Expose Beans
The first is that rather than exposing Beans, it silently creates objects that cannot be used by the underlying application or by Spring Boot for auto configuration. This makes it difficult for Boot to know if an AuthenticationManager
needs to be created or not. It also makes it difficult for users to leverage an AuthenticationManager
in their own code as a Bean.
Instead, it is preferred that users expose an AuthenticationManager
(or AuthenticationProvider
or UserDetailsService
) as a Bean
so it can be used by the rest of the application.
Beans Cannot be Injected via Method Arguments
Another issue with WebSecurityConfigurerAdapter
is that the static nature of the method signatures means that Security configuration does not follow best practices of passing in the Beans by method arguments. Instead, dependencies must be injected into member variables or resolved through method references.
While there is nothing inherently wrong with this, it doesn't follow best practices causing several limitations.
When using method arguments for Bean dependencies Spring knows exactly which Beans are dependencies before Object creation takes place. This means the minimal Object graph can be created. When using member variables, @Autowired
methods on the configuration class, etc Spring needs to initialize the entire @Configuration
to resolve the Bean. Similar problems happen when using method references to resolve Beans.
Not being able to determine the minimal dependencies of a Bean leads to BeanCurrentlyInCreationException
(e.g. gh-4489 ) and AlreadyBuiltException
being thrown (e.g. gh-3916). Again, this happens in large part due to not having as much information about the Object graph since parameters are not used to inject the Bean dependencies.