...
A special feature of this flow is the ability to inject your own behavior in response to particular error or warning conditions that occur. These conditions are set via the shibboleth.authn.Password.ClassifiedMessageMap bean in authn/password-authn-config.xml. That is, if you map a particular string label to one or more exception/error messages in the map, that string label becomes a flow "event" that you can program the flow to respond to. This is controlled with a subflow that is under user control in flows/authn/conditions./
The conditions-flows.xml file controls what events are detected and handled, and what to do. The example included responds to a number of events by calling predefined subflows that are themselves just empty examples that return immediately, and then it control passes control back to the view state that renders the login form.
An obvious use for this feature is responding to an imminently expiring password with some kind of warning view; another is detection of a locked account, and the use of a dedicated view to help the user with that condition.
Some notes about this feature...
Don't touch anything in the system/ directory (this is always true, but it's just reinforcement: this feature is not about changing our flows, it's about creating your own).
If what you want to do is interrupt and stop the login process for good, then what you want to do is modify the subflow file corresponding to the event/condition you want to "hook" and change it from signaling "proceed" to signaling your custom event name, which could just be the event you started with (AccountLocked, etc.). The ErrorHandlingConfiguration topic has some discussion of how to handle the event with your own error page.
On the other hand, if what you want to do is interrupt the login process to do something else and then resume it again, that's more work and would require actually plugging your own behavior into the corresponding subflow file. In the simplest case, maybe you just want to display a page, in which case you can insert your own <view-state> that displays a template of your own creation. Views generally have to contain a form whose action is set to "$flowExecutionUrl" and that contain a button to submit the form with the value "_eventId_proceed". Your view then transitions on "proceed" to the corresponding <end-state> and ends up back on the login form.
In more complex cases, you may need to actually redirect the user out to other functionality implemented outside the IdP, which is something the Spring Web Flow documentation refers to as an external redirect, and it's possible to resume the flow in that scenario as well. If you don't, the user's session is suspeneded and will consume resources until it times out, and that doesn't work well at scale, so you have to be careful with that approach.
Custom Back-Ends
Due to the design of this login flow, it's possible to plug in alternative validation strategies by commenting out all of the existing bean imports in password-authn-config.xml and supplying an alternative. The only real requirement is that you supply a bean "alias" of this form:
...