Forcing Duo 2FA at the IdP
Cantor, Scott
cantor.2 at osu.edu
Wed Jan 18 20:04:41 EST 2017
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
More information about the users
mailing list