Where to put multifactor flows

[David Walker]

Moving up a level or two...

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 (/e.g./, authenticate with a hardware token that hasn't been
issued to the user, or an assurance profile for which the user hasn't
been certified), as well as for implementing special site policies for
when certain authentication methods must be used.

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.  Password authentication is
required for the first two, but it's an extra step for X.509.  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).

What if Marvin's Password login screen had a button to invoke X.509
authentication (and was the initial-authn)?  People with X.509 tokens
could then be trained to use X.509 all the time, rather than typing a
password.  It might provide a more consistent user interface, and
probably wouldn't create too much of an extra step for X.509 token holders.

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.

David


On 07/14/2015 08:05 AM, Cantor, Scott wrote:
> On 7/14/15, 10:56 AM, "dev on behalf of Marvin Addison" <dev-bounces at shibboleth.net on behalf of marvin.addison at gmail.com> wrote:
>> That sounds like it would provide flexibility so that Password method of initial-authn is not assumed, which is what we need. I'm unclear what happens on the second pass through the authn subsystem; is there a flag that prevents duplicate processing by the actual auth mech?
> SSO kicks in. The initial-authn run is trying to get a Session in place so that when the "real" flow runs, if it's already done what's required to satisfy the request it just falls into the SSO logic and reuses the result.
>
>> You mean the case where a flow can't be found due to unsatisfied RequestedPrincipalContext? If that's what you mean, I don't see why it would matter. It would fail on the second round anyway and amount to the same result afaict.
> Well, the assumption for the initial-authn case is that you're limiting the set of flows that might be available, otherwise there's not much point in doing it. If you limit the initial set and then apply RequestedPrincipalContext logic to which runs are usable, the assumption I'm making is that the "real" set is larger and so the second run might not fail.
>
> That's an assumption, but it seems like a valid one. I'm sure there could be cases where it won't hold, but I don't understand what they would be. Running initial and "regular" authn with the same set of flows and both honoring the RPC rules would seem to be truly redundant.
>
> The "initial" run seems like it should have to be different in some dimension, either in the flows that are active or in whether the RPC is looked at.
>
> -- Scott
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150715/1c9b19aa/attachment.html>