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

[db@alaska.edu]

Add one more complication: SP I need to protect with 2FA uses unsolicited SSO. Even if I provide a link that includes request for 2FA it's trivial for motivated user to rewrite for PPT.

We've concluded we have to require enrollment of individual in 2FA (i.e., 2FA only allowed method) by policy, and enforce at IdP by conditionalizing release of required attribute actually being used. 

IAM and Security are OK with that, but I suspect a few users will whine about having to use 2FA even for less sensitive services. 

David.Bantz at Alaska.edu


> On Oct 22, 2015, at 07:20, Mark McCoy <Mark.McCoy at utsa.edu> wrote:
> 
> 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> 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 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> 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
> 
> 
> --
> Michael A. Grady
> IAM Architect, Unicon, Inc.
> 
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20151022/02860489/attachment.html>