Spring-boot: Default user password logged even if AuthenticationManagerBuilder is configured

[snicoll]

I have the following configuration (for a simple demo) using Spring Boot 2.0.1.RELEASE:

@Configuration
static class SecurityConfig extends GlobalAuthenticationConfigurerAdapter {

    @Override
    public void init(AuthenticationManagerBuilder auth) throws Exception {
        auth.inMemoryAuthentication()
                .withUser("hero").password("{noop}hero").roles("HERO", "USER").and()
                .withUser("user").password("{noop}user").roles("USER");
    }

}

The configuration works fine and my users are recognized but I can see the following in the logs:

Using generated security password: 01e94f0f-b575-46e1-96f6-f35f4027432a

Same with

@Configuration
static class SecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.inMemoryAuthentication()
                .withUser("hero").password("{noop}hero").roles("HERO", "USER").and()
                .withUser("user").password("{noop}user").roles("USER");
    }

}

[mbhave]

@snicoll Spring Security 5 is moving away from AuthenticationManagerBuilder which is why Spring Boot's auto-configuration only looks for the presence of a UserDetailsService, AuthenticationProvider or AuthenticationManager bean before it backs off from creating the in-memory user.

[rajadilipkolli]

@mbhave can this be documented? As I am struggling with same issue from past one week.

[mbhave]

I've added a note in the migration wiki.

[snicoll]

@mbhave thanks for the feedback. so SampleMethodSecurityApplication is the recommended way of doing things now?

Spring Security 5 is moving away from AuthenticationManagerBuilder

Oh really? That's not very obvious. Do I get this right that if you want to configure users and http security you can't do that in the same area now? (I am specifically asking because non deprecated hook points in Spring Security definitely allows you do that).

What would be the recommended way then? Perhaps we should make sure the migration guide has a link to that

[mbhave]

The recommended way to configure users is to use a UserDetailsService bean which is what we do in all our samples.

/cc @rwinch

[mbhave]

Spring Security doesn't request the UserDetailsService if something else is explicitly provided. We can make the UserDetailsService bean lazy and prevent the default password from being logged.

[mbhave]

Making the bean lazy won't work here because of this.

[philwebb]

@mbhave I have a possible fix but I'm very unsure about it. Could you review this branch? If you think it'll work, we should also get Rob to review.

[mbhave]

Actually, it turns out that making the bean @Lazy is sufficient.