Why should we use UserDetailsService bean instead of configureGlobal method

[bangseongbeom]

Summary

#7283 changed from configureGlobal to UserDetailsService by @eleftherias.

I'm wondering why UserDetailsService bean is preferred to inMemoryAuthentication method.

[eleftherias]

@bangseongbeom Previously, our sample was specifying the AuthenticationManager used to authenticate users.
However, in the sample application we were not using a custom authentication mechanism. Therefore, we can simply expose a UserDetailsService that looks up user data, and rely on the DaoAuthenticationProvider to authenticate users.
There is more information on the UserDetailsService in the documentation, specifically take a look at the note at the end of the section.

[eleftherias]

@bangseongbeom Since this is more of a question rather than an issue with Spring Security, I will go ahead and close it. Feel free to ask any followup questions in this thread.

[bangseongbeom]

@eleftherias

Both ways use InMemoryAuthenticationManager and DaoAuthenticationProvider:

1. Expose an InMemoryUserDetailsManager as a bean is same that expose a UserDetailsService as a bean. DaoAuthenticationProvider will be created internally.

2. inMemoryAuthentication() method creates an InMemoryUserDetailsManagerConfigurer instance. In this class, it creates an InMemoryUserDetailsManager:

InMemoryUserDetailsManagerConfigurer.java:

super(new InMemoryUserDetailsManager(new ArrayList<>()));

And it's ancestor class, AbstractDaoAuthenticationConfigurer, which creates DaoAuthenticationProvider:

AbstractDaoAuthenticationConfigurer.java:

private DaoAuthenticationProvider provider = new DaoAuthenticationProvider();

---

If your main purpose is not JDBC nor in-memory, but just a custom authentication mechanism, I agree that exposing a custom UserDetailsService with relying on DaoAuthenticationProvider is a reasonable choice.

But your main purpose is JDBC or in-memory, rather than expose InMemoryUserDetailsManager as a UserDetailsService bean, just relying on AuthenticationManagerBuilder is more natural and elegant way.

Because AuthenticationManagerBuilder is provided as Spring configuration system. Spring configuration system has two ways (Java, XML) to configure Spring. AuthenticationManagerBuilder corresponds to <authentication-manager> in XML, inMemoryAuthentication() corresponds to <user-service>. It's more Spring-ful.

---

And it's not natural that in-memory authentication is provided to expose InMemoryUserDetailsManager as a UserDetailsService bean, and JDBC authentication is not. Why not expose JdbcUserDetailsManager as a UserDetailsService bean for JDBC?

[eleftherias]

@bangseongbeom you can still use a custom AuthenticationManager if you choose.

The helloworld sample application is intended to demonstrate a simple security configuration. Many applications using Spring Security authenticate using username/password. For those cases, a UserDetailsService is all that Spring Security requires to authenticate.

The purpose of the helloworld sample is not to prescribe a way of doing in-memory authentication, but rather to show a pattern that many applications can apply.

There are other samples, such as the one for multitenancy where an AuthenticationManager is used instead.