Modifying Login Flows

[Mr. Christopher Bland]

Hi Scott,

I am clearly missing something.  I have done the following:

Authorizing custom login flow events in conf/authn/authn-events-flow.xml
    <end-state id="FDUExpiredPassword" />

    <global-transitions>
        <transition on="FDUExpiredPassword" to="FDUExpiredPassword" />
        <transition on="#{!'proceed'.equals(currentEvent.id)}" to="InvalidEvent" />
    </global-transitions>


Creating a custom error in conf/authn/password-authn-config.xml inside     <util:map id="shibboleth.authn.Password.ClassifiedMessageMap">
        <entry key="FDUChangePassword">
            <list>
                <value>ERROR_PASSWORD_EXPIRED</value>
                <value>ERROR_PASSWORD_MUST_CHANGE</value>
                <value>PASSWORD_EXPIRED</value>
                <value>PASSWORD_MUST_CHANGE</value>
                <value>532</value>
                <value>773</value>
            </list>
        </entry>


In conf/errors.xml
    <util:map id="shibboleth.EventViewMap">
             <entry key="FDUExpiredPassword" value="fduexpiredpassword" />
    </util:map>

    <util:map id="shibboleth.LocalEventMap">
        <entry key="FDUExpiredPassword" value="true" />
        ...
    </util:map>

What I am now seeing is in the error message part of the login page I see "Login Failure: FDUChangePassword” instead of the message defined in messages.properties. 

I feel like I need something in flows/authn/conditions/conditions-flow.xml or possibly I need to use the idp.errors.exceptionMappings.  I am unsure of what to set idp.errors.exceptionMappings to.  

-Chris

> On Jan 24, 2019, at 8:04 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> 
> (This title by the way is not a great description of what's going in here. You do *not* modify login flows, that's not supported.)
> 
> On 1/24/19, 6:39 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:
> 
> <some ideas>
> 
> I think the simplest option that's the least invasive to the existing view is actually a combination of what I suggested. What I would probably do (well, aside from the defaults and just letting it be) is to map the relevant error messages to a custom Event name that doesn't match one of the "known" events.
> 
> Instead of ExpiredPassword, map the error strings to MyExpiredPassword or CustomExpiredPassword or whatever, and follow the documentation in [1] under Custom Events. That describes how to get your custom event to complete the flows gracefully and then head over to the error handling docs to do what I suggested and set up a template to handle it.
> 
> That's simpler in the end because it's less invasive to the login view, which is already complex enough, and isn't really meant to be handling errors that way.
> 
> I'd forgotten this was already outlined in the top level docs. I'll link it more contextually into some of the other pages.
> 
> -- Scott
> 
> [1] https://wiki.shibboleth.net/confluence/display/IDP30/AuthenticationConfiguration
> 
> 
> -- 
> For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net