Default user password shouldn't be logged if OAuth2 is being used

[mbhave]

No description provided.

[Quantas]

I also noticed this "regression" when switching from 2.0.0M4 to 2.0.0M5 when not using OAuth but when using Pre Authenticated security such as SiteMinder.

[mbhave]

We can make the bean lazy once this is taken care of.

[snicoll]

@mbhave I was discussing this issue with @rwinch recently and he was mentioning he was expecting zero change in Spring Boot. Can we please double check we're on the same page here? (dunno what you mean with the @Lazy part). Thanks!

[mbhave]

I think we'd still need the bean to be lazy, so that it only logs the password if InMemoryUserDetailsManager is being used. Unless I'm missing something @rwinch?

[rwinch]

@mbhave You are right. It will need to be lazy (I missed that it wasn't lazy already). @jgrandja is looking into it now so we will find out the details soon

[wilkinsona]

@rwinch @jgrandja Given that spring-projects/spring-security#4795 has been declined, can you please describe how we should achieve our goal here?

[mbhave]

I think the suggestion is to add

@ConditionalOnMissingBean(type="org.springframework.security.oauth2.client.registration.ClientRegistrationRepository")

to InMemoryUserDetailsManager.

I think it contradicts this slightly, specifically,

http.formLogin() and http.oauth2Login() can be configured at the same time and the UserDetailsService bean would be used when the user logs in via http.formLogin()

Since these two modes of authentication can be used together, it makes me wonder if not creating the InMemoryUserDetailsManager bean when there is a ClientRegistrationRepository is the right call.

[rwinch]

@mbhave You are right it does contradict that statement. However, determining when to create a UserDetailsService has always been an educated guess. Unfortuantely, there is no way around making an educated guess until SPR-13779 is solved and then we integrate something into Spring Security to leverage that.

Other examples of where creating the UserDetailsService is unnecessary are when a user might leverage Spring Security for just HTTP headers. Yet another example is if the user performs authentication using a third party library that simply sets the SecurityContextHolder without using an AuthenticationManager. There are plenty of reasons that this is not a perfect answer. If we need a perfect answer for when UserDetailsService is created, then we probably cannot create one at all (at least not until SPR-13779 is solved).

In the end we want to ensure that the bean is not even defined if the user does not need it. Therefore, the previous approaches outlined of using @Lazy and Spring Security not looking it up are not sufficient.