Current File(s): conf/intercept/profile-intercept.xml (V4.0), conf/relying-party.xml
Format: Native Spring
...
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.
...
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
Defining Interceptors
There are significant differences in the OOB approach to configuration for new installs of V4.1 compared to V4.0 or upgraded systems. The tabs below (and elsewhere in the page) provide the relevant information for each version, and where applicable information on taking advantage of new approaches after upgrading.
| Expand | ||
|---|---|---|
| ||
The intercept/profile-intercept.xml file is where all supported interceptor flows are (usually minimally) described to the system. The file contains a Spring list bean named shibboleth.AvailableInterceptFlows. Descriptors are of a specific class, ProfileInterceptorFlowDescriptor, and generally the other options are handled with properties or with other XML configuration files. The |
| Expand | ||
|---|---|---|
| ||
V4.1 introduces Modules, and most of the individual interceptor flows have been converted into modules that can be enabled and disabled. This approach is addressed within the pages that document all the flows. Every interceptor flow known to the system auto-registers itself and generally any other settings are documented on those individual pages.
Upgrading from V4.0 and EarlierThe information above focuses on the "as-delivered" V4.1 defaults, which are changed from earlier versions, and apply out of the box only to new installs. Upgraded systems, while they may contain combinations of old and new files, by design function the same as they used to for compatibility, and the new bits are generally ignored/overridden by the older settings. With V4.1, the use of XML to configure many basic features has been minimized and the original intercept/profile-intercept.xml file has been removed from new installations (but is still processed when present). With this release, all beans of type ProfileInterceptorFlowDescriptor are automatically recognized, obviating the need to define them by hand, which was the main purpose of the XML file. Instead, all of the built-in interceptor flows are wired up internally, and any settings required are (and, for the most part already were) handled with properties in the conf/idp.properties file. Any flow descriptor bean inside a list named shibboleth.AvailableInterceptFlows with a particular p For those wishing to migrate from the older approach to the newer approach (this is not required), removing intercept/profile-intercept.xml and setting any properties corresponding to non-default settings applied in the XML will provide equivalent behavior. |
...
Built-In Interceptors
The following interceptor flows are provided with the software:
Warning 4.1
...
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. The 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 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).
...
Bean ID | Type | Function |
|---|---|---|
shibboleth.AvailableInterceptFlows | List of flow descriptors enumerating the interceptor flows available to the system (supplanted in V4.1 now by autowiring of ProfileInterceptorFlowDescriptor beans, but you may might need to create this bean if you wish to extend/alter the behavior of the system-defined beansflows) | |
shibboleth.InterceptFlow | Abstract parent bean for defining new flow descriptor beans |
...