HttpSecurity, WebSecurity and AuthenticationManagerBuilder

Question

Could anyone explain when to override configure(HttpSecurity), configure(WebSecurity) and configure(AuthenticationManagerBuilder)?

Hendecagon

Answer 1

configure(AuthenticationManagerBuilder) is used to establish an authentication mechanism by allowing AuthenticationProviders to be added easily: e.g. The following defines the in-memory authentication with the in-built 'user' and 'admin' logins.

public void configure(AuthenticationManagerBuilder auth) {
    auth
        .inMemoryAuthentication()
        .withUser("user")
        .password("password")
        .roles("USER")
    .and()
        .withUser("admin")
        .password("password")
        .roles("ADMIN","USER");
}

configure(HttpSecurity) allows configuration of web based security at a resource level, based on a selection match - e.g. The example below restricts the URLs that start with /admin/ to users that have ADMIN role, and declares that any other URLs need to be successfully authenticated.

protected void configure(HttpSecurity http) throws Exception {
    http
        .authorizeRequests()
        .antMatchers("/admin/**").hasRole("ADMIN")
        .anyRequest().authenticated()
}

configure(WebSecurity) is used for configuration settings that impact global security (ignore resources, set debug mode, reject requests by implementing a custom firewall definition). For example, the following method would cause any request that starts with /resources/ to be ignored for authentication purposes.

public void configure(WebSecurity web) throws Exception {
    web
        .ignoring()
        .antMatchers("/resources/**");
}

You can refer to the following link for more information Spring Security Java Config Preview: Web Security

Tailing

Nice answer Nick. With spring-security-config-5.0.3 (which comes with spring-boot 2.0.0), I couldn't find the method http.authorizeUrls(), maybe it got renamed to http.authorizeRequests() some while ago. – Hierolatry

I know this is old, but what's the best practice here? I have found examples of configure(HttpSecurity http) method implementations invoking http.antMatchers("/foo").permitAll()" which seems equivalent to invoking web.ignoring().antMatchers("/foo") in the configure(WebSecurity web) method. – Williwaw

great answer. I am wondering if we ever need to call permitAll on HttpSecurity? Can't we just ignore all open url's like /register or /login using WebSecurity? Then why does all tutorials or answers use HttpSecurity.permitAll for /register and /login but WebSecurity.ingore for /publics of /resources ? – – Saurischian

Answer 2

General use of WebSecurity ignoring() method omits Spring Security and none of Spring Security’s features will be available. WebSecurity is based above HttpSecurity.

@Override
public void configure(WebSecurity web) throws Exception {
    web
        .ignoring()
        .antMatchers("/resources/**")
        .antMatchers("/publics/**");
}

@Override
protected void configure(HttpSecurity http) throws Exception {
    http
        .authorizeRequests()
        .antMatchers("/admin/**").hasRole("ADMIN")
        .antMatchers("/publics/**").hasRole("USER") // no effect
        .anyRequest().authenticated();
}

WebSecurity in the above example lets Spring ignore /resources/** and /publics/**. Therefore the .antMatchers("/publics/**").hasRole("USER") in HttpSecurity is unconsidered.

This will omit the request pattern from the security filter chain entirely. Note that anything matching this path will then have no authentication or authorization services applied and will be freely accessible.

configure(HttpSecurity) allows configuration of web-based security at a resource level, based on a selection match - e.g. The example below restricts the URLs that start with /admin/ to users that have ADMIN role, and declares that any other URLs need to be successfully authenticated.

configure(WebSecurity) is used for configuration settings that impact global security (ignore resources, set debug mode, reject requests by implementing a custom firewall definition). For example, the following method would cause any request that starts with /resources/ to be ignored for authentication purposes.

AuthenticationManagerBuilder
extends AbstractConfiguredSecurityBuilder<AuthenticationManager,AuthenticationManagerBuilder>
implements ProviderManagerBuilder<AuthenticationManagerBuilder>

SecurityBuilder used to create an AuthenticationManager. Allows for easily building in memory authentication, LDAP authentication, JDBC based authentication, adding UserDetailsService, and adding AuthenticationProvider's.

@Override
     protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.inMemoryAuthentication().withUser("user").password("password").roles("USER"); 
        auth.userDetailsService(customUserDetailService).passwordEncoder(new BCryptPasswordEncoder());
     }

Ranch

great answer. I am wondering if we ever need to call permitAll on HttpSecurity? Can't we just ignore all open url's like /register or /login using WebSecurity? Then why does all tutorials or answers use HttpSecurity.permitAll for /register and /login but WebSecurity.ingore for /publics of /resources ? – Saurischian