MCB with Duo and password as fallback

[Wessel, Keith]

Hi, all,

We're getting our plans together to put the MCB and Duo in place, and I'm preparing a demo for our security folks to help us make some decisions.

I'd like to set up a service provider to require Duo if available and, if not, to settle for username/password. This would allow users from two different assurance levels in that the application could handle accordingly.

But I'm hitting a snag. With my authnContextClassRef set to the duo context followed by the password context, and my initial context in the MCB set only to password, I get prompted to password authenticate. But then I never get sent to Duo authenticate, presumably because I've already settled the password context.

Only solution I can think of is to add a 3rd context which uses the password method that an SP will never ask for and configure it as my only initial context. If a user is eligible for Duo, the MCB will then try to satisfy the Duo context as it already knows the user's principal. If the user is only eligible for password, and since that method has already been satisfied, the password context will be returned to the service provider.

It feels like a hack to have a 3rd dummy context, though. I was hoping, after doing password authn, the MCB would then see that Duo was preferred and do that. No such luck.

Is there a cleaner way to do what I'm trying to do?

Thanks,
Keith

[Cantor, Scott]

Post by Wessel, Keith
But I'm hitting a snag. With my authnContextClassRef set to the duo
context followed by the password context, and my initial context in the
MCB set only to password, I get prompted to password authenticate. But
then I never get sent to Duo authenticate, presumably because I've
already settled the password context.

Isn't your SP asking for Duo first? That shouldn't be satisfiable with a
password...

Or do you mean you're requesting both at the same time?

That seems like a byproduct of favoring SSO over making the best match
with the request, which is really a bug (in V2 alone, don't know about the
MCB), and I coded V3 to include an option to leave that behavior, or
strictly honor the request's preference list and not favor SSO.

-- Scott

[Wessel, Keith]

Hi, Scott,

I'm asking for both at the same time, that is a space-separated list for authnContextClassRef with my duo class first and password class second.

The password class is my only initial class and, thus, gets triggered by the MCB when the user arrives.

I thought the MCB would then proceed to try and honor Duo. But that doesn't appear to be the case, thus my work-around of the 3rd class that the SP doesn't know about.

Does that clarify things?

Keith


-----Original Message-----
From: users-bounces-***@public.gmane.org [mailto:users-bounces-***@public.gmane.org] On Behalf Of Cantor, Scott
Sent: Wednesday, August 20, 2014 4:29 PM
To: Shib Users
Subject: Re: MCB with Duo and password as fallback

Post by Wessel, Keith
But I'm hitting a snag. With my authnContextClassRef set to the duo
context followed by the password context, and my initial context in the
MCB set only to password, I get prompted to password authenticate. But
then I never get sent to Duo authenticate, presumably because I've
already settled the password context.

Isn't your SP asking for Duo first? That shouldn't be satisfiable with a password...

Or do you mean you're requesting both at the same time?

