Authn cancel from a subflow.

O'Dowd, Josh Josh.O'Dowd at
Wed Aug 5 16:20:01 EDT 2015

Thanks.  This is great; very flexible.  Can I assume, then, that only a 'proceed' event will result in an SSO session being granted?


-----Original Message-----
From: users [mailto:users-bounces at] On Behalf Of Cantor, Scott
Sent: Wednesday, August 05, 2015 2:11 PM
To: Shib Users
Subject: Re: Authn cancel from a subflow.

On 8/5/15, 3:37 PM, "users on behalf of O'Dowd, Josh" <users-bounces at on behalf of Josh.O'Dowd at> wrote:

>What is the best/cleanest way to implement a cancellation event from an intercept subflow, such that the user would land on a message view, but no SSO session created?

An intercept can signal any event it wants, and you can classify any event as Local or non-Local and handle any local events using the default error view or by mapping it to a dedicated view. All of that is contingent on the Event being known to the flow, which is explained below.

>It looks like the /conf/intercept/intercept-events-flow.xml might be a place to start, but I am unsure how to use it.

The *-events-flow.xml files are needed because subflows have to reach an end-state and signal back the event they ended on as their flow result. To do that, there has to be an end-state for that event defined, and those *-events-flow files let you add your events in so that the surrounding flows that call things like login and intercept flows can signal back those custom events without requiring modification of the system files.

	-> intercept
		-> custom-intercept

The top of that call sequence has a rule defined:

  <transition on-exception="java.lang.RuntimeException" to="LogRuntimeException" />
  <transition on="#{!'proceed'.equals(}" to="HandleError" />

Meaning anything that's not "proceed" ends up getting routed to the error-handling machinery. Literally anything, it doesn't care. At that top level, there aren't enumerated events that have to be pre-defined.

That's not the case for those two other flows. For those flows to "surface" an event to the error handling code, they have to have an <end-state> defined for each event. To add your own events, you have to add a line like the commented example in the relevant flow file. Once you do that, any of your flow actions or views that signals it will safely terminate the subflow and the calling flow and eventually get it to bubble back out to the error handling code.

It's a lot of machinery to achieve a simple result but it's not really hard to use, just not so easy to grasp why.

-- Scott

To unsubscribe from this list send an email to users-unsubscribe at

More information about the users mailing list