Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Request AuthenticationManagerResolvers #7366

Merged
merged 1 commit into from Jan 26, 2022

Conversation

jzheaux
Copy link
Contributor

@jzheaux jzheaux commented Sep 5, 2019

Fixes gh-6762

@jzheaux
Copy link
Contributor Author

jzheaux commented Feb 27, 2020

@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
Copy link
Contributor

bdemers commented Mar 2, 2020

@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:


and again here:
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 approved these changes Mar 2, 2020
Copy link
Contributor

@bdemers bdemers left a comment

🎉

@bdemers
Copy link
Contributor

bdemers commented Apr 13, 2020

@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!

@jzheaux jzheaux changed the base branch from main to 5.7.x Jan 25, 2022
@jzheaux jzheaux merged commit 9baf113 into spring-projects:5.7.x Jan 26, 2022
12 checks passed
@jzheaux jzheaux deleted the gh-6762 branch Jan 26, 2022
@jzheaux jzheaux added in: web status: duplicate type: enhancement labels Jan 26, 2022
@jzheaux jzheaux added this to the 5.7.0-M2 milestone Jan 26, 2022
@bdemers
Copy link
Contributor

bdemers commented Jan 27, 2022

Woot!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web status: duplicate type: enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants