Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Current File(s): conf/intercept/profile-intercept.xml, conf/relying-party.xml

Format: Native Spring

Overview

An intercept is a Spring Web Flow that can be run as a subflow 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 or changing system files.

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 primarily used by the system to plugin in security handling code and to allow for very specialized kinds of customization, and 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 to help develop your own custom behaviors.

General Configuration

The three interception points 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. The SAML profile beans typically auto-declare the right inbound interceptor flow to run to provide the appropriate security checks; these interception points should generally be left to their default values.

Authentication profile configurations (e.g. CAS, SAML Browser SSO and ECP) include a postAuthenticationFlows property for specifying the ordered list of  intercepts 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; 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>

There are three intercept flows provided with the software:

Custom Intercepts

TBD

Reference

Beans

Bean IDTypeFunction
shibboleth.AvailableInterceptFlowsList<ProfileInterceptorFlowDescriptor>List of flow descriptors enumerating the intercept flows available to the system
shibboleth.DefaultInterceptFlowsList<ProfileInterceptorFlowDescriptor>List of built-in intercept flows, into which user-defined flows are merged
shibboleth.InterceptFlowProfileInterceptorFlowDescriptorAbstract parent bean for defining new flow descriptor beans

Notes

TBD

  • No labels