Add Request AuthenticationManagerResolvers

[jzheaux]

Fixes gh-6762

[jzheaux]

@bdemers I remember you saying that you were taking a look at choosing JWT vs Opaque Token based on path. Will you take a look at this PR and see whether it would be helpful for what you are trying to do?

[bdemers]

@jzheaux This is great! I just had a chance to play around with this!

One thing that feels odd is configuring the path matching in two different places.
here:

spring-security/samples/boot/oauth2resourceserver-multitenancy/src/main/java/sample/OAuth2ResourceServerSecurityConfiguration.java

Line 63 in 2a3f03a

.antMatchers("/**/message/**").hasAuthority("SCOPE_message:read")

and again here:

spring-security/samples/boot/oauth2resourceserver-multitenancy/src/main/java/sample/OAuth2ResourceServerSecurityConfiguration.java

Lines 76 to 77 in 2a3f03a

	authenticationManagers.put(new AntPathRequestMatcher("/tenantOne/**"), jwt());
	authenticationManagers.put(new AntPathRequestMatcher("/tenantTwo/**"), opaque());

These types of use-case may not be common enough to worry about that (and the OAuth configs are at the top level of HttpSecurity...)

Any idea of how this type of strategy will play with Boot's autoconfigure classes/properties (security.oauth2.*). For example, currently, you cannot define a jwk.key-set-uri and a token-info-uri for the same provider. (again this might not be a common enough use case currently to worry about just yet)

That said, I'd love to use this as is today :)

[bdemers]

🎉

[bdemers]

@jzheaux I was playing around with this again today, and noticed what the RequestMatchingAuthenticationManagerResolver.setDefaultAuthenticationManager() could do.

That seems to remove my concern about the paths being defined twice.

I could do something like:

LinkedHashMap<RequestMatcher, AuthenticationManager> authenticationManagers = new LinkedHashMap<>();
            authenticationManagers.put(new AntPathRequestMatcher("/opaque/**"), opaque());
            RequestMatchingAuthenticationManagerResolver authenticationManagerResolver = new RequestMatchingAuthenticationManagerResolver(authenticationManagers);
            authenticationManagerResolver.setDefaultAuthenticationManager(jwt());
            return authenticationManagerResolver;

Assuming I'm seeing this correctly, this would (more or less) function the same way as the out of the box JWT Decoding (with some configuration differences). Where all paths are handled by the JWT decoder, except the special handling /opaque/**.

Very cool stuff!

[bdemers]

Woot!!