Current File(s): conf/intercept/profile-intercept.xml (V4.0), conf/relying-party.xml
Format: Native Spring
Table of Contents |
---|
Overview
An interceptor 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.
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 plug 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 as examples to develop your own, though this is a development task, not just a matter of configuration.
...
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.
Localtabgroup | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
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
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. |
The following interceptor flows are provided with the software:
Warning 4.1
Enabling Interceptors
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.
...
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
Code Block | ||
---|---|---|
| ||
<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> |
...
Refer to the ProfileHandling developer material for more technical details on developing interceptor flows.
Reference
Localtabgroup | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|