...
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.
In the simplest case, it's possible to map messages to labels like "InvalidPassword" or "AccountLocked", and the views/login-error.vm file includes example behavior that handles these kinds of error labels. That's one form of customization.
If your goal is to terminate processing at this pointafter an error, 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.
...
A feature included with the Password flow is the ability to present additional login options to the user and call them directly as subflows in response to some form of user input or client-side script. This is useful if you want most users to have the option to use a password, but make more advanced options available at the same time without requiring extra pages or clicks to reach the password option.A key advantage is that it allows error handling in response to other login flows to be handled by the username/password login view, to avoid stranding the user or having to return an error for the overall request. The second advantage is that allows the Password flow and the extended flow(s) to be combined without prior knowledge of each other
This feature has been superseded by the MFA login flow implemented in V3.3 and is much more flexible and usually simpler to use, even though it's more complex to understand at first. There are no explicit plans to deprecate or remove this feature yet, but migrating away from it would be a good decision.
Basic Setup
Some preconditions for using this feature:
...
To the base path you must append a slash, the name of a bean implementing the AccountLockoutManager interface, another slash, and finally the "key" that identifies the lockout record to access. By default this will be a username, a bang (!), and an IP address (unless you customize the way the lockout is scoped).
...