MFA result reuse with Duo.

Cantor, Scott cantor.2 at osu.edu
Wed Jan 18 15:40:30 EST 2017


On 1/18/17, 3:15 PM, "users on behalf of O'Dowd, Josh" <users-bounces at shibboleth.net on behalf of Josh.O'Dowd at mso.umt.edu> wrote:

> I understand the process for setting up an RP override.  In this case, I am not sure about using the EntityAttribute because,
> at least so far, the RPs I am being asked to require Duo for are going to be CAS authenticating and restricted to
> faculty/staff attempts(never any lack of excitement in what they ask for around here!).

I would like to see the CAS config move over to metadata but obviously for the time being, no, you'll have to explicitly deal with relying-party.xml for that at the moment.

But I don't think you could do anything that's user-specific. If the SP requirement for MFA gets triggered, that has to be satisfied or it's not going to work at the end, it will fail the result. And you don't know anything about the user that early, so you couldn't know whether to trigger it. And if you don't trigger it, and the MFA result minus Duo satisifies the request, it's not going to run the flow, which is what you're getting now.

(I'm ignoring all the older features I know are going to go away sooner or later.)

I really can't think of a clean way to do it. You can derive the defaultAuthenticationMethods setting dynamically, but even if there were a session in place, it isn't "loaded" into the state of the request by the time that logic would run, so it wouldn't be able to look at the session to decide what to return. That's a promising direction but the timing just doesn't work.

Basically, I entertained:

- decision is based on SP
- decision is based on user

I don't think combining them is possible right now without other assumptions. I did ask several times on -dev for use cases to validate the design, but I didn't get any.

-- Scott




More information about the users mailing list