Skip to content

Deprecate WebSecurityConfigurerAdapter #10822

@eleftherias

Description

@eleftherias

With the following issues closed we've added the ability to configure the security of an application without needing the WebSecurityConfigurerAdapter.

Related issues:


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.

Metadata

Metadata

Assignees

Labels

in: configAn issue in spring-security-configtype: enhancementA general enhancement

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions