...
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 control passes 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.
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.
If your goal is to terminate processing at this point, then you should take a look at the discussion in AuthenticationConfiguration under "Custom Events", which describes how to authorize the system to treat your custom events as allowable "end" states for the request and handle them as errors.
If your goal is rather to interrupt but then resume the login flow, then this is somewhat accomodated with a predefined set of flow defintions designed to be user-editable 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 control passes 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.
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.
...