requiring 2FA for a service (Shibboleth 2 & MCB)

[Mark McCoy]

Have you tested logging in to a TFA-required SP first and then a non-TFA SP, and then starting a new browser session and logging in in the opposite order (non-TFA an then TFA)?

We tried the exact method that you describe and could not find any way using the MCB to achieve this. It appears to do the right thing if you login TFA first and then non-TFA, but even though the scripted attribute is recalculated on the second login, the MCB will only ever use the calculated list of contexts from the first login. The MCB is focused around the user, and really has no concept of the combination of user+SP, which was a hard idea to get our heads around. The use cases assume that once a user opts-in or is required to use MFA, then the user will always use MFA on all subsequent logins.

Thanks,
Mark


From: users on behalf of Rhian Resnick
Reply-To: Shib Users
Date: Monday, October 19, 2015 at 7:40 PM
To: Shib Users
Subject: Re: requiring 2FA for a service (Shibboleth 2 & MCB)

In 2x we use a scripted atrribute to specify the assurance level required by MCB and a specific service provider.

Same technique should work in 3x.

Rhian
FAU

-------- Original Message --------
From:Mark McCoy
Sent:Mon, 19 Oct 2015 18:06:49 -0400
To:Shib Users
Subject:Re: requiring 2FA for a service (Shibboleth 2 & MCB)

That was our experience. We did not find a way to force TFA at the IdP side with the MCB, and had to fall back to having the SP require the needed context.

Thanks,
Mark


From: users on behalf of Michael A Grady
Reply-To: Shib Users
Date: Thursday, October 15, 2015 at 7:12 PM
To: Shib Users
Subject: Re: requiring 2FA for a service (Shibboleth 2 & MCB)

I'm pretty sure that setting in relying-party.xml only got used if the SP did not explicitly request something. If the SP does have an explicit request, that takes precedence.

On Oct 15, 2015, at 6:49 PM, David Walker <dwalker at internet2.edu<mailto:dwalker at internet2.edu>> wrote:

The current version of the MCB (for Shib 2) should be treating the defaultAuthenticationMethod in relying-party.xml as if it were a context requested by the SP, so if you set that to a context requiring MFA, it should do what you want.  What I don't remember (and the GitHub issue below doesn't illuminate) is whether it will override an explicit request from the SP or if it's merely a default when the SP requests no context.  Paul, if you're watching, do you remember?

By the way, this functionality was not in the initial release; see <https://github.com/Internet2/Shibboleth-Multi-Context-Broker/issues/11> https://github.com/Internet2/Shibboleth-Multi-Context-Broker/issues/11 for details.

David


On 10/14/2015 07:02 PM, Cantor, Scott wrote:

On 10/14/15, 9:51 PM, "users on behalf of IAM David Bantz" <users-bounces at shibboleth.net on behalf of dabantz at alaska.edu><mailto:users-bounces at shibboleth.netonbehalfofdabantz@alaska.edu> wrote:





Seems it should be possible, setting the defaultAuthenticationMethod for this service in relying-party.xml


That's nominally correct, but in V2 that isn't really quite saying that it requires that method. That tells it what to do in the absence of any other decision, but it has no way of enforcing what happened before it finishes up. I don't know if the MCB changes that, I guess it probably does.

-- Scott



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


--
Michael A. Grady
IAM Architect, Unicon, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20151022/be811920/attachment.html>