OPLogout

File(s): conf/relying-party.xml, conf/oidc.properties
Format: Native Spring, Spring Properties

1 Overview
2 Configuration
- 2.1 Profile configurations
- 2.2 Required IdP properties
- 2.3 Metadata items
- 2.4 Logout views in IdP 5.0
- 2.5 Profile configuration options
  - 2.5.1 Guidance

Overview

Since OP version 4.1, the OIDC.Logout profile configuration bean enables support for the OIDC logout specifications that cover the two halves:

Responding to requests from RP (OIDC RP-initiated logout)
Propagating logout to an RP (OIDC front- and back-channel logout)

Similarly to the SAML logout, the propagation step works in the same way regardless of how the logout is initiated (see https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199510118 ).

Configuration

Profile configurations

In addition to the OIDC.Logout bean, make sure to enable OAUTH2.Revocation bean to enable token revocation during the logout process (see documentation for the revokeTokens -property below).

Required IdP properties

Similarly to the SAML logout, the following global configuration properties need to be set to true:

idp.session.trackSPSession
idp.session.secondaryServiceIndex

Metadata items

In addition to the configuration options below, the following items at the RP metadata are needed for specific features:

post_logout_redirect_uris: the set of redirection URIs that may be used with the OIDC RP-initiated logout
backchannel_logout_uri: the URI used with the back-channel logout propagation
backchannel_logout_session_required: the flag to indicate that sid-parameter should be included in the back-channel logout request
frontchannel_logout_uri: the URI used with the front-channel logout propagation
frontchannel_logout_session_required: the flag to indicate that sid-parameter should be included in the front-channel logout request

Either backchannel_logout_uri or frontchannel_logout_uri needs to be included in the RP metadata to activate the propagation support.

Logout views in IdP 5.0

With IdP 5.0, the logout-propagate.vm and logout-complete.vm views need to be modified to contain the following iframe inside the if-clause:

<!-- If OIDC logout, complete the flow by adding a hidden iframe. -->
#if ($profileRequestContext.getProfileId().contains("oidc/logout"))
    <iframe style="display:none" src="$flowExecutionUrl&_eventId=proceed"></iframe>
#end

The snippet is needed to close the logout process and free up the resources on the IdP-side. In the cases when RP-initiated logout was used to initiate the logout process and the logout request message contained the post_logout_redirect_uri -parameter, this iframe will also call that post logout redirection URI via HTTP 302 redirect.

From IdP 5.1 onwards, no changes to the default logout views are needed.

Profile configuration options

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.

Options common to most/all profiles:

Name	Type	Default	Description

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.

Options specific to the OIDC Logout flow:

Name	Type	Description

Name	Type	Description
encryptionOptional	Boolean	Whether to automatically disable back-channel logout token encryption if the relying party does not possess a suitable key (defaults to true).
preferFrontChannel	Boolean	Whether to prefer front-channel logout propagation if both front and back -channel URIs are defined in the RP metadata (defaults to true).
frontChannelSuccess	Boolean	Whether to consider front-channel logout propagation success in the propagation UI (defaults to false).
revokeTokens	Boolean	Whether to revoke the access and refresh tokens related to the session (defaults to true). Note that the OAUTH2.Revocation profile must be enabled for the RP.
requireIdTokenHint	Boolean	Whether to require the use of id_token_hint parameter in the RP-initiated logout request.
logoutHintMatchingStrategy	BiPredicate< String, SPSession >	A bi-predicate for matching the logout_hint parameter with an SPSession (defaults to always return false).

The following properties can be used to globally control settings above:

idp.oidc.logout.encryptionOptional
idp.oidc.logout.preferFrontChannel
idp.oidc.logout.frontChannelSuccess
idp.oidc.logout.revokeTokens
idp.oidc.logout.requireIdTokenHint
idp.oidc.logout.logoutHintMatchingStrategy

The global bean shibboleth.oidc.logout.LogoutTokenTypeLookupStrategy (Function<MessageContext, String>) can be defined for replacing the default logic for naming back-channel logout tokens. By default their type is always logout+jwt as recommended by the specification.