When using IDP 2.4.4 and MCB 1.2.5 we are seeing AuthnFailed message after authenticating to one sp then switching to a new tab with an sp that forces reauth

[David Langenberg]

You can avoid the initial selection screen by setting an InitialAuthContext
that maps to your username/password context.  In our implementation, we
have three contexts in play for some users.  To eliminate the chooser
screen for them, we modified our selectcontext.vm file to contain a bit of
javascript that when window.onload() fires, it submits the chooser form
automatically back to the IdP with our 2FA context pre-selected.  The JS
works pretty well, though we've found it breaks users trying to install the
Box Sync and Box Office applications on windows machines (for some reason
the embedded browser won't run the JS).

Dave

On Tue, Jun 30, 2015 at 9:22 PM, Ewing, Bill <BEwing at utsystem.edu> wrote:

>  Thanks for the response. I tried the new version this evening and while
> it did get me to the sp w/o an AuthnFailed message we did get stopped with
> an authentication selection screen where we have to select our authcontext
> ie 2factor, username/password only. Is there some additional config that
> can be done to get through w/o getting the selection screen?
>
>
>
> Thanks,
>
> Bill
>
>
>
> *From:* users [mailto:users-bounces at shibboleth.net] *On Behalf Of *Paul
> Hethmon
> *Sent:* Tuesday, June 30, 2015 2:59 PM
> *To:* Shibboleth Users
> *Subject:* Re: When using IDP 2.4.4 and MCB 1.2.5 we are seeing
> AuthnFailed message after authenticating to one sp then switching to a new
> tab with an sp that forces reauth
>
>
>
> Grab version 1.2.6 to fix that bug.
>
>
>
> Paul
>
>
>
>  On Jun 30, 2015, at 3:50 PM, Ewing, Bill <BEwing at utsystem.edu> wrote:
>
>
>
> Ever since we’ve started using the IDP 2.4.4 and MCB 1.2.5 in preparation
> for rolling out 2factor we have our users seeing the AuthnFailed message
> when after authenticating to one sp previously opens a new browser tab and
> visits an sp that is set to force re-authentication. One of our other
> schools with a similar setup disabled their setup for previous sessions to
> get around this issue. We were wondering if this was a known issue for this
> scenario or are we missing something with our config on the sp or idp
> possibly? I’ll paste the idp log snippet below
>
>
>
>
>
> -----
> Paul Hethmon
> Chief Software Architect
> paul.hethmon at clareitysecurity.com
>
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>



-- 
David Langenberg
Identity & Access Management Architect
The University of Chicago
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150630/e581a8c1/attachment.html>