Spring Security is about to deprecate the WebSecurityConfigurerAdapter configuration class

Anyone who has used WebSecurityConfigurerAdapter knows that it is very important for Spring Security , and is in charge of the configuration system of Spring Security . But this class will be abolished soon, you read it right, this class will be marked by @Deprecated in version 5.7, and this class will be removed in the future.

In response to this, netizens shouted, "Learn to learn and you will be abandoned." Since it is about to be deprecated, there must be a transition plan or a new gameplay.

As early as March 2021, wrote an article , which clearly explained the new gameplay. If you read it, you will definitely not learn discarding techniques. Here's the whole set of alternatives all over again, and don't learn outdated techniques.

Version requires Spring Security 5.4.x and above.

Comparison of old and new gameplay of HttpSecurity

Old way of playing:

@Configuration
static class SecurityConfig extends WebSecurityConfigurerAdapter {
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .antMatcher("/**")
            .authorizeRequests(authorize -> authorize
                    .anyRequest().authenticated()
            );
    }
}

New gameplay:

@Bean
SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    return http
            .antMatcher("/**")
            .authorizeRequests(authorize -> authorize
                    .anyRequest().authenticated()
            )
            .build();
}

Check out this article for principles.

Comparison of old and new ways of WebSecurity

Use WebSecurity.ignoring() ignore some URL requests, these requests will be ignored by Spring Security , which means that these URLs will be vulnerable to CSRF, XSS, Clickjacking, etc. The following examples are for demonstration only and should not be used in a production environment. Did you learn it again?

Old way of playing:

@Configuration
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {

    @Override
    public void configure(WebSecurity web) {
        // 仅仅作为演示
        web.ignoring().antMatchers("/ignore1", "/ignore2");
    }

}

New gameplay:

@Configuration
public class SecurityConfiguration {

    @Bean
    public WebSecurityCustomizer webSecurityCustomizer() {
        // 仅仅作为演示
        return (web) -> web.ignoring().antMatchers("/ignore1", "/ignore2");
    }

}

If you need to ignore URLs, please consider doing so via HttpSecurity.authorizeHttpRequests of permitAll .

Comparison of the old and new gameplay of AuthenticationManager

AuthenticationManager configuration is mainly divided into global (Global), local (Local).

old game

@Configuration
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.jdbcAuthentication();
    }
}

The above is the local configuration opened by WebSecurityConfigurerAdapter . To open the global configuration, you need to override its authenticationManagerBean() method and mark it as a Bean:

       @Bean(name name="myAuthenticationManager")
       @Override
       public AuthenticationManager authenticationManagerBean() throws Exception {
           return super.authenticationManagerBean();
       }

new gameplay

Local configuration is achieved through HttpSecurity.authenticationManager :

@Configuration
public class SecurityConfiguration {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests((authz) -> authz
                .anyRequest().authenticated()
            )
            .httpBasic(withDefaults())
            .authenticationManager(new CustomAuthenticationManager());
    }

}

The global configuration gets rid of the dependence on the WebSecurityConfigurerAdapter.authenticationManagerBean() method, and only needs to define a bean of type AuthenticationManager :

    @Bean
    AuthenticationManager ldapAuthenticationManager(
            BaseLdapPathContextSource contextSource) {
        LdapBindAuthenticationManagerFactory factory = 
            new LdapBindAuthenticationManagerFactory(contextSource);
        factory.setUserDnPatterns("uid={0},ou=people");
        factory.setUserDetailsContextMapper(new PersonContextMapper());
        return factory.createAuthenticationManager();
    }

Of course, you can also modify AuthenticationManagerBuilder by customizing GlobalAuthenticationConfigurerAdapter and injecting Spring IoC . There is no limit to the number, but pay attention to the sorting problem. Related mind maps:

finally

Many technical solutions are not directly changed. There will be a process of change. As long as you keep up with the changes, there will be no changes.

Follow the official account: Felordcn for more information

Personal Blog: https://felord.cn