IDP 3 Duo + Username/Password with user-opt-in forcing Duo

[Wessel, Keith]

Chiming in here since I've been trying to help Tulio get DaveL's replicated MCB functionality working.

In this case, for reasons I don't' fully grasp, the authn/Duo bean is defined in global.xml. Perhaps it should be in general-authn.xml, but Dave suggested to add it to global.xml.

The context checking seems to have more to do with defining which flows satisfy which others, not tying a contaxt to an attribute value.

My understanding is that the presence of the ben in globalxml defined as DaveL documents, but replacing the UChicago context with the locally appropriate one, will associate the context with the method. Does this also handle the filtering of contexts based on the assurance (or eduPersonAssurance, whatever you choose to call it) attribute values? That seems to be what's falling down for Tulio... either that or it's not recognizing his bean in global.xml.

This setup worked out of the box for me after following Dave's instructions, but it hasn't worked for Tulio, and we're pulling our hair out trying to figure out what's different.

Keith

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Monday, October 12, 2015 1:50 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: IDP 3 Duo + Username/Password with user-opt-in forcing Duo

On 10/12/15, 2:30 PM, "users on behalf of Llosa, Tulio C" <users-bounces at shibboleth.net on behalf of tllos1 at uis.edu> wrote:

>However, the Potential authentication flows left after filtering only retain authn/Password and NOT authn/Duo:

Assuming a flow was enabled generally, it would have to have been filtered out by other criteria, possibly including the SP requesting something specific that the flow doesn't support. Requesting a password-based AuthnContextClassRef usually.

>Where should I be looking to figure out why authn/Duo is not being considered a potential authentication flow? Is it in the global.xml bean definition or in the context-check-intercept-config.xml, or elsewhere?

The context-check feature has nothing at all to do with this kind of scenario. If you're using that, stop, it isn't used for controlling authentication behavior and having to use it for that would be a red flag that there are other problems with the approach.

There is nothing in global.xml at all by default, it's for user-defined Java beans that don't fit anywhere else.

Defining authentication methods includes steps like adding a flow descriptor bean definition to the list in authn/general-authn.xml and then enabling it in the idp.authn.flows property, if you want it on globally speaking. It can also be enabled only at the relying-party level if needed.

Other than SP request content or profile-specific settings, there's nothing else that would filter out any flows from being available if they're on to start with.

-- Scott

-- 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net