Disabling credentials erasure on custom AuthenticationManager is not working

[kmartin88]

Describe the bug
In the documentation there is an example on how to customize the AuthenticationManager:
https://docs.spring.io/spring-security/reference/servlet/authentication/passwords/index.html#customize-global-authentication-manager (below "Publish AuthenticationManager bean for Spring Security").
Even though eraseCredentialsAfterAuthentication is set to false, the credentials get erased. They seem to get erased by another ProviderManager which has an AnonymousAuthenticationProvider.

To Reproduce
Create an empty Spring Boot Project with Spring Security and Spring Web MVC, create a @RestController and a SecurityConfig like in the example. The RestController should have a method which autowires the Authentication and returns the credentials of this Authentication object. Then you call the controller with user credentials and see that the credentials are empty/null.

Expected behavior
The password of the user should be returned when calling the controller.

[sjohnr]

@kmartin88, thank you for reaching out!

Create an empty Spring Boot Project with Spring Security and Spring Web MVC, create a @RestController and a SecurityConfig like in the example. The RestController should have a method which autowires the Authentication and returns the credentials of this Authentication object. Then you call the controller with user credentials and see that the credentials are empty/null.

Can you please provide more information about the security configuration and rest controller? It would be helpful if you could provide actual code, so there is no chance of misunderstanding.

Currently, I am not seeing information about how you authenticate prior to calling an endpoint, and whether the endpoint you are calling is permitAll() or authenticated() in authorizeHttpRequests(), which I think would be an important detail for reproducing what you're seeing. Please provide full steps to reproduce the issue.

[kmartin88]

@sjohnr
Hi, I created a sample project: https://github.com/kmartin88/demo
I hope this clarifies what I mean.

[sjohnr]

Thanks for the sample, @kmartin88! That does indeed help clarify your situation. I do see what the issue is so let me explain that first:

Spring Security has a specific order in which it checks for beans that can be used to construct an AuthenticationProvider and/or AuthenticationManager.

1. First, it looks to see if there is a unique AuthenticationProvider published by your application as a bean. If so, this is added to a list used to build an internal AuthenticationManager.
2. Second, it looks to see if there is a unique UserDetailsService published by your application as a bean. If so, this is used to build a DaoAuthenticationProvider, which is then added to a list used to build an internal AuthenticationManager.
3. Finally, if neither of the above are found (or there are multiple beans to choose from, which is non-unique) it looks to see if there is a unique or @Primary AuthenticationManager published by your application as a bean. If so, this is directly used as the internal AuthenticationManager (in addition to being available for your application as a @Bean.

The reason this ordering of checks is used is historical in Spring Security, so we probably couldn't switch the order to be more intuitive or else risk breaking applications relying on this order. What I believe you are hoping for in this case based on your sample is that you fall into the third (3) case. Unfortunately, you are falling into the second (2) case because you have published a UserDetailsService @Bean. Here is what the docs mention in context (emphasis added):

Publish an AuthenticationManager bean

A fairly common requirement is publishing an AuthenticationManager bean to allow for custom authentication, such as in a @Service or Spring MVC @Controller. For example, you may want to authenticate users via a REST API instead of using Form Login.

In fact, in your sample you are using a built-in authentication mechanism (e.g. HTTP Basic or Form Login).

It could be that the documentation should be modified to suggest a configuration that doesn't fall into the second case. However, I wonder if the documentation needs to be improved in some way to make this clearer or if this is simply something you missed when reading the documentation and modifying the code from there? I feel the current example and text in the docs make the use case fairly clear, but I imagine it could be confusing if the code is modified from there. Can you provide some feedback on this and whether you find the docs clear or confusing and in need of improvement?

[kmartin88]

@sjohnr Thanks for the explanation!

Even if I don't publish a UserDetailsService bean I still see the same effect in my test case. So if I do it like this:

@Bean
public AuthenticationManager authenticationManager(PasswordEncoder passwordEncoder) {
        UserDetails userDetails = User.withDefaultPasswordEncoder()
                .username("user")
                .password("password")
                .roles("USER")
                .build();

        InMemoryUserDetailsManager inMemoryUserDetailsManager = new InMemoryUserDetailsManager(userDetails);
        DaoAuthenticationProvider authenticationProvider = new DaoAuthenticationProvider();
        authenticationProvider.setUserDetailsService(inMemoryUserDetailsManager);
        authenticationProvider.setPasswordEncoder(passwordEncoder);

        ProviderManager providerManager = new ProviderManager(authenticationProvider);
        providerManager.setEraseCredentialsAfterAuthentication(false);

        return providerManager;
}

and remove the UserDetailsService bean in the SecurityConfig, the credentials are still erased in the end.

As to if I find the documentation confusing - I guess so, yes. So first it tells me I can publish an AuthenticationManager bean to be able to use it directly in a RestController.
But then it says:

Normally, Spring Security builds an AuthenticationManager internally composed of a DaoAuthenticationProvider for username/password authentication. In certain cases, it may still be desired to customize the instance of AuthenticationManager used by Spring Security. For example, you may need to simply disable credential erasure for cached users.
The recommended way to do this is to simply publish your own AuthenticationManager bean, and Spring Security will use it. You can publish an AuthenticationManager using the following configuration:

Which sounds to me like it would be the way to go if I need to disable the credentials erasure regardless of how I use the AuthenticationManager.

The following:

Alternatively, you can take advantage of the fact that the AuthenticationManagerBuilder used to build Spring Security’s global AuthenticationManager is published as a bean. You can configure the builder as follows:

suggests (to me at least) that the following example is doing the same thing and both examples are interchangeable.

What I really want to accomplish is (as real life examples always are) a bit more complex. We have several SecurityFilterChains and depending on a configuration file we have two authentication mechanisms out of 4 in total which should be used globally. Currently, we are doing it like this:

@Autowired
public void configureAuthenticationManagerBuilder(AuthenticationManagerBuilder authenticationManagerBuilder) throws Exception {
        authenticationManagerBuilder.eraseCredentials(false);

        if (isFirstAuthMode()) {
            configureFirstAuthentication(authenticationManagerBuilder); //this calls ldapAuthentication() on the builder and configures the resulting configurer
        } else if (isSecondAuthMode()) {
            configureSecondAuthentication(authenticationManagerBuilder); //this creates a new instance of an AuthenticationProvider and adds it via authenticationProvider() to the builder
        } else if (isThirdAuthMode()) {
            configureThirdAuthentication(authenticationManagerBuilder); //this creates a new instance of an AuthenticationProvider and adds it via authenticationProvider() to the builder
        }

        addDefaultAuthentication(authenticationManagerBuilder); //this creates a new instance of an AuthenticationProvider and adds it via authenticationProvider() to the builder
}

and this is working fine. However, when looking at several examples on how to do it since Spring Security 6, it seems to me that configuring AuthenticationManagers like this is not the intended way.