ProfileInterceptConfiguration

Current File(s): conf/relying-party.xml
Format: Native Spring

1 Overview
2 General Configuration
3 Reference
- 3.1 Beans

Overview

An interceptor is a Spring Web Flow that can be run as a subflow (a sort of callable subroutine) at specific points during the processing of a request to the IdP to do work. It allows behavior to be customized without replacing core code.

There are currently three different "interception" points in the profile flows:

Inbound message processing
Post-authentication during SSO profiles
Outbound message processing

The inbound and outbound hooks are not commonly used by deployers. In contrast, the post-authentication hook is a very fruitful injection point for supporting many useful features. Several predefined examples come with the software, and can be used as examples to develop your own, though this is a development task, not just a matter of configuration.

General Configuration

Built-In Interceptors

The following interceptor flows are provided with the software:

Enabling Interceptors

The three interception points mentioned above correspond to three properties that can be specified on the profile configuration beans in the RelyingPartyConfiguration. Each property is a list of intercept flow IDs (excluding the "intercept/" prefix) to run.

All profile configurations include a pair of properties, inboundInterceptorFlows and outboundInterceptorFlows, for specifying inbound and outbound interceptors.

Authentication profile configurations (e.g. CAS, SAML Browser SSO and ECP) include a postAuthenticationFlows property for specifying the ordered list of interceptors to run after most of the work of the system is done but before any outbound message/response has been generated. They run after the user has logged in and after any user attributes have been resolved and filtered; essentially all that's left is the production of a response, so this is an opportunity to affect the result that will be produced (or prevent one altogether).

Example enabling intercepts for the SAML SSO profiles

    <bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty">
        <property name="profileConfigurations">
            <list>
                <bean parent="Shibboleth.SSO" p:postAuthenticationFlows="#{{'attribute-release', 'terms-of-use'}}" />
                <ref bean="SAML1.AttributeQuery" />
                <ref bean="SAML1.ArtifactResolution" />
                <bean parent="SAML2.SSO" p:postAuthenticationFlows="#{{'attribute-release', 'terms-of-use'}}" />
                <ref bean="SAML2.ECP" />
                <ref bean="SAML2.Logout" />
                <ref bean="SAML2.AttributeQuery" />
                <ref bean="SAML2.ArtifactResolution" />
                <ref bean="Liberty.SSOS" />
            </list>
        </property>
    </bean>

Developing Interceptor Flows

Refer to the ProfileHandling developer material for more technical details on developing interceptor flows.

Reference

Beans

Bean ID	Type	Function

Bean ID	Type	Function
shibboleth.AvailableInterceptFlows	List<ProfileInterceptorFlowDescriptor>	List of flow descriptors enumerating the interceptor flows available to the system (supplanted now by autowiring of ProfileInterceptorFlowDescriptor beans, but you might need to create this bean if you wish to extend/alter the behavior of the system-defined flows)
shibboleth.InterceptFlow	ProfileInterceptorFlowDescriptor	Abstract parent bean for defining new flow descriptor beans