Page Comparison

...

Overview

The "context-check" intercept interceptor flow is an example of how to use an intercept interceptor to interrupt processing and either continue or halt processing based on the state of the "context tree" that makes up the state of the request. A common use case for this feature is to impose authorization rules at the IdP to work around the limitations of a service that either does not implement any authorization or does not provide an adequate user experience in the event of failure. A frequently cited example of the latter is Google Apps for Education. Must be their limited budget.

...

• information about the relying party
• information about the user, the user's session, the user's authentication state, or attributes
• environmental information from the client request
• any configuration/rules you define and inject with Spring

General Configuration (V3.4 and above)

As of V3.4, this flow can operate in the limited "single condition" mode offered originally or a more flexible functional mode.

For the single condition mode, refer to the original documentation below for older versions.

Previously, it was common to need to create copies of the flow to accomodate different needs, as shown in the section labeled "Multiple Checkers". While this is still possible, it can be avoided in many cases by using the newer support for applying a Function instead a condition/predicate. While the condition mode applies a single condition and returns a fixed error Event, the Function mode is more general in that it directly returns a string to use as the follow up event.

The bean named shibboleth.context-check.Function in intercept/context-check-intercept-config.xml must be defined by you with the function you want to apply. The bean must be of type Function<ProfileRequestContext,String>. The return value contains the event that the interceptor should signal, either "proceed" to indicate that processing should continue successfully or any other value as a custom Event. For example, returning "ContextCheckDenied" will match the existing behavior of the original condition mode.

If you want to support one or more custom events, you'll need to add the event(s) to conf/intercept/intercept-events-flow.xml. The default file includes a commented example for an event called "MyCustomEvent". Then you'll need to add that event in conf/errors.xml if you want it handled with a local error page.

As a primitive example, consider a map indexed by relying party name, allowing a condition to be uniquely defined for each applicable relying party separately.

<util:map id="ConditionMap">
	<entry key="https://sp.example.org/sp">
		<ref bean="Condition1"/>
	</entry>
	<entry key="https://another.example.org/sp">
		<ref bean="Condition2"/>
	</entry>
</util:map>

<bean id="shibboleth.context-check.Function" parent="shibboleth.ContextFunctions.Scripted" factory-method="inlineScript"
		p:customObject-ref="ConditionMap">
	<constructor-arg>
		<value>
		<![CDATA[
		var event = "proceed";
		var rpid = input.getSubcontext(
				"net.shibboleth.idp.profile.context.RelyingPartyContext").getRelyingPartyId();
		var condition = custom.get(rpid);
		if (condition != null && !condition.apply(input)) {
			event = "ContextCheckDenied";
		}
		event;
		]]>
		</value>
	</constructor-arg>
</bean>

General Configuration (V3.3 and below)

The only configuration involved with this flow is to define the condition you want it to evaluate, and possibly adjust the user interface result in the event of failure.

The bean named shibboleth.context-check.Condition in intercept/context-check-intercept-config.xml must be defined by you with the condition you want to apply. The bean must be of type Predicate<ProfileRequestContext>, but beyond that, it can do anything. Note that this is the same type signature as the conditions discussed in the ActivationConditions topic, so the examples there may help you. Non-programmers may be particularly interested in the scripted examples.

...

The event is mapped to a default error message using the standard machinery, which you can adjust, but producing the right response for a lot of different (possibly unrelated) scenarios will quickly become hard to manage. You will probably want to define your own events, and to do that, you need to create your own copy of this flow.

Multiple Checkers

While you absolutely can use this flow directly, it will often become unwieldy to try and combine every possible use for this feature into a single condition to evaluate. One reason is the user interface problem discussed above. So you may find it more fruitful to actually copy it into your own version in "user-space" and create multiple versions of it for different purposes. That way each one is simple, self-contained, and easier to maintain.

...

In some cases, this may not be sufficient, such as when the user's identity or associated attributes dictate whether authentication is sufficient, regardless of the service. If the MFA login flow is being used, the suggested approach is to manipulate the RequestedPrincipalContext object in the context tree as part of the MFA ruleset, so that the IdP will enforce the appropriate policy for you.

...

Notes

TBD