File(s): conf/relying-party.xml, conf/oidc.properties
Format: Native Spring, Spring Properties
Overview
The OIDC.SSO profile configuration bean enables support for the OIDC Authorization and OAuth 2 Token endpoints, which includes the browser-based flow that actually issues token(s) and/or authorization codes to resolve into tokens, and the flow to resolve the codes. It has the most configurability compared to the other profiles since it includes both OIDC-related features and all the standard authentication-related controls/options supported by the IdP. Many of the authentication settings only apply to the Authorization half.
In V3.1+ of the plugin, the behavior of the Authorization and Token endpoints has been optionally split into separate profile configurations, in order to support additional OAuth use cases specific to the token endpoint and to allow for more configuration flexibility. For backward compatibility, the presence of this bean (the Authorization configuration) but the absence of the new Token configuration bean, implies enablement of the Token configuration with the options configured on this bean, supporting the previously supported OIDC grant types. In other words, by default nothing changes and no new features are involved. If the OAUTH2.Token bean is added in a RelyingParty definition, its presence supersedes this compatibility, and the behavior of the Token endpoint is controlled by the new bean.
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.
In V3.3+ of the plugin, the support for plain OAuth2 authorization requests can be controlled via idp.oauth2.requireAuthenticationRequestPredicate property. In order the default behaviour as before V3.3, the property value defaults to a predicate shibboleth.Conditions.TRUE, meaning that OIDC authentication requests are always required. One principal requirement for an OIDC authentication request is to include openid in the requested scopes. If the predicate is configured to return false, then non-OIDC requests are enabled. For these RPs, one must configure at least one audience in the RP metadata for controlling the target audience of the access tokens. See audience claim in OAuthRPMetadataProfile .
Common
Options common to most/all profiles:
Name | Type | Default | Description |
|---|
securityConfiguration | SecurityConfiguration | Bean named shibboleth.DefaultSecurityConfiguration | An object containing all of the default security-related objects needed for peer authentication and encryption. See SecurityConfiguration for complete details. |
disallowedFeatures | Integer | 0 | A bitmask of features to disallow, the mask values being specific to individual profiles |
inboundInterceptorFlows | List<String> | | Ordered list of profile interceptor flows to run prior to message processing |
outboundInterceptorFlows | List<String> | | Ordered list of profile interceptor flows to run prior to outbound message handling |
Guidance
Modifying the security configuration is usually done to:
specify an alternate signing or decryption key to use
control signing or encryption algorithms (but for metadata you control, it's advisable to control algorithms by using an extension to specify supported 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 SAML request.
Authentication
Options common to profiles that perform authentication:
Name | Type | Default | Description |
|---|
postAuthenticationFlows | List<String> |
| Ordered list of profile interceptor flows to run after successful authentication |
defaultAuthenticationMethods | List<Principal> |
| Ordered list of Java Principals to be used to select appropriate login flow(s) to attempt, in the event that a relying party does not signal a preference. See AuthenticationFlowSelection. |
forceAuthn | Boolean | false | Disallows use (or reuse) of authentication results and login flows that don't provide a real-time proof of user presence in the login process |
proxyCount | Non-Negative Integer |
| Limits use of proxying either to service providers downstream or when requesting authentication from identity providers upstream. This will generally depend on whether a particular protocol supports the feature. |
Guidance
The postAuthenticationFlows property is used to apply special processing to requests, such as attribute release consent, password expiration warnings, authorization checks, or other custom processing.
Examples of postAuthenticationFlows property
Examples of postAuthenticationFlows property
<bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty">
<!-- Add consent to Shibboleth SSO profile. -->
<bean parent="Shibboleth.SSO" p:postAuthenticationFlows="attribute-release" />
<!-- Add consent, followed by expiring password check, to SAML 2 SSO profile. -->
<bean parent="SAML2.SSO" p:postAuthenticationFlows="#{{'attribute-release', 'expiring-password'}}" />
<!-- Return interceptors from a function bean (not shown). -->
<bean parent="Shibboleth.SSO" p:postAuthenticationFlowsLookupStrategy-ref="InterceptorsFunction" />
</bean>
With the increased use of multi-factor authentication, it is more common to find RPs that can specify authentication requirements, but there are still many cases, particular with commercial services, in which it becomes necessary to force the use of specific login methods. This can be achieved using the defaultAuthenticationMethods property by specifying one or more corresponding Principals to trigger the use of stronger methods.
Note that you must also prevent a malicious actor from overriding this preference for a SAML 2.0 SP by manufacturing a request, via one of two means:
For a SAML 2.0 SP that can sign its requests, its metadata can be modified with the AuthnRequestsSigned flag to indicate that its requests must be signed.
Alternatively, the disallowedFeatures property may be set with the SAML2.SSO.FEATURE_AUTHNCONTEXT bean to block use of the SAML 2.0 <RequestedAuthnContext> feature.
At present, no other authentication profiles support a feature capable of requesting the authentication method.
Examples of defaultAuthenticationMethods property
Examples of defaultAuthenticationMethods property
<!-- NOTE: these example.org constants are examples and are not suitable for real use. -->
<bean id="MFASAML2Principal" parent="shibboleth.SAML2AuthnContextClassRef"
c:_0="http://example.org/ac/classes/mfa" />
<bean id="MFASAML1Principal" parent="shibboleth.SAML1AuthenticationMethod"
c:_0="http://example.org/ac/classes/mfa" />
<bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty">
<!-- Require MFA with Shibboleth SSO profile. -->
<bean parent="Shibboleth.SSO">
<property name="defaultAuthenticationMethods">
<list>
<ref bean="MFASAML1Principal" />
</list>
</property>
</bean>
<!-- Require MFA with SAML 2 SSO profile. -->
<bean parent="SAML2.SSO" p:disallowedFeatures-ref="SAML2.SSO.FEATURE_AUTHNCONTEXT">
<property name="defaultAuthenticationMethods">
<list>
<ref bean="MFASAML2Principal" />
</list>
</property>
</bean>
</bean>
Flow Types
Options common to OP profiles with OIDC flow settings:
Name | Type | Default | Description |
|---|
authorizationCodeFlowEnabled | Boolean | true | Whether to enable the authorization code flow |
hybridFlowEnabled | Boolean | true | Whether to enable the hybrid flow |
implicitFlowEnabled | Boolean | true | Whether to enable the implicit flow |
refreshTokensEnabled | Boolean | true | Whether to enable refresh token support |
Client Authentication
Options common to OP profiles that support client authentication:
Name | Type | Default | Description |
|---|
tokenEndpointAuthMethods | Collection<String> | client_secret_basic,
client_secret_post,
client_secret_jwt,
private_key_jwt | Enabled endpoint client authentication methods |
unregisteredClientPolicy 4.0 | Map<String, UnregisteredClientPolicy> | See wiki page | The policy used to verify unverified clients when this profile is enabled in the unverified RP config |
For convenience, this is also controllable globally via the idp.oidc.tokenEndpointAuthMethods property.
Since OP v3.4, the JWT-based client authentication methods (client_secret_jwt and private_key_jwt) accepts any of the following three audiences:
OP issuer value (profile responder ID)
The token flow endpoint URL value (even for introspection and revocation endpoints)
The flow endpoint URL value
Prior to V3.4, only the flow endpoint URL value could be used. Any custom bean for validating the audience can be set via idp.oauth2.jwtAuth.audienceValidator -property.
For convenience, this is also controllable globally via the idp.oidc.tokenEndpointAuthMethods property.
Profile-Specific
Options specific to the OIDC Authorization flow:
Name | Type | Default | Description |
|---|
iDTokenLifetime | Duration | PT1H | Lifetime of ID token |
accessTokenLifetime | Duration | PT10M | Lifetime of access token If you customise this, make sure to set the revocation cache lifetime (See Replay and Revocation -section later at this page) to at least match with this. Also check refreshTokenTimeout and use which ever is longer. |
authorizeCodeLifetime | Duration | PT5M | Lifetime of authorization code |
refreshTokenLifetime
| Duration
| PT2H
| DEPRECATED Lifetime of refresh token |
refreshTokenTimeout 3.4 | Duration | PT2H | Lifetime of a single refresh token issued to client, which acts as a timeout on the ability to refresh any tokens. If you customise this, make sure to set the revocation cache lifetime (See Replay and Revocation -section later at this page) to at least match with this. Also check accessTokenLifetime and use which ever is longer. |
refreshTokenChainLifetime 3.4 | Duration | PT2H | Lifetime of the chain of refresh tokens issued to client. The expiration instant is calculated by adding the lifetime to the end user authentication instant. |
additionalAudiencesForIdToken | Set<String> | | Adds additional valid audiences for ID token. This feature does not involve any policy controls or features that may be added in the future to support issuing tokens to parties other than the OIDC client. It should be used with caution, and in most cases avoided. |
acrRequestAlwaysEssential | Boolean | false | Whether to treat "acr" claim requests as essential regardless of request |
forcePKCE | Boolean | false | Whether client is required to use PKCE |
allowPKCEPlain | Boolean | false | Whether client is allowed to use PKCE code challenge method "plain" |
encodedAttributes | Set<String> | | Specifies IdPAttributes to encode into tokens for recovery on back-channel token requests |
encodeConsentInTokens | Boolean | false | Whether to embed consent decision(s) in access/refresh tokens and authorization code to allow for client-side consent storage |
alwaysIncludedAttributes | Set<String> | | Specifies IdPAttributes to always include in ID token regardless of response_type |
deniedUserInfoAttributes | Set<String> | | Specifies IdPAttributes to omit from UserInfo token |
accessTokenType3.2 | String | | Format of access token. Supported values are “JWT” or nothing/empty/null, implying opaque tokens. |
useRequestObject 3.4 | Boolean | false | Whether to enforce use of request objects |
signRequestObject 3.4 | Boolean | true | Whether to enforce signing of request objects if they’re used. |
encryptRequestObject 3.4 | Boolean | false | Whether to enforce encryption of request objects if they’re used. |
responseModes 4.1 | Set<String° | | Specifies allowed values for response_mode in the authorization/authentication requests. Null/empty means that all supported values are allowed. |
requireAuthenticationRequest 4.1 | Boolean | true | Whether to enforce use of OIDC authentication sequence (involving openid scope). Note! In SAML metadata-driven configuration, only the use of requireAuthenticationRequestPredicate is supported. |
requirePushedAuthorizationRequest 4.2 | Boolean | false | Whether to require the use of OAUTH2.PAR prior to the authorization/authentication request and thus include the request_uri value produced by it. |
strictScopeValidation 4.2 | Boolean | false | Whether to enable strict scope validation. If enabled, the request containing non-allowed (not registered for the registered clients or non-policy compliant for unregistered clients) scope values is considered as an error. |
includeIssuerInResponse 3.2 | Boolean | false | Whether to include issuer -parameter in the responses, as specified by RFC 9207. If set to true, also consider including authorization_response_iss_parameter_supported to the OP metadata. |
IDTokenManipulationStrategy 3.2 | BiFunction<
ProfileRequestContext,
Map<String,Object>,
Map<String,Object>
> | | Manipulation strategy for customising id_token contents. The BiFunction inputs are the ProfileRequestContext and the current contents of id_token as a Map<String,Object>. If the result is non-null, the result (Map<String,Object) is used to replace the contents of the id_token. It is the deployer’s responsibility to ensure the results remain valid/appropriate. |
authorizationCodeClaimsSetManipulationStrategy 3.2 | BiFunction<
ProfileRequestContext,
Map<String,Object>,
Map<String,Object>
> | | Manipulation strategy for customising authorization code claims set contents. The BiFunction inputs are the ProfileRequestContext and the current contents of the claims set as a Map<String,Object>. If the result is non-null, the result (Map<String,Object) is used to replace the contents of the claims set. It is the deployer’s responsibility to ensure the results remain valid/appropriate. |
accessTokenClaimsSetManipulationStrategy 3.2 | BiFunction<
ProfileRequestContext,
Map<String,Object>,
Map<String,Object>
> | | Manipulation strategy for customising access token claims set contents. The BiFunction inputs are the ProfileRequestContext and the current contents of the claims set as a Map<String,Object>. If the result is non-null, the result (Map<String,Object) is used to replace the contents of the claims set. It is the deployer’s responsibility to ensure the results remain valid/appropriate. |
customRedirectUriValidationStrategy 4.2 | BiPredicate< URI, ProfileRequestContext > | null | Custom validation strategy for the redirect_uri parameter. If a value is set, it overrides the default validation logic for both registered and unregistered clients. |
The following properties can be used to globally adjust some of the settings above (some of them affect other profiles as well).
idp.oidc.idToken.defaultLifetime
idp.oidc.accessToken.defaultLifetime
idp.oidc.authorizeCode.defaultLifetime
idp.oidc.refreshToken.defaultLifetime
idp.oidc.forcePKCE
idp.oidc.allowPKCEPlain
idp.oidc.encodedAttributes
idp.oidc.encodeConsentInTokens
idp.oidc.alwaysIncludedAttributes
idp.oidc.deniedUserInfoAttributes
idp.oauth2.requireAuthenticationRequestPredicate3.3
idp.oidc.requestobject.used3.4
idp.oidc.requestobject.signed3.4
idp.oidc.requestobject.encrypted3.4
idp.oauth2.responseModes4.1
idp.oidc.strictScopeValidation4.2
The encodedAttributes feature is discussed under OPAttributeResolution (see Timing of Resolution).
The final two options relate 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. These settings force claims into or out of those spots.
Replay and Revocation
Authorization codes are bearer tokens and have to be limited to a single use as a security measure. Reuse is monitored by storing reference values in the existing IdP replay cache that handles related SAML and CAS needs. It should be noted that the criticality of this cache to CAS and OIDC are generally much higher than for SAML (unless SAML artifacts are used), and the limitations of an in-memory cache that is not clustered across servers much more severe.
Reuse of an authorization code invalidates all tokens derived from it by tracking revoked codes. This is handled by another (obviously server-side) cache, the revocation cache.
Two properties are provided in conf/oidc.properties to control aspects of this process: