MCB with Duo and password as fallback

[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 at shibboleth.net [mailto:users-bounces at shibboleth.net] 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 at shibboleth.net<mailto:users-bounces at shibboleth.net> [mailto:users-bounces at shibboleth.net] 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


On Aug 21, 2014, at 8:37 AM, David Langenberg <davel at uchicago.edu<mailto:davel at uchicago.edu>> wrote:



On Thu, Aug 21, 2014 at 6:35 AM, Tom Scavo <trscavo at gmail.com<mailto:trscavo at gmail.com>> wrote:
On Wed, Aug 20, 2014 at 10:10 PM, Wessel, Keith <kwessel at illinois.edu<mailto:kwessel at illinois.edu>> wrote:
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140822/23d65139/attachment-0001.html