Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device.
Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
File(s):conf/relying-party.xml, conf/oidc.properties Format: Native Spring, Spring Properties
Overview
The OIDC.UserInfo profile configuration bean enables support for the OIDC UserInfo endpoint, which relies on the access tokens issued by the Authorization endpoint to retrieve the subject's claims. It is analagous to the (very old) Shibboleth practice of relying on Attribute Queries to query for user attributes instead of passing them over the front channel, but with weaker security guarantees. It does not support a lot of options because it is required to rely on the bearer access token for security.
Configuration
The most typical options used are described in more detail below, but not every obscure option is discussed. See the javadoc for all of the possible configuration options for this profile (note that some of them are inherited from parent classes).
Virtually all the configuration options below can be set via two different properties: a static property that explicitly sets the value to use and a lookup strategy or predicate property that takes a Function or Predicate and returns the value to use. The dynamic property is generally named "propertyNamePredicate" or "propertyNameLookupStrategy" for Boolean- and non-Boolean-valued properties respectively.
Bean named shibboleth.oidc.DefaultSecurityConfiguration
An object containing all of the default security-related objects needed for peer authentication and encryption. See OIDCSecurityConfiguration for complete details.
specify an alternate signing or decryption key to use
control signing or encryption algorithms
The two interceptor lists allow the much less commonly used profile interceptor injection points to be used. This is largely a Java-based way of doing very low-level sorts of “message rewriting” hackery that might otherwise be impossible to pull off. One use case for the inbound side might be picking up non-standard parameters in a request.
The DPoP proof is automatically required whenever any DPoP access token is presented to the userinfo endpoint.
Options related to DPoP proof validation:
Name
Type
Default
Description
Name
Type
Default
Description
requireDpopProof 4.2
Boolean
false
A flag for requiring the DPoP proof JWT in the profile. If the proof exists in the request, it’s always validated.
dpopProofClaimsValidator 4.2
ClaimsValidator
Beans named DefaultDPoPProofClaimsValidator for PAR/token and DefaultDPoPWithAthProofClaimsValidator for others (involving access token validation)
The claims validation configuration used for validating the payload contents of the DPoP proof JWTs. The default values follows the RFC: the latter also verifying the access token hash claim.
dpopProofSignatureValidationConfiguration 4.2
BasicSignatureValidationConfiguration
Bean named DPoPSignatureValidationConfiguration
The bean used for defining the signature validation configuration used for validating DPoP proof signatures.
dpopProofNonceGenerator 4.2
Function< ProfileRequestContext, String>
Bean named DefaultOAuth2DPoPNonceGenerator
The bean used for defining the function used for generating nonce used within DPoP proofs. Null value (#{null}) means that nonces are disabled.
If modified to a non-null value, the dpopProofClaimsValidatorneeds to be modified to be able to validate the custom nonce value.
DPoP proof claims set validation
The idp.policy.messageLifetimeand idp.policy.clockSkew properties are exploited when validating the iat -claim.
The lifetime for the replay cache record is taken from the exp -claim if it exists in the DPoP proof claims set. If not, the property idp.oauth2.dpop.replayCacheLifetime(defaults to 5 minutes) is exploited. The record key is taken from the jti claim.
In order to guard against memory exhaustion attacks, the jti values longer than 64 characters are hashed with SHA-256 before using them as the replay record key. The maximum record lifetime may also be set via idp.oauth2.dpop.maxReplayCacheLifetime-property, which defaults to 5 minutes.
Nonces
If the dpopProofNonceGenerator option has a value, the bean is used for generating nonce values to be used within DPoP proof JWTs. The default value points to an implementation that generates relying party -specific values that are valid for 5 minutes, customisable via idp.oauth2.dpop.nonceLifetime-property. The default implementation exploits the data sealer for encrypting the nonce value into an opaque string.
The default value for dpopProofClaimsValidator contains a claims validator that is activated whenever dpopProofNonceGenerator option has a value.
Note that any browser-based client applications using CORS may require the DPoP-Nonce to be included in the Access-Control-Expose-Headers response header list value. The page https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199501090 describes some alternatives for handling CORS preflight requests. For instance the Spring CORS configuration supports p:exposedHeaders="DPoP-Nonce"as a way for satisfying that requirement.
Options specific to the OIDC UserInfo flow:
Name
Type
Description
Name
Type
Description
resolveAttributes 3.1
Boolean
Whether to run the attribute resolution/filtering step
deniedUserInfoAttributes
Set<String>
Specifies IdPAttributes to omit from UserInfo token
encryptionOptional 3.4
Boolean
Whether to automatically disable encryption if the relying party does not possess a suitable key (defaults to true)
unregisteredClientPolicy 4.0
Map<String, UnregisteredClientPolicy>
The policy used to verify unverified clients when this profile is enabled in the unverified RP config.
The following property can be used to globally control the last setting above:
idp.oidc.deniedUserInfoAttributes
This option relates to "claims splitting" and override the typical processing rules for when to insert claims into particular tokens. Typically most "data" is omitted from the front-channel ID token unless no authorization code is being issued, with the claims only accessed via the UserInfo endpoint. This setting, together with the same option on the OIDC.SSO profile bean, prevent attributes from appearing in the UserInfo response.