Two-factor authentication and ApplicationOverride

[Cantor, Scott]

On 9/7/15, 8:31 AM, "dev on behalf of Sérgio Nicolau da Silva" <dev-bounces at shibboleth.net on behalf of sergions at gmail.com> wrote:

>The proposal is the use of ApplicationOverride (SP) setting a new Endpoint (handlerURL) to second factor authentication. Where:
>- Endpoint A (ApplicationDefaults):  user and password authentication;
>- Endpoint B (ApplicationOverride): second factor authentication.

It's likely a more flexible approach to just do the enforcement in your application layer, which obviates the need to do all that extra set up in the SP. There are some things that just aren't that clean to pull out of that layer.

>The IdP has a subflow for the second factor TOTP based.

I don't know how well creating separate flows for the two factors really works. I'm not really convinced that's going to be viable.

>The questions are:
>- It is a viable way within the IdP / SP architecture?

That's a matter of opinion. It will be hard, IMHO.

>- How to identify within the flow (SWF) the endpoint forward authentication request, for to select the flow two-factor or password?

I don't exactly understand your question, but I think you're getting into exactly why having separate flows doesn't work easily. For one thing, you're fundamentally incorrect about what the flows do. You do *not* have a two factor flow. TOTP is not multi-factor, it's one factor. The password is the other factor. What you have is two flows that have to run at the same time in a complex web of interactions that is very hard to pull off.

The IdP doesn't know anything about this. It only runs flows individually based on a single dispatching architecture and configuration which I documented in the wiki.

-- Scott