Duo cancel event handling. IdPv3.3/SP2.5

Cantor, Scott cantor.2 at osu.edu
Wed Jan 4 16:18:59 EST 2017


On 1/4/17, 4:04 PM, "users on behalf of O'Dowd, Josh" <users-bounces at shibboleth.net on behalf of Josh.O'Dowd at mso.umt.edu> wrote:

>    Do you guys have any recommends for how to filter/handle the ‘cancel’ event that comes out of a Duo user cancellation?
> By default, it ultimately comes back to the SP as an AuthnFailed SAML response?  At the SP, in the /var/log/http-error.log
>I am seeing an eventId parameter in the log entry: SAML response reported an IdP error., referer:

You can't be treating Referer as part of the conversation, that's purely incidental and certainly nothing you can rely on to mean anything. The SP knows only what's in the SAML response, that's all.

> This ends up in the error view template on the SP.

Umm, the Referer doesn't, certainly...not in any template we provide. I don't even think you could get it there, not with the Shibboleth SP. Maybe I'm forgetting something.

>    I am wondering if there is a way to leverage the eventId at the SP so that I can have a more intuitive landing message
> for the user.

If you want to change the SAML status codes that get sent back, yes, that's possible.

> I also see that I can uncomment “NoPotentialFlow” in the shibboleth.LocalEventMap, and handle those at the IdP, but I
> am leary of how many permutations there might be there.

As Jim said, the first gate is what your flow scripting tells it to do, which can be a lot of things.

But confining this to passing something back, the cancel button causes the flow to trigger the ReselectFlow event. By default that triggers the check for a login method to try and failing that the NoPotentialFlow outcome. If you want something else, you can script a rule to turn that into a different event, propagate that out of authentication entirely, and then map that to a local view or to a SAML status.

You can do basically anything, in other words.

> Ultimately we would like the ‘cancel’ event messaging to be friendlier than the typical authentication failed messaging.

Well, you'll have to be specific. I don't happen to think that there *is* any result that ultimately will do much good, you just have to decide which end is responsible for leaving the user confused. Or take the cancel option off of course.

-- Scott




More information about the users mailing list