Feedback on Multi-Context Broker Community Contribution

Paul Hethmon paul.hethmon at clareitysecurity.com
Mon Oct 21 17:00:08 EDT 2013


Keith,

One of the issues with using RemoteUser is that forced authentication is not supported. I've actually got some code not committed yet that implements an MCB submodule for RemoteUser. We're just not sure how useful that is given the lack of forced authentication support. Ideally, you would use MCB submodules for all of the authentication tasks, it gives you the most control over the stepped up authentication model.

I just scanned the Duo handler and see how it's like the standard UserPassword handler, but I'm not picking up on what it is doing for the "Duo" authentication part. From looking at their website, it looks like the login at the IdP using normal JAAS mechanisms would trigger the push notification to the user's phone? Then if the user approves it, that somehow lets the IdP know to proceed with the authentication? That sounds like a pretty asynchronous process. All of that was me figuring out if I could write a submodule for the MCB without having used Duo ever.

I do need to write a standalone MCB submodule project that others can use as a skeleton. I had planned on using SafeNet Safeword as that example as I've used that two-factor token system for a number of years, but might be persuaded to do Duo.

Paul

From: <Wessel>, Keith <kwessel at illinois.edu<mailto:kwessel at illinois.edu>>
Reply-To: Shibboleth Users <users at shibboleth.net<mailto:users at shibboleth.net>>
Date: Monday, October 21, 2013 4:44 PM
To: Shibboleth Users <users at shibboleth.net<mailto:users at shibboleth.net>>
Subject: RE: Feedback on Multi-Context Broker Community Contribution

Paul,

This _might_ be of use to us at Illinois and possibly others in a similar situation to us.

We’ll soon be switching away from the UsernamePassword login handler to the RemoteUser login handler to integrate with a new university-wide SSO system that’s being put in place. In other words, Shib will be using the other SSO as authoritative. However, the other SSO doesn’t currently have support for Duo which we’re considering. And Duo’s contributed login handler is only a drop-in replacement for the UsernamePassword login handler. Duo, at our request, has added modifying the RemoteUser login handler to do a Duo token auth after getting a username back from the RemoteUser login handler, but I don’t think it’s a high priority.

We’d love if we could somehow use your MCB work to use a Remoteuser login handler for basic or unspecified authn requests but use something from Duo for MFA requests. I’m not sure, after reading your docs, that this is doable, though. Thoughts or comments? Am I nuts here? :)

Keith


From: users-bounces at shibboleth.net<mailto:users-bounces at shibboleth.net> [mailto:users-bounces at shibboleth.net] On Behalf Of Paul Hethmon
Sent: Monday, October 21, 2013 3:27 PM
To: Shibboleth Users
Subject: Feedback on Multi-Context Broker Community Contribution

I've been working on a project for InCommon to provide a Shibboleth Authentication Handler that implements ordered levels of authentication. So you could configure both a simple password and a two-factor system inside of Shibboleth and then let the SP request which one to use. So if Joe User first authenticates with password, a second SP (or even the first for that matter), could then send an authentication request that says to use two-factor authentication. The Multi-Context Broker (MCB) would then force the user to "upgrade" their authentication to two-factor to continue.

That's the basics of what it can do. We've done some initial testing and are now looking to broaden our audience for more feedback. You can find all of the information on the Shibboleth wiki:

https://wiki.shibboleth.net/confluence/display/SHIB2/Multi-Context+Broker

Please take a look if you think this capability might be useful to you.

thanks,

Paul


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20131021/56f0ab8d/attachment.html 


More information about the users mailing list