MFA fails canonicalization of 2nd factor when re-using existing session

Grant Byers Grant.Byers at aarnet.edu.au
Wed Apr 14 22:09:01 UTC 2021


Thanks Scott. That makes sense.

> I think there's a logging bug that's failing to note that the problem is there are two UsernamePrincipals in the final pile of merged results, one from the Password flow and one from SPNEGO. Simple c14n can't do that, it only runs when there's a single one (it doesn't actually look and see whether they're the same, and in most cases they're not because SPNEGO will populate its copy with the Kerberos principal name).

> So anyway, that's probably the issue. If you let it just merge them all together and then try and apply "simple" that's not going to fly. You need a custom merging function to produce the MFA results at the end or you need a custom c14n solution that knows how to deal with the merged results.

Will see what I can come up with.

> I'd also be curious what happens if you bypass Password and go straight to SPNEGO + Duo. Unless you do something about it, the Kerberos principal names should be getting passed up to Duo as the username, and I can't imagine that's what you'd want either. You probably could apply a regex via simple c14n to transform those into something though.

I am applying a regex via simple c14n at the moment, so it's just the username portion or the kerberos principal that gets passed to Duo.

> I'm going to do a bit of poking at the logging and see if I can get a bit more out of it for the next patch, it should record the reason "simple" couldn't apply, not just that it couldn't.


--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20210414/88b317b3/attachment.htm>


More information about the users mailing list