Where to put multifactor flows

[Marvin Addison]

>
> The initial-authn's purpose is, essentially, to let you get information
> about the current user before addressing the SP's request.  This is needed
> for second factor only authentication like Duo, but it also helps with user
> experience by not asking the user to do something that can't be done
>

In our case it's not only a matter of user experience but policy. We need
to run the authn subsystem once to get attributes in order to determine
whether the user is a candidate for 2-factor authentication; if not, the
user MUST NOT proceed to the Duo login page. I believe our requirements are
similar to what David Langenberg posted recently [1].


> The problem is that it can cause an extra authentication step, if the
> initial-authn doesn't contribute to the first SP's request.  As I
> understand Marvin's use case, he has three possible types of
> authentication, Password, Duo, and X.509.
>

That's correct.


> Password authentication is required for the first two, but it's an extra
> step for X.509.
>

Correct.


> I'm also guessing that X.509 satisfies the requirements for a Duo request,
> and Duo satisfies the requirements of a Password request (*i.e.*, once
> the user authenticates with X.509, there's no further need to authenticate
> during the IdP session, barring a request for forced re-authentication).
>

It's actually more complicated than that. Not all X.509 certificates are
equal, though for the common case the hierarchy you stated is correct:
X.509 > Duo > password.


> What if Marvin's Password login screen had a button to invoke X.509
> authentication (and was the initial-authn)?
>

That's actually a step backward. The RequestedPrincipalContext machinery
works great for driving the user to the proper login process based on SP
requirements. That's not to say we can't do what you suggested, but it
would trade Duo functionality for a lesser user experience. I'm hopeful we
can get the functionality we need without that tradeoff.


> I do like the idea of conditional initial-authns, by the way.  Probably
> something like "use X if the SP requested Y," where X and Y may or may not
> be the same, but it gets complicated if the SP requests more than one
> context.
>

Frankly, it makes my head hurt, but I think making initial-authn
conditional is what we need. I'm still not clear on the knobs, but I'm
willing to go with a straw man, test it, and report back.

M

[1]
https://wiki.shibboleth.net/confluence/display/IDP30/Replicating+Multi-Context+Broker+Functionality
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150715/d3c2d0e9/attachment.html>