Modifying Login Flows

[Cantor, Scott]

On 1/24/19, 6:09 PM, "users on behalf of Mr. Christopher Bland" <users-bounces at shibboleth.net on behalf of chris at fdu.edu> wrote:

> I would appreciate any thoughts or suggestions,

If you really don't want to complete the login process, I think there's a simpler trick you can use than bothering with all the flow features and custom error handling, so I'll start with  that.

You could detect the PasswordExpired event on the login view and have that short-circuit the rest of the Velocity template by rendering your error page, and have a hidden iframe trigger the $flowExecutionURL with a query parameter like "_eventId_PasswordExpired" to force the login flow to finish with an error event and hopefully wrap up the whole request, but it would be invisible, it's just housekeeping for the session. For initial debugging, not doing that won't hurt anything, it just leaves state around in memory and leaves the requests half done.

That said (since I already wrote up the overview of the "long" way) I'll include that...

I extended the documentation for the Password flow earlier today where it talks about custom error handling with a little bit about the common use cases.

For this scenario, it (now) talks through the couple of steps. You want to finish out the authentication as a whole with a custom event and then handle that event as an error.

Assuming you have the LDAP or JAAS error messages mapped appropriately so you get the (e.g.) ExpiredPassword event happening, that's going to run a particular subflow that's underneath flows/authn/conditions/

That subflow has a dummy definition that just triggers "proceed" in the <on-start> block to make it a no-op. You change that so it signals "ExpiredPassword" and add that <end-state> and I believe that should cause the whole authn flow to complete with that event once all the stack popping is done.

That may not be 100% of the change required but it's close and I can figure out the rest from whatever it complains about and get it documented so it's clearer the next time.

And then the final step is in [1] which describes how to handle any custom event with a new error page (or extend the existing error.vm view to deal with it, up to you). Once the event is bubbling out, it can be handled as what's called a "local" error, which just means to let the IdP deal with it and not return control to an SP. Most of these kinds of things are going to be handled that way. conf/errors.xml lets you define local error events and map them to custom view pages if desired.

If you're asking why it's all that hard, honestly we just display that error for the user at the top of the login form and link off to the page where they can fix it (opening a new window). They can come right back and finish logging in that way, and that seemed a lot simpler to me.
 
-- Scott

[1] https://wiki.shibboleth.net/confluence/display/IDP30/ErrorHandlingConfiguration