Forcing Duo 2FA at the IdP

[Hall, Gerry]

Sorry for just getting back to this, but I have been trying to get this to work based on the previous response.  However, I am still running into the same problem; that is forcing DUO 2FA at the IdP will only work if I have an existing session form a previous Shibboleth login.  As Scott pointed out, without the existing session, there is no username for Duo to consume.

To restate the problem, I need to force Duo 2FA for the SP regardless of whether the SP requests that context or not and regardless of if there is already an existing session or not (i.e., Duo 2FA is the only authorized login context for this SP).  I want to control this at the IdP as the SP cannot specify a particular login context.  As stated previously, I am using IdP v3.3.0.

Is this possible?  If you can point me to existing documentation on how to do this or if someone can provide an example that would be much appreciated.



On 1/18/17, 8:04 PM, "users on behalf of Cantor, Scott" <users-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:

>On 1/18/17, 4:47 PM, "users on behalf of Hall, Gerry" <users-bounces at shibboleth.net on behalf of gerry.hall at emory.edu> wrote:
>
>>  However, this only works if I have an existing session.  Here is the error that I am getting in the idp-process.log:
>
>That means the Duo flow doesn't have a username to consume from a previous factor/flow. That itself wasn't being handled gracefully and has been tracked and patched, but the underlying cause is still a bug in the first factor flow or the way you're running it.
>
>The one known case of that with the Password flow as delivered has also been patched, but it's fairly obscure, it involves use of the conditions hook. But I don't know what you're using so I don't know what your particular bug is.
>
>> Note that I am testing using a clean install of IdP v3.3.0.
>
>I don't believe you could get this result if your first factor was the Password flow, used as delivered with no customizations, and if your MFA rules are running the Password flow first. So that would implicate your MFA config perhaps, the rules/scripts handling the transitions inside there.
>
>> Also, having other SP's explicitly request the Duo authnContext https://login.emory.edu/duo  also works (i.e., no entry in
>> the relying-party.xml)
>
>An SP requesting a context class is exactly the same internally as setting the profile property yourself the way you are doing. It can't cause a different outcome, not by itself.
>
>> Per the docs at https://wiki.shibboleth.net/confluence/display/IDP30/Configuring+the+IdP+for+the+MultiContext+Broker+Model
>
>That material is not relevant anymore. I will likely delete it at some point, but since I didn't write any of it, I tend not to get that medieval on things I didn't write.
>
>-- Scott
>
>
>--
>To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

________________________________

This e-mail message (including any attachments) is for the sole use of
the intended recipient(s) and may contain confidential and privileged
information. If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution
or copying of this message (including any attachments) is strictly
prohibited.

If you have received this message in error, please contact
the sender by reply e-mail message and destroy all copies of the
original message (including attachments).