MCB with Duo and password as fallback

[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-bounces at shibboleth.net [mailto:users-bounces at 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 <kwessel at illinois.edu<mailto:kwessel at 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-bounces at shibboleth.net<mailto:users-bounces at shibboleth.net> [mailto:users-bounces at shibboleth.net<mailto:users-bounces at 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 <kwessel at illinois.edu<mailto:kwessel at 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-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>



--
David Langenberg
Identity & Access Management
The University of Chicago

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>



--
David Langenberg
Identity & Access Management
The University of Chicago
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140820/3486618c/attachment-0001.html