OPAuthorization

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 shibbileth.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 .

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

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

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:

• idp.oidc.revocationCache.authorizeCode.lifetime

  • Lifetime for entries stored to revocation cache, defaults to 6 hours.

• idp.oidc.revocationCache.StorageService

  • Bean ID of StorageService for revocation cache, requires server-side storage. Defaults to shibboleth.StorageService (in-memory).