Deprecate WebSecurityConfigurerAdapter

[eleftherias]

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.

[linghengqian]

Thanks for your efforts, I noticed that https://docs.spring.io/spring-security/reference/5.7.0-M1/servlet/configuration/java.html documentation has not been updated, so I am a little confused, something like this How should the scene migrate WebSecurityConfigurerAdapter to SecurityFilterChain. The TokenAuthFilter here extends BasicAuthenticationFilter, so the construction requires an AuthenticationManager parameter.

  @Order(1)
  @Configuration
  public static class ApiWebSecurityConfigurerAdapter extends WebSecurityConfigurerAdapter {
         @Override
         protected void configure(HttpSecurity http) throws Exception {
                 http.authorizeHttpRequests(authorize -> authorize.anyRequest().authenticated())
                         .addFilter(new TokenAuthFilter(super.authenticationManager()));
         }
}

[eleftherias]

Thanks for bringing this up @linghengqian.

The reference documentation was updated as part of gh-10003 and will be available in 5.7.0-M2.
At the moment it's available in the latest snapshot documentation https://docs.spring.io/spring-security/reference/5.7/servlet/configuration/java.html.

We will also share a blog post on how to migrate common use-cases when we release 5.7.0-M2.

The configuration you share above can be rewritten as follows:

@Configuration
public class SecurityConfiguration {

    @Bean
    @Order(1)
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
                // you probably want a request matcher since you are using @Order
                .authorizeHttpRequests((authorize) -> authorize
                        .anyRequest().authenticated()
                )
                .apply(customDsl());
        return http.build();
    }
}

public class MyCustomDsl extends AbstractHttpConfigurer<MyCustomDsl, HttpSecurity> {
	@Override
	public void configure(HttpSecurity http) throws Exception {
		AuthenticationManager authenticationManager = http.getSharedObject(AuthenticationManager.class);
		http.addFilter(new TokenAuthFilter(authenticationManager));
	}

	public static MyCustomDsl customDsl() {
		return new MyCustomDsl();
	}
}

[eleftherias]

Closed via e97c643

[eleftherias]

The related blog post containing common use-cases https://spring.io/blog/2022/02/21/spring-security-without-the-websecurityconfigureradapter

[NotFound403]

huge change

[tha2015]

It is not a good practice to both modify the input parameter and return a value. I would not write some method like this if I have a choice.

[linghengqian]

It is not a good practice to both modify the input parameter and return a value. I would not write some method like this if I have a choice.

If you need to configure Multiple HttpSecurity, you'll find WebSecurityConfigurerAdapter not intuitive to the code and add a layer of burden. To be honest, WebFlux's thinking in this area is pretty good and worth changing.