Remove need for WebSecurityConfigurerAdapter

[eleftherias]

Closes gh-8804

[rwinch]

I also wonder if we should consider deprecating WebSecurityConfigurerAdapter and update the samples? Perhaps that is something for another issue?

[eleftherias]

@rwinch I created gh-8821 to update the samples.

I had not thought about deprecating WebSecurityConfigurerAdapter.
It may come as a surprise to users, since it is such a core part of Spring Security.
Maybe we can consider deprecating it in 5.5, once everyone is familiar with the SecurityFilterChain bean approach.

[rwinch]

If we are going to deprecate it, I'd rather give users more time to update. The deprecation can give instructions on how to migrate (which shouldn't be too painful). We'd likely remove the support next year in 6.0, but certainly no sooner.

[rwinch]

Thanks for the responses. It looks good to me

[jzheaux]

Looks good to me, though I did leave a question inline.

[jzheaux]

What are the consequences of not adding the other shared objects that WebSecurityConfigurerAdapter adds?

[eleftherias]

My understanding is that the WebSecurityConfigurerAdapter adds the additional shared objects because they may be overridden within that class, for example using configure(AuthenticationManagerBuilder auth).
When using the SecurityFilterChain bean, you would need to expose a UserDetailsService bean and I confirmed that the UserDetailsService is used even if it's not explicitly added to the shared objects here.
It was similar for the ContentNegotiationStrategy and AuthenticationTrustResolver.

[imod]

I see the value to use the SecurityFilterChain, but how do I register multiple AuthenticationProvider with this approach?

With the adapter I could simply do:

	@Override
	protected void configure(AuthenticationManagerBuilder auth) throws Exception {
		auth.authenticationProvider(new Provider1());
		auth.authenticationProvider(new Provider2());
		auth.authenticationProvider(new Provider3());
	}