That seems like a byproduct of favoring SSO over making the best match with the request, which is really a bug (in V2 alone, don't know about the MCB), and I coded V3 to include an option to leave that behavior, or strictly honor the request's preference list and not favor SSO.

-- Scott

--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org

[Cantor, Scott]

Post by Wessel, Keith
I thought the MCB would then proceed to try and honor Duo. But that
doesn't appear to be the case, thus my work-around of the 3rd class that
the SP doesn't know about.

That basically means it's doing exactly what the IdP already did before,
favor active results (i.e. SSO) over inactive methods.

As an aside, these are the sorts of things that I really need people to
test for me. I don't have anything resembling this Duo stuff at OSU, so I
can't begin to test these kinds of things.

-- Scott

[Rich Graves]

If your SP per se doesn't really care, then the SP needn't ask for a specific context. The decision to prefer or require can be made by the IdP (or by Duo, if you tell it not to require enrolment).

We are primarily going with 2-factor based on user or location (Duo "trusted networks"), not by SP.

[David Langenberg]

Keith,

What happens when you get rid of your dummy class and try to access that SP
as the 2nd SP of the session (SSO through to it?). Also, what version of
the MCB are you trying this with?

Dave

Post by Wessel, Keith
Hi, all,
We're getting our plans together to put the MCB and Duo in place, and I'm
preparing a demo for our security folks to help us make some decisions.
I'd like to set up a service provider to require Duo if available and, if
not, to settle for username/password. This would allow users from two
different assurance levels in that the application could handle accordingly.
But I'm hitting a snag. With my authnContextClassRef set to the duo
context followed by the password context, and my initial context in the MCB
set only to password, I get prompted to password authenticate. But then I
never get sent to Duo authenticate, presumably because I've already settled
the password context.
Only solution I can think of is to add a 3rd context which uses the
password method that an SP will never ask for and configure it as my only
initial context. If a user is eligible for Duo, the MCB will then try to
satisfy the Duo context as it already knows the user's principal. If the
user is only eligible for password, and since that method has already been
satisfied, the password context will be returned to the service provider.
It feels like a hack to have a 3rd dummy context, though. I was hoping,
after doing password authn, the MCB would then see that Duo was preferred
and do that. No such luck.
Is there a cleaner way to do what I'm trying to do?
Thanks,
Keith
--
To unsubscribe from this list send an email to

[Wessel, Keith]

Was hoping you’d chime in since you’ve probably been down this road, Dave.

I’m on 1.1.2 which is probably part of my problem. 1.2.0 is the latest stable, correct?

When I log in with an SP that specifies no authnContextClassRef then go to my SP that has both listed, duo first, it seems to be honoring my existing password authentication and not giving me the chance to move up.

Keith


From: users-***@shibboleth.net [mailto:users-***@shibboleth.net] On Behalf Of David Langenberg
Sent: Wednesday, August 20, 2014 4:42 PM
To: Shib Users
Subject: Re: MCB with Duo and password as fallback

Keith,

What happens when you get rid of your dummy class and try to access that SP as the 2nd SP of the session (SSO through to it?). Also, what version of the MCB are you trying this with?

Dave

On Wed, Aug 20, 2014 at 3:20 PM, Wessel, Keith <***@illinois.edu<mailto:***@illinois.edu>> wrote:
Hi, all,

We're getting our plans together to put the MCB and Duo in place, and I'm preparing a demo for our security folks to help us make some decisions.

I'd like to set up a service provider to require Duo if available and, if not, to settle for username/password. This would allow users from two different assurance levels in that the application could handle accordingly.

But I'm hitting a snag. With my authnContextClassRef set to the duo context followed by the password context, and my initial context in the MCB set only to password, I get prompted to password authenticate. But then I never get sent to Duo authenticate, presumably because I've already settled the password context.

Only solution I can think of is to add a 3rd context which uses the password method that an SP will never ask for and configure it as my only initial context. If a user is eligible for Duo, the MCB will then try to satisfy the Duo context as it already knows the user's principal. If the user is only eligible for password, and since that method has already been satisfied, the password context will be returned to the service provider.

It feels like a hack to have a 3rd dummy context, though. I was hoping, after doing password authn, the MCB would then see that Duo was preferred and do that. No such luck.

Is there a cleaner way to do what I'm trying to do?

Thanks,
Keith

[David Langenberg]

Try updating. What it's supposed to do in that case is require Duo and if
the user can't meet Duo then just fall back to password.

Dave

Post by Wessel, Keith
Was hoping you’d chime in since you’ve probably been down this road, Dave.
I’m on 1.1.2 which is probably part of my problem. 1.2.0 is the latest
stable, correct?
When I log in with an SP that specifies no authnContextClassRef then go to
my SP that has both listed, duo first, it seems to be honoring my existing
password authentication and not giving me the chance to move up.
Keith
*On Behalf Of *David Langenberg
*Sent:* Wednesday, August 20, 2014 4:42 PM
*To:* Shib Users
*Subject:* Re: MCB with Duo and password as fallback
Keith,
What happens when you get rid of your dummy class and try to access that
SP as the 2nd SP of the session (SSO through to it?). Also, what version
of the MCB are you trying this with?
Dave
Hi, all,
We're getting our plans together to put the MCB and Duo in place, and I'm
preparing a demo for our security folks to help us make some decisions.
I'd like to set up a service provider to require Duo if available and, if
not, to settle for username/password. This would allow users from two
different assurance levels in that the application could handle accordingly.
But I'm hitting a snag. With my authnContextClassRef set to the duo
context followed by the password context, and my initial context in the MCB
set only to password, I get prompted to password authenticate. But then I
never get sent to Duo authenticate, presumably because I've already settled
the password context.
Only solution I can think of is to add a 3rd context which uses the
password method that an SP will never ask for and configure it as my only
initial context. If a user is eligible for Duo, the MCB will then try to
satisfy the Duo context as it already knows the user's principal. If the
user is only eligible for password, and since that method has already been
satisfied, the password context will be returned to the service provider.
It feels like a hack to have a 3rd dummy context, though. I was hoping,
after doing password authn, the MCB would then see that Duo was preferred
and do that. No such luck.
Is there a cleaner way to do what I'm trying to do?
Thanks,
Keith
--
To unsubscribe from this list send an email to
--
David Langenberg
Identity & Access Management
The University of Chicago
--
To unsubscribe from this list send an email to

[Wessel, Keith]

Thanks, I should have tried that first, apologies. Is 1.2.0 stable? Or should I go for 1.1.4?

Keith


From: users-***@shibboleth.net [mailto:users-***@shibboleth.net] On Behalf Of David Langenberg
Sent: Wednesday, August 20, 2014 4:52 PM
To: Shib Users
Subject: Re: MCB with Duo and password as fallback

Try updating. What it's supposed to do in that case is require Duo and if the user can't meet Duo then just fall back to password.

Dave

On Wed, Aug 20, 2014 at 3:48 PM, Wessel, Keith <***@illinois.edu<mailto:***@illinois.edu>> wrote:
Was hoping you’d chime in since you’ve probably been down this road, Dave.

I’m on 1.1.2 which is probably part of my problem. 1.2.0 is the latest stable, correct?

When I log in with an SP that specifies no authnContextClassRef then go to my SP that has both listed, duo first, it seems to be honoring my existing password authentication and not giving me the chance to move up.

Keith


From: users-***@shibboleth.net<mailto:users-***@shibboleth.net> [mailto:users-***@shibboleth.net<mailto:users-***@shibboleth.net>] On Behalf Of David Langenberg
Sent: Wednesday, August 20, 2014 4:42 PM

To: Shib Users
Subject: Re: MCB with Duo and password as fallback

Keith,

What happens when you get rid of your dummy class and try to access that SP as the 2nd SP of the session (SSO through to it?). Also, what version of the MCB are you trying this with?

Dave

On Wed, Aug 20, 2014 at 3:20 PM, Wessel, Keith <***@illinois.edu<mailto:***@illinois.edu>> wrote:
Hi, all,

We're getting our plans together to put the MCB and Duo in place, and I'm preparing a demo for our security folks to help us make some decisions.

I'd like to set up a service provider to require Duo if available and, if not, to settle for username/password. This would allow users from two different assurance levels in that the application could handle accordingly.

But I'm hitting a snag. With my authnContextClassRef set to the duo context followed by the password context, and my initial context in the MCB set only to password, I get prompted to password authenticate. But then I never get sent to Duo authenticate, presumably because I've already settled the password context.

Only solution I can think of is to add a 3rd context which uses the password method that an SP will never ask for and configure it as my only initial context. If a user is eligible for Duo, the MCB will then try to satisfy the Duo context as it already knows the user's principal. If the user is only eligible for password, and since that method has already been satisfied, the password context will be returned to the service provider.

It feels like a hack to have a 3rd dummy context, though. I was hoping, after doing password authn, the MCB would then see that Duo was preferred and do that. No such luck.

Is there a cleaner way to do what I'm trying to do?

Thanks,
Keith
--
To unsubscribe from this list send an email to users-***@shibboleth.net<mailto:users-***@shibboleth.net>
--
David Langenberg
Identity & Access Management
The University of Chicago

[David Langenberg]

1.1.4 is the latest stable, but an issue with forceAuthn, so if you have
forceAuthn SPs you may want to just plunge for 1.2.0.

Dave

Post by Wessel, Keith
Thanks, I should have tried that first, apologies. Is 1.2.0 stable? Or
should I go for 1.1.4?
Keith
*On Behalf Of *David Langenberg
*Sent:* Wednesday, August 20, 2014 4:52 PM
*To:* Shib Users
*Subject:* Re: MCB with Duo and password as fallback
Try updating. What it's supposed to do in that case is require Duo and if
the user can't meet Duo then just fall back to password.
Dave
Was hoping you’d chime in since you’ve probably been down this road, Dave.
I’m on 1.1.2 which is probably part of my problem. 1.2.0 is the latest
stable, correct?
When I log in with an SP that specifies no authnContextClassRef then go to
my SP that has both listed, duo first, it seems to be honoring my existing
password authentication and not giving me the chance to move up.
Keith
*On Behalf Of *David Langenberg
*Sent:* Wednesday, August 20, 2014 4:42 PM
*To:* Shib Users
*Subject:* Re: MCB with Duo and password as fallback
Keith,
What happens when you get rid of your dummy class and try to access that
SP as the 2nd SP of the session (SSO through to it?). Also, what version
of the MCB are you trying this with?
Dave
Hi, all,
We're getting our plans together to put the MCB and Duo in place, and I'm
preparing a demo for our security folks to help us make some decisions.
I'd like to set up a service provider to require Duo if available and, if
not, to settle for username/password. This would allow users from two
different assurance levels in that the application could handle accordingly.
But I'm hitting a snag. With my authnContextClassRef set to the duo
context followed by the password context, and my initial context in the MCB
set only to password, I get prompted to password authenticate. But then I
never get sent to Duo authenticate, presumably because I've already settled
the password context.
Only solution I can think of is to add a 3rd context which uses the
password method that an SP will never ask for and configure it as my only
initial context. If a user is eligible for Duo, the MCB will then try to
satisfy the Duo context as it already knows the user's principal. If the
user is only eligible for password, and since that method has already been
satisfied, the password context will be returned to the service provider.
It feels like a hack to have a 3rd dummy context, though. I was hoping,
after doing password authn, the MCB would then see that Duo was preferred
and do that. No such luck.
Is there a cleaner way to do what I'm trying to do?
Thanks,
Keith
--
To unsubscribe from this list send an email to
--
David Langenberg
Identity & Access Management
The University of Chicago
--
To unsubscribe from this list send an email to
--
David Langenberg
Identity & Access Management
The University of Chicago
--
To unsubscribe from this list send an email to

[Wessel, Keith]

Unfortunately, 1.1.4 doesn’t seem to act any differently for me. Same result going straight to the SP configured to ask for both, and same behavior going to the other SP configured for nothing specific first then the specially configured SP. It’s never asking for Duo.

I tried removing Password from the config on the SP just to make sure I hadn’t broken something, and it came up right away asking for Duo auth.

For what it’s worth, when I was running 1.1.2, the last line in my idp-process.log on start-up advertised 1.1.1. I always assumed this was just a string that didn’t get updated. Now that I’m on 1.1.4, the last line on start-up says:

17:06:38.905 - INFO [edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginServlet:92] [session=] - 1.1.2 (2014-04-11)

Since it’s no longer saying 1.1.1, I’m going to assume it upgraded to 1.1.4.

I’ll try 1.2.0 and see if I have any better luck.

Keith

From: users-***@shibboleth.net [mailto:users-***@shibboleth.net] On Behalf Of David Langenberg
Sent: Wednesday, August 20, 2014 5:00 PM
To: Shib Users
Subject: Re: MCB with Duo and password as fallback

1.1.4 is the latest stable, but an issue with forceAuthn, so if you have forceAuthn SPs you may want to just plunge for 1.2.0.

Dave

On Wed, Aug 20, 2014 at 3:53 PM, Wessel, Keith <***@illinois.edu<mailto:***@illinois.edu>> wrote:
Thanks, I should have tried that first, apologies. Is 1.2.0 stable? Or should I go for 1.1.4?

Keith


From: users-***@shibboleth.net<mailto:users-***@shibboleth.net> [mailto:users-***@shibboleth.net<mailto:users-***@shibboleth.net>] On Behalf Of David Langenberg
Sent: Wednesday, August 20, 2014 4:52 PM

To: Shib Users
Subject: Re: MCB with Duo and password as fallback

Try updating. What it's supposed to do in that case is require Duo and if the user can't meet Duo then just fall back to password.

Dave

On Wed, Aug 20, 2014 at 3:48 PM, Wessel, Keith <***@illinois.edu<mailto:***@illinois.edu>> wrote:
Was hoping you’d chime in since you’ve probably been down this road, Dave.

I’m on 1.1.2 which is probably part of my problem. 1.2.0 is the latest stable, correct?

When I log in with an SP that specifies no authnContextClassRef then go to my SP that has both listed, duo first, it seems to be honoring my existing password authentication and not giving me the chance to move up.

Keith


From: users-***@shibboleth.net<mailto:users-***@shibboleth.net> [mailto:users-***@shibboleth.net<mailto:users-***@shibboleth.net>] On Behalf Of David Langenberg
Sent: Wednesday, August 20, 2014 4:42 PM

To: Shib Users
Subject: Re: MCB with Duo and password as fallback

Keith,

What happens when you get rid of your dummy class and try to access that SP as the 2nd SP of the session (SSO through to it?). Also, what version of the MCB are you trying this with?

Dave

On Wed, Aug 20, 2014 at 3:20 PM, Wessel, Keith <***@illinois.edu<mailto:***@illinois.edu>> wrote:
Hi, all,

We're getting our plans together to put the MCB and Duo in place, and I'm preparing a demo for our security folks to help us make some decisions.

I'd like to set up a service provider to require Duo if available and, if not, to settle for username/password. This would allow users from two different assurance levels in that the application could handle accordingly.

But I'm hitting a snag. With my authnContextClassRef set to the duo context followed by the password context, and my initial context in the MCB set only to password, I get prompted to password authenticate. But then I never get sent to Duo authenticate, presumably because I've already settled the password context.

Only solution I can think of is to add a 3rd context which uses the password method that an SP will never ask for and configure it as my only initial context. If a user is eligible for Duo, the MCB will then try to satisfy the Duo context as it already knows the user's principal. If the user is only eligible for password, and since that method has already been satisfied, the password context will be returned to the service provider.

It feels like a hack to have a 3rd dummy context, though. I was hoping, after doing password authn, the MCB would then see that Duo was preferred and do that. No such luck.

Is there a cleaner way to do what I'm trying to do?

Thanks,
Keith
--
To unsubscribe from this list send an email to users-***@shibboleth.net<mailto:users-***@shibboleth.net>
--
David Langenberg
Identity & Access Management
The University of Chicago
--
To unsubscribe from this list send an email to users-***@shibboleth.net<mailto:users-***@shibboleth.net>
--
David Langenberg
Identity & Access Management
The University of Chicago

[Paul Hethmon]

On Aug 20, 2014, at 6:14 PM, Wessel, Keith <kwessel-nzINlOoChub2fBVCVOL8/***@public.gmane.org<mailto:kwessel-nzINlOoChub2fBVCVOL8/***@public.gmane.org>> wrote:

Unfortunately, 1.1.4 doesn’t seem to act any differently for me. Same result going straight to the SP configured to ask for both, and same behavior going to the other SP configured for nothing specific first then the specially configured SP. It’s never asking for Duo.


Keith,

How do you have your MCB config setup? It sounds like both password and duo end up being equal. I'm thinking you will need something like this:

<context name="password" method="password">
<allowedContexts>duo</allowedContexts>
</context>

<context name="duo" method="duo" />

So Duo is allowed to be used for password, but password is not allowed for Duo. Then, if you are wanting to force Duo, have the SP send only Duo. If the SP sends both password and Duo, then while one may be preferred by the order given, it still means both are acceptable.

Where the greater control comes in is to limit the user to only Duo. So you can say this user is only allowed Duo while the SP can allow either choice.

Paul


Paul Hethmon
Chief Software Architect
paul.hethmon-NC06ibP+gDOju1H+chf1WFaTQe2KTcn/@public.gmane.org<mailto:paul.hethmon-NC06ibP+gDOju1H+chf1WFaTQe2KTcn/@public.gmane.org>

[Cantor, Scott]

Post by Paul Hethmon
So Duo is allowed to be used for password, but password is not allowed
for Duo. Then, if you are wanting to force Duo, have the SP send only
Duo. If the SP sends both password and Duo, then while one may be
preferred by the order given, it still means both are acceptable.

Right, but the IdP today doesn't prefer the first one that can be tried,
but the first one that's already active. If the MCB does that too, it
shares that quirk. Whether you want to consider that a bug or not is up to
you, but I did/do consider it a bug in the IdP.

In V3, it's controlled with the idp.authn.favorSSO property, which
defaults true at the moment, but I'm still debating that. While it's
compatible that way, it's not really correct, and changing that behavior
doesn't really break anything.

-- Scott

[Paul Hethmon]

On Aug 20, 2014, at 8:28 PM, Cantor, Scott <cantor.2-ZbGKxL/***@public.gmane.org<mailto:***@osu.edu>> wrote:

So Duo is allowed to be used for password, but password is not allowed
for Duo. Then, if you are wanting to force Duo, have the SP send only
Duo. If the SP sends both password and Duo, then while one may be
preferred by the order given, it still means both are acceptable.

Right, but the IdP today doesn't prefer the first one that can be tried,
but the first one that's already active. If the MCB does that too, it
shares that quirk. Whether you want to consider that a bug or not is up to
you, but I did/do consider it a bug in the IdP.

MCB will satisfy the requested AuthnContext that meets the requirements between what the SP requested and what the user is allowed. It also allows the administrator to specify that one context can satisfy another context, yielding an ordered list. What complicates it more at this point, is that contexts are satisfied by methods. So, a method being the actual way a user authenticates. A given method can be specified to satisfy multiple context values which ends up rendering them the same in practice. That is because when a user authenticates successfully, they have completed a method. Then any context which uses that method can be satisfied.

So it ends up allowing the ordering of contexts and restricting which contexts a user is allowed.

Paul


Paul Hethmon
Chief Software Architect
paul.hethmon-NC06ibP+gDOju1H+chf1WFaTQe2KTcn/@public.gmane.org<mailto:paul.hethmon-NC06ibP+gDOju1H+chf1WFaTQe2KTcn/@public.gmane.org>

[Cantor, Scott]

Post by Paul Hethmon
A given method can be specified to satisfy multiple context values which
ends up rendering them the same in practice. That is because when a user
authenticates successfully, they have completed a method. Then any
context which uses that method can be satisfied.

Yes, but my point is that SAML requires that the IdP try and honor the
requested contexts in the order they're listed. It doesn't qualify that
requirement with "unless a later one can be met without actually
prompting". It's not irrational to take that view, because users are
obviously happier, but it's not actually something the standard would
justify, and SPs routinely get confused when this happens, so it's clearly
not what they want.

In other words, the strict approach is to say, if the SP requests X, and
if X is possible to attempt, you attempt X, even if the user already
completed Y and Y is the second one in the request. Replace X with Duo and
Y with password in this case.

With V3, the flow selection can be configured with either interpretation.
But if V2 hadn't done it the other way, I wouldn't have implemented that,
because the standard is fairly clear about it.

-- Scott

[Wessel, Keith]

To make matters more complicated, the MCB doesn't even attempt X if both X and Y are requested but only Y is configured as an _initial_ context. Since Duo requires that password first be completed, then password is configured as initial. The MCB does that then sees it has a completed method that satisfies a context, even if I'm eligible for the higher context and it was preferred by the SP.

Sadly, I tried with 1.2.0, and same result... Which, based on Paul's explanation, means it's doing what it's designed to do.

Ideally, like Scott said, my SP could request multiple methods in priority order and the IDP would give the user the chance to use the highest one that they're eligible to use even if they're already authenticated at a lower level.

My earlier hack might work -- the 3rd context that also uses the password method. I'm still exploring for other options.

Keith

-----Original Message-----
From: users-bounces-***@public.gmane.org [mailto:users-bounces-***@public.gmane.org] On Behalf Of Cantor, Scott
Sent: Wednesday, August 20, 2014 8:22 PM
To: Shib Users
Subject: Re: MCB with Duo and password as fallback

Post by Paul Hethmon
A given method can be specified to satisfy multiple context values
which ends up rendering them the same in practice. That is because when
a user authenticates successfully, they have completed a method. Then
any context which uses that method can be satisfied.

Yes, but my point is that SAML requires that the IdP try and honor the requested contexts in the order they're listed. It doesn't qualify that requirement with "unless a later one can be met without actually prompting". It's not irrational to take that view, because users are obviously happier, but it's not actually something the standard would justify, and SPs routinely get confused when this happens, so it's clearly not what they want.

In other words, the strict approach is to say, if the SP requests X, and if X is possible to attempt, you attempt X, even if the user already completed Y and Y is the second one in the request. Replace X with Duo and Y with password in this case.

With V3, the flow selection can be configured with either interpretation.
But if V2 hadn't done it the other way, I wouldn't have implemented that, because the standard is fairly clear about it.

-- Scott

--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org

[Paul Hethmon]

On Aug 20, 2014, at 9:21 PM, Cantor, Scott <cantor.2-ZbGKxL/***@public.gmane.org<mailto:***@osu.edu>> wrote:

Yes, but my point is that SAML requires that the IdP try and honor the
requested contexts in the order they're listed. It doesn't qualify that
requirement with "unless a later one can be met without actually
prompting". It's not irrational to take that view, because users are
obviously happier, but it's not actually something the standard would
justify, and SPs routinely get confused when this happens, so it's clearly
not what they want.

It does honor the order given by the SP.

In other words, the strict approach is to say, if the SP requests X, and
if X is possible to attempt, you attempt X, even if the user already
completed Y and Y is the second one in the request. Replace X with Duo and
Y with password in this case.

So how the MCB would handle this would be up to the configuration. Assuming the two contexts are handled by different methods then X will be presented first as requested. However, if the second SP request were for method Y and Y is not satisfied by X, then the MCB would require the user to satisfy Y instead of using previous session.

If X and Y used the same method, then the second SP request would be granted as a previous session no matter which context was requested, since the user has already satisfied the method that covers both contexts.

I don't feel I'm adequately explaining what it can do here.

Paul Hethmon
Chief Software Architect
paul.hethmon-NC06ibP+gDOju1H+chf1WFaTQe2KTcn/@public.gmane.org<mailto:paul.hethmon-NC06ibP+gDOju1H+chf1WFaTQe2KTcn/@public.gmane.org>

[Cantor, Scott]

Post by Paul Hethmon
It does honor the order given by the SP.

Not based on what Keith is saying. Unless he's missing an option...

Post by Paul Hethmon
So how the MCB would handle this would be up to the configuration.
Assuming the two contexts are handled by different methods then X will be
presented first as requested. However, if the second SP request were for
method Y and Y is not satisfied by X, then the MCB would require the user
to satisfy Y instead of using previous session.

Keith is saying that it's not presenting X, because Y's already been used
and it satisfies the SP as the context requested in second position.
That's what I'm terming "favoring SSO".

Post by Paul Hethmon
If X and Y used the same method, then the second SP request would be
granted as a previous session no matter which context was requested,
since the user has already satisfied the method that covers both contexts.

Yes. We're actually talking about a simpler case where X and Y are not
supported by the same underlying method so they're at least disjoint.

Things get much more complex when you change that, but I did handle that
in V3 because not only do flows (methods) advertise the contexts they
support, but *results* also do. So you might have a single flow handling X
and Y, but when you do it once, you only got Y. So an SP that requests X
won't get SSO, the IdP knows to re-run the single method because the
result before wasn't good enough.

Post by Paul Hethmon
I don't feel I'm adequately explaining what it can do here.

It's very difficult to explain any of this, which is why it has little
chance of wide adoption. That's an aside, but it's something the higher
ups need to get clear. You can't deploy what you can't understand. I can
barely understand what the new version can do and I wrote it.

-- Scott

[Wessel, Keith]

Where my situation gets tricky is that Duo can't be an initial authentication context. The Duo submodule uses a principal from another submodule. In my case, the only context that can be triggered initially, regardless of what was requested, is password.

If both Duo and Password could be initial contexts, it'd work as Paul describes.

But in filling the initial context, I satisfy password, and the MCB says "good enough."

So far, it's just unfortunate, but I can live with that.

Where I think something's wrong is when I go to my simple SP that specifies no authn contexts before going to the one that has duo then password configured. If the MCB is truly honoring the order of the string, it should prompt me to use Duo. It has the principal, I'm eligible for Duo. But it simply uses my previous session. I've satisfied password, so we use password.

I thought I tested this during acceptance testing and saw behavior like what Paul described. I can't get it to work that way now, though.

I'll keep digging.

Keith


-----Original Message-----
From: users-bounces-***@public.gmane.org [mailto:users-bounces-***@public.gmane.org] On Behalf Of Cantor, Scott
Sent: Wednesday, August 20, 2014 9:01 PM
To: Shib Users
Subject: Re: MCB with Duo and password as fallback

Post by Paul Hethmon
It does honor the order given by the SP.

Not based on what Keith is saying. Unless he's missing an option...

Post by Paul Hethmon
So how the MCB would handle this would be up to the configuration.
Assuming the two contexts are handled by different methods then X will
be presented first as requested. However, if the second SP request were
for method Y and Y is not satisfied by X, then the MCB would require
the user to satisfy Y instead of using previous session.

Keith is saying that it's not presenting X, because Y's already been used and it satisfies the SP as the context requested in second position.
That's what I'm terming "favoring SSO".

Post by Paul Hethmon
If X and Y used the same method, then the second SP request would be
granted as a previous session no matter which context was requested,
since the user has already satisfied the method that covers both contexts.

Yes. We're actually talking about a simpler case where X and Y are not supported by the same underlying method so they're at least disjoint.

Things get much more complex when you change that, but I did handle that in V3 because not only do flows (methods) advertise the contexts they support, but *results* also do. So you might have a single flow handling X and Y, but when you do it once, you only got Y. So an SP that requests X won't get SSO, the IdP knows to re-run the single method because the result before wasn't good enough.

Post by Paul Hethmon
I don't feel I'm adequately explaining what it can do here.

It's very difficult to explain any of this, which is why it has little chance of wide adoption. That's an aside, but it's something the higher ups need to get clear. You can't deploy what you can't understand. I can barely understand what the new version can do and I wrote it.

-- Scott

--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org

[Cantor, Scott]

Post by Wessel, Keith
If both Duo and Password could be initial contexts, it'd work as Paul describes.

I think that's avoiding the question, because an initial method is (I
thought) only used when there's no session.

Post by Wessel, Keith
I thought I tested this during acceptance testing and saw behavior like
what Paul described. I can't get it to work that way now, though.

Dunno, it's definitely known behavior without the MCB.

-- Scott

[Wessel, Keith]

You are correct, Scott. Initial contexts are used when the user doesn't yet have a session. So, that doesn't come into play for previous session handling. My point was simply that, in the case that a new user comes along, there seems to be a problem satisfying X if Y is allowed as an initial context but X isn't. Y gets satisfied, and the MCB runs with it.

Previous sessions are a different but somewhat similar situation. If the SP asks for X and Y and I already have a session with Y, the MCB again seems to run with it.

Keith


-----Original Message-----
From: users-bounces-***@public.gmane.org [mailto:users-bounces-***@public.gmane.org] On Behalf Of Cantor, Scott
Sent: Wednesday, August 20, 2014 9:16 PM
To: Shib Users
Subject: Re: MCB with Duo and password as fallback

Post by Wessel, Keith
If both Duo and Password could be initial contexts, it'd work as Paul describes.

I think that's avoiding the question, because an initial method is (I
thought) only used when there's no session.

Post by Wessel, Keith
I thought I tested this during acceptance testing and saw behavior like
what Paul described. I can't get it to work that way now, though.

Dunno, it's definitely known behavior without the MCB.

-- Scott

--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org

[Cantor, Scott]

Post by Wessel, Keith
You are correct, Scott. Initial contexts are used when the user doesn't
yet have a session. So, that doesn't come into play for previous session
handling. My point was simply that, in the case that a new user comes
along, there seems to be a problem satisfying X if Y is allowed as an
initial context but X isn't. Y gets satisfied, and the MCB runs with it.

Well, a problem in the strictest sense. In the more general sense the SP
did say password was ok, so the problem is in not getting the best you can
get, in exchange for more user convenience.

There's a valid case to be made that if you want something better, you
shouldn't accept something worse and expect not to get it. This is
exacerbated if the user has the ability to choose or to signal to the
strong method that they'd prefer the weak. Given a choice, I'm going to
pick the thing I don't have to pull out my phone for.

Strong auth basically doesn't work if you also allow weak, IMHO.

Post by Wessel, Keith
Previous sessions are a different but somewhat similar situation. If the
SP asks for X and Y and I already have a session with Y, the MCB again
seems to run with it.

It's exactly the same situation; once you're past "initial", you have a
session and it operates the same for that SP as the next one. It certainly
ought to, anything else would be very confusing.

-- Scott

[Wessel, Keith]

Correct: strong auth doesn't work if you also allow weak. Our idea is to use the authncontext passed back into the application to see how the user authenticated and grant access accordingly.

For instance, our password changing tool allows end users to change their own passwords and IT folks to change others' passwords in addition. We could only allow changing of others' passwords for an authorized user if (1) they're authorized and (2) they logged in using MFA. In that case, we're detecting the difference inside the application. If you're getting the same thing with just a password as you are with MFA, I'm with you: why bother pulling out your phone?

Keith


-----Original Message-----
From: users-bounces-***@public.gmane.org [mailto:users-bounces-***@public.gmane.org] On Behalf Of Cantor, Scott
Sent: Wednesday, August 20, 2014 9:35 PM
To: Shib Users
Subject: Re: MCB with Duo and password as fallback

Post by Wessel, Keith
You are correct, Scott. Initial contexts are used when the user doesn't
yet have a session. So, that doesn't come into play for previous
session handling. My point was simply that, in the case that a new user
comes along, there seems to be a problem satisfying X if Y is allowed
as an initial context but X isn't. Y gets satisfied, and the MCB runs with it.

Well, a problem in the strictest sense. In the more general sense the SP did say password was ok, so the problem is in not getting the best you can get, in exchange for more user convenience.

There's a valid case to be made that if you want something better, you shouldn't accept something worse and expect not to get it. This is exacerbated if the user has the ability to choose or to signal to the strong method that they'd prefer the weak. Given a choice, I'm going to pick the thing I don't have to pull out my phone for.

Strong auth basically doesn't work if you also allow weak, IMHO.

Post by Wessel, Keith
Previous sessions are a different but somewhat similar situation. If
the SP asks for X and Y and I already have a session with Y, the MCB
again seems to run with it.

It's exactly the same situation; once you're past "initial", you have a session and it operates the same for that SP as the next one. It certainly ought to, anything else would be very confusing.

-- Scott

--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org

[Cantor, Scott]

Post by Wessel, Keith
Correct: strong auth doesn't work if you also allow weak. Our idea is to
use the authncontext passed back into the application to see how the user
authenticated and grant access accordingly.

Oh, I know. I'm just saying that allowing both at the app means the user
has every incentive to try and do as little as he/she can, and you have
the problem of the lack of privilege once they login and realize they
should have just taken their phone out.

I know that's what you're trying to fix by listing Duo first, and that's
why I fixed this in the IdP redesign.

-- Scott

[Tom Scavo]

Post by Wessel, Keith
Where my situation gets tricky is that Duo can't be an initial authentication context. The Duo submodule uses a principal from another submodule. In my case, the only context that can be triggered initially, regardless of what was requested, is password.

I don't know what Duo module you're referring to (one distributed with
the MCB?) but essentially you're saying the module doesn't support
step-up authentication.

Tom

[David Langenberg]

Post by Wessel, Keith

Post by Wessel, Keith
Where my situation gets tricky is that Duo can't be an initial

authentication context. The Duo submodule uses a principal from another
submodule. In my case, the only context that can be triggered initially,
regardless of what was requested, is password.
I don't know what Duo module you're referring to (one distributed with
the MCB?) but essentially you're saying the module doesn't support
step-up authentication.

He's referring to the MCB Duo module. The module requires that the user's
identity be previously established by another unspecified method before it
can be called.

Dave

[Michael A Grady]

Post by Tom Scavo

Post by Wessel, Keith
Where my situation gets tricky is that Duo can't be an initial authentication context. The Duo submodule uses a principal from another submodule. In my case, the only context that can be triggered initially, regardless of what was requested, is password.

I don't know what Duo module you're referring to (one distributed with
the MCB?) but essentially you're saying the module doesn't support
step-up authentication.
He's referring to the MCB Duo module. The module requires that the user's identity be previously established by another unspecified method before it can be called.
Dave

Wouldn't think it is the MCB Duo module's "fault", because either it gets invoked or not. It comes down to whether the MCB can currently support the full complexity of use cases some deployers are trying.

If the user had already done password, and the service requesting indicated it only accepted Duo, it will require the user to do Duo. The reported problem seems to come in when the user has already done password as the initial context, and the service will accept either, with Duo listed first. The user is not getting presented the choice to do/"add" Duo.

Does playing games with the two different password contexts, :Password versus :PasswordProtectedContext, make any difference? Listing :Password for initial context, and then having :PasswordProtectedContext as a later context with the same method, and having the service list :PasswordProtectedContext as the 2nd choice? Probably won't make a difference, since both are satisfied by the same method.

--
Michael A. Grady
Senior IAM Consultant, Unicon, Inc.

[Wessel, Keith]

Hi, Mike,

I essentially tried your suggestion: I made a dummy context called urn:mace:incommon:uiuc.edu:authn:password. The SP didn't know about or ask about it. In fact, I didn't even list it as an accepted context for the MCB's handler definition in handler.xml. It had the same method as the usual password method, though.

I authenticated using my password and was returned to the SP with the standard password context. No Duo.

So, no luck there.

Keith


From: users-bounces-***@public.gmane.org [mailto:users-bounces-***@public.gmane.org] On Behalf Of Michael A Grady
Sent: Thursday, August 21, 2014 9:15 AM
To: Shib Users
Subject: Re: MCB with Duo and password as fallback

Post by Wessel, Keith
Where my situation gets tricky is that Duo can't be an initial authentication context. The Duo submodule uses a principal from another submodule. In my case, the only context that can be triggered initially, regardless of what was requested, is password.

I don't know what Duo module you're referring to (one distributed with
the MCB?) but essentially you're saying the module doesn't support
step-up authentication.

He's referring to the MCB Duo module. The module requires that the user's identity be previously established by another unspecified method before it can be called.

Dave


Wouldn't think it is the MCB Duo module's "fault", because either it gets invoked or not. It comes down to whether the MCB can currently support the full complexity of use cases some deployers are trying.

If the user had already done password, and the service requesting indicated it only accepted Duo, it will require the user to do Duo. The reported problem seems to come in when the user has already done password as the initial context, and the service will accept either, with Duo listed first. The user is not getting presented the choice to do/"add" Duo.

Does playing games with the two different password contexts, :Password versus :PasswordProtectedContext, make any difference? Listing :Password for initial context, and then having :PasswordProtectedContext as a later context with the same method, and having the service list :PasswordProtectedContext as the 2nd choice? Probably won't make a difference, since both are satisfied by the same method.

--
Michael A. Grady
Senior IAM Consultant, Unicon, Inc.

[Eric Goodman]

Keith,

This is a fascinating problem and discussion. I see your point about a third context being somewhat of a hack. But I can still see the argument that what you are defining is truly its own third context. Your MCB config allows two contexts, as "must use Duo if you have it" and "may use password only".

But in this case, the password login behavior you are trying to implement is "may use password only *if not a Duo user*" is an acceptable context, right? And if you implemented the password context this way, then the MCB would work exactly as you want it, right? (Never mind that this would likely break all of your other password-context based SPs!) That is, the password context you want to allow is subtly different than the one you're re-using. For example, if the Duo login for a Duo user was attempted but actually failed, you'd get the same behavior you're experiencing now, and your context listing indicates that it's still okay for the Duo user to login without being Duo authenticated. So I can see the argument that you'd need a separate password context to address what you're trying to implement.

I do understand that my argument is somewhat academic, because if the Duo authentication was actually attempted before falling over to the password context (and there are reasonable arguments that it should), it would still likely be "good enough" for your immediate issue, but from an IdP/SAML messaging design standpoint I can see the argument that you are trying to link these two independent contexts in a way that's not obviously the "right way" for your use case.

--- Eric



From: users-bounces-***@public.gmane.org [mailto:users-bounces-***@public.gmane.org] On Behalf Of Wessel, Keith
Sent: Thursday, August 21, 2014 7:28 AM
To: Shib Users
Subject: RE: MCB with Duo and password as fallback

Hi, Mike,

I essentially tried your suggestion: I made a dummy context called urn:mace:incommon:uiuc.edu:authn:password. The SP didn't know about or ask about it. In fact, I didn't even list it as an accepted context for the MCB's handler definition in handler.xml. It had the same method as the usual password method, though.

I authenticated using my password and was returned to the SP with the standard password context. No Duo.

So, no luck there.

Keith


From: users-bounces-***@public.gmane.org<mailto:users-bounces-***@public.gmane.org> [mailto:users-bounces-***@public.gmane.org] On Behalf Of Michael A Grady
Sent: Thursday, August 21, 2014 9:15 AM
To: Shib Users
Subject: Re: MCB with Duo and password as fallback

Post by Wessel, Keith
Where my situation gets tricky is that Duo can't be an initial authentication context. The Duo submodule uses a principal from another submodule. In my case, the only context that can be triggered initially, regardless of what was requested, is password.

I don't know what Duo module you're referring to (one distributed with
the MCB?) but essentially you're saying the module doesn't support
step-up authentication.

He's referring to the MCB Duo module. The module requires that the user's identity be previously established by another unspecified method before it can be called.

Dave


Wouldn't think it is the MCB Duo module's "fault", because either it gets invoked or not. It comes down to whether the MCB can currently support the full complexity of use cases some deployers are trying.

If the user had already done password, and the service requesting indicated it only accepted Duo, it will require the user to do Duo. The reported problem seems to come in when the user has already done password as the initial context, and the service will accept either, with Duo listed first. The user is not getting presented the choice to do/"add" Duo.

Does playing games with the two different password contexts, :Password versus :PasswordProtectedContext, make any difference? Listing :Password for initial context, and then having :PasswordProtectedContext as a later context with the same method, and having the service list :PasswordProtectedContext as the 2nd choice? Probably won't make a difference, since both are satisfied by the same method.

--
Michael A. Grady
Senior IAM Consultant, Unicon, Inc.

[Wessel, Keith]

Hey, Eric,

An interesting way to look at it... and I agree.

Unfortunately, the MCB doesn't seem to.

I have my initial context list set to one context: my new passworc context, let's call it urn:mace:incommon:uiuc.edu:Password. This context is configured to use the same password method as the standard urn:oasis:...:Password context.

I have my SP requesting Duo followed by the standard Password context. It knows nothing about this new context that the MCB has for an initial one.

I go to the MCB and am prompted to password-authenticate. Then, based on how I'm interpresting the logs, it sees that I've already satisfied the password method and follows the path of least effort for the USER. It sees that this method satisfies the standard password context and returns that one. Duo's ignored.

Keith


From: users-bounces-***@public.gmane.org [mailto:users-bounces-***@public.gmane.org] On Behalf Of Eric Goodman
Sent: Friday, August 22, 2014 6:23 PM
To: Shib Users
Subject: RE: MCB with Duo and password as fallback

Keith,

This is a fascinating problem and discussion. I see your point about a third context being somewhat of a hack. But I can still see the argument that what you are defining is truly its own third context. Your MCB config allows two contexts, as "must use Duo if you have it" and "may use password only".

But in this case, the password login behavior you are trying to implement is "may use password only *if not a Duo user*" is an acceptable context, right? And if you implemented the password context this way, then the MCB would work exactly as you want it, right? (Never mind that this would likely break all of your other password-context based SPs!) That is, the password context you want to allow is subtly different than the one you're re-using. For example, if the Duo login for a Duo user was attempted but actually failed, you'd get the same behavior you're experiencing now, and your context listing indicates that it's still okay for the Duo user to login without being Duo authenticated. So I can see the argument that you'd need a separate password context to address what you're trying to implement.

I do understand that my argument is somewhat academic, because if the Duo authentication was actually attempted before falling over to the password context (and there are reasonable arguments that it should), it would still likely be "good enough" for your immediate issue, but from an IdP/SAML messaging design standpoint I can see the argument that you are trying to link these two independent contexts in a way that's not obviously the "right way" for your use case.

--- Eric



From: users-bounces-***@public.gmane.org<mailto:users-bounces-***@public.gmane.org> [mailto:users-bounces-***@public.gmane.org] On Behalf Of Wessel, Keith
Sent: Thursday, August 21, 2014 7:28 AM
To: Shib Users
Subject: RE: MCB with Duo and password as fallback

Hi, Mike,

I essentially tried your suggestion: I made a dummy context called urn:mace:incommon:uiuc.edu:authn:password. The SP didn't know about or ask about it. In fact, I didn't even list it as an accepted context for the MCB's handler definition in handler.xml. It had the same method as the usual password method, though.

I authenticated using my password and was returned to the SP with the standard password context. No Duo.

So, no luck there.

Keith


From: users-bounces-***@public.gmane.org<mailto:users-bounces-***@public.gmane.org> [mailto:users-bounces-***@public.gmane.org] On Behalf Of Michael A Grady
Sent: Thursday, August 21, 2014 9:15 AM
To: Shib Users
Subject: Re: MCB with Duo and password as fallback

Post by Wessel, Keith
Where my situation gets tricky is that Duo can't be an initial authentication context. The Duo submodule uses a principal from another submodule. In my case, the only context that can be triggered initially, regardless of what was requested, is password.

I don't know what Duo module you're referring to (one distributed with
the MCB?) but essentially you're saying the module doesn't support
step-up authentication.

He's referring to the MCB Duo module. The module requires that the user's identity be previously established by another unspecified method before it can be called.

Dave


Wouldn't think it is the MCB Duo module's "fault", because either it gets invoked or not. It comes down to whether the MCB can currently support the full complexity of use cases some deployers are trying.

If the user had already done password, and the service requesting indicated it only accepted Duo, it will require the user to do Duo. The reported problem seems to come in when the user has already done password as the initial context, and the service will accept either, with Duo listed first. The user is not getting presented the choice to do/"add" Duo.

Does playing games with the two different password contexts, :Password versus :PasswordProtectedContext, make any difference? Listing :Password for initial context, and then having :PasswordProtectedContext as a later context with the same method, and having the service list :PasswordProtectedContext as the 2nd choice? Probably won't make a difference, since both are satisfied by the same method.

--
Michael A. Grady
Senior IAM Consultant, Unicon, Inc.

[Tom Scavo]

Post by Cantor, Scott

Post by Paul Hethmon
I don't feel I'm adequately explaining what it can do here.

It's very difficult to explain any of this, which is why it has little
chance of wide adoption.

I agree, which is why I think single-factor IdPs (and IdP Proxies)
will prevail in the end.

Tom

[Cantor, Scott]

Post by Tom Scavo
I agree, which is why I think single-factor IdPs (and IdP Proxies)
will prevail in the end.

There are plenty of very simple and easy to deploy MFA approaches, such as
SecurID. We just need options that aren't proprietary/expensive.

-- Scott

[Wessel, Keith]

Just to confirm, Paul. You said:

If the SP sends both password and Duo, then while one may be preferred by the order given, it still means both are acceptable.

Does that mean that if one, say password, is already met, Duo won't be attempted?

Keith


From: users-bounces-***@public.gmane.org [mailto:users-bounces-***@public.gmane.org] On Behalf Of Paul Hethmon
Sent: Wednesday, August 20, 2014 7:16 PM
To: Shibboleth Users
Subject: Re: MCB with Duo and password as fallback

On Aug 20, 2014, at 6:14 PM, Wessel, Keith <kwessel-nzINlOoChub2fBVCVOL8/***@public.gmane.org<mailto:kwessel-nzINlOoChub2fBVCVOL8/***@public.gmane.org>> wrote:


Unfortunately, 1.1.4 doesn't seem to act any differently for me. Same result going straight to the SP configured to ask for both, and same behavior going to the other SP configured for nothing specific first then the specially configured SP. It's never asking for Duo.


Keith,

How do you have your MCB config setup? It sounds like both password and duo end up being equal. I'm thinking you will need something like this:

<context name="password" method="password">
<allowedContexts>duo</allowedContexts>
</context>

<context name="duo" method="duo" />

So Duo is allowed to be used for password, but password is not allowed for Duo. Then, if you are wanting to force Duo, have the SP send only Duo. If the SP sends both password and Duo, then while one may be preferred by the order given, it still means both are acceptable.

Where the greater control comes in is to limit the user to only Duo. So you can say this user is only allowed Duo while the SP can allow either choice.

Paul


Paul Hethmon
Chief Software Architect
paul.hethmon-NC06ibP+gDOju1H+chf1WFaTQe2KTcn/@public.gmane.org<mailto:paul.hethmon-NC06ibP+gDOju1H+chf1WFaTQe2KTcn/@public.gmane.org>

[Paul Hethmon]

On Aug 20, 2014, at 9:34 PM, Wessel, Keith <kwessel-nzINlOoChub2fBVCVOL8/***@public.gmane.org<mailto:kwessel-nzINlOoChub2fBVCVOL8/***@public.gmane.org>> wrote:

Just to confirm, Paul. You said:

If the SP sends both password and Duo, then while one may be preferred by the order given, it still means both are acceptable.

Does that mean that if one, say password, is already met, Duo won’t be attempted?

Yes

I think I need to understand how the Duo module is implemented in order to say how it needs to be configured.

Paul

Paul Hethmon
Chief Software Architect
paul.hethmon-NC06ibP+gDOju1H+chf1WFaTQe2KTcn/@public.gmane.org<mailto:paul.hethmon-NC06ibP+gDOju1H+chf1WFaTQe2KTcn/@public.gmane.org>

[Tom Scavo]

On Wed, Aug 20, 2014 at 9:48 PM, Paul Hethmon

Post by Paul Hethmon
I think I need to understand how the Duo module is implemented in order to
say how it needs to be configured.

Authentication via the second (mobile) factor is controlled by the
application (or IdP login handler): once the user has been
authenticated with a username/password, a user-specific iframe is
presented (if using the Duo Web SDK) or the user identifier (usually
ePPN) is transmitted to the Duo service (if using the Duo Auth API).
If the application receives a login request and the user already has a
session, the username/password step can be skipped since the user is
already known (ignoring ForceAuthn of course).

Does that help?

Tom