Removed some duplication by delegating to
DefaultOAuth2AuthenticatedPrincipal
Changed order of listed interfaces to satisfy compiler issue. When
listed with OAuth2AuthenticatedPrincipal first, then
OAuth2ResourceServerBeanDefinitionParserTests would fail to import
OpaqueTokenBeanDefinitionParser. Switching
OAuth2AuthenticatedPrincipal with OAuth2IntrospectionClaimAccessor
resolved the compilation issue.
Issue gh-6489
In order to simplify retrieving of OAuth 2.0 Introspection specific
attributes, OAuth2IntrospectionClaimAccessor interface was introduced
and also new OAuth2AuthenticatedPrincipal implementing this new
interface (OAuth2IntrospectionAuthenticatedPrincipal).
Also DefaultOAuth2AuthenticatedPrincipal was replaced by
OAuth2IntrospectionAuthenticatedPrincipal in cases where OAuth 2.0
Introspection is performed (NimbusOpaqueTokenIntrospector,
NimbusReactiveOpaqueTokenIntrospector).
DefaultOAuth2AuthenticatedPrincipal can be still used by applications
that introspected the token without OAuth 2.0 Introspection.
OAuth2IntrospectionAuthenticatedPrincipal will also be used as a
default principal in tests where request is post-processed/mutated
by OpaqueTokenRequestPostProcessor/OpaqueTokenMutator.
Closes gh-6489
Before:
1. SimpleSavedRequest#getMethod returned null
2. SimpleSavedRequest(SavedRequest request) constructor did not set the method field from request
After:
1. SimpleSavedRequest#getMethod returns method property value
2. SimpleSavedRequest(SavedRequest request) constructor sets the method field from request
Closes gh-8675
Extends all existing builders in NimbusJwtDecoder and NimbusReactiveJwtDecoder with a
post-processor hook to apply changes on the JWTProcessor used for token verification.
Test cases added show how this is used to configure the JWTProcessor to allow additional
JWT typ headers.
Closes gh-8730
- The test intentionally points to a non-existent LDAP server; on
some machines, this will hang indefinitely without a specified
timeout.
Issue gh-2884
While using the request's "isSecure" flag is a reasonable default, when webapps sit behind firewalls, sometimes the firewall does the SSL, and the traffic between the firewall and the app is plain HTTP (not HTTPS). In this case the "isSecure" flag on the request is always false, but we still want th XSRF-TOKEN cookie to be secure (the firewall forwards all cookies to the app, and the browser sends the secure cookie to the firewall).
It would be nice if we could configure the desired value for the secure flag of the cookie, just like we can configure the value for the httpOnly flag of the cookie.
Josh Cummings
kothasa
Joe Grandja
Jay Bryant
Eleftheria Stein
Hurelhuyag
Dávid Kováč
Roman Sydorov
wangsong
Rob Winch
Zeeshan Adnan
Peer Schönhusen
Benjamin Bargeton
Heinz Wittig
Jan Oopkaup
Сергей Цыпанов
michal