Complicating my MFA implementation

[Cantor, Scott]

> We've got our IDP set up using the V3 MCB recipe right now; a certain
> context will trigger Duo authentication if the user logging in is Duo eligible.
> The eligibility (and eduPersonAssurance attribute value) is based on
> membership in a particular group.

I was fortunate in not needing attribute-based opt-in, and driving everything by RequestedAuthnContext is a relatively workable model to implement, but I still needed a custom Duo flow of my own making to do this without wanting a shower afterwards.

I don't really know much about how to do the more advanced things people do with attributes, which I frankly don't understand well.

> We'd like to complicate things a bit and add a second group; users in that
> group would be required to Duo auth regardless of the rquested context.
> This would allow for certain users with significant admin access or even users
> who just want to opt in to MFA for everything to get the Duo screen for the
> creation of any IDP session.

I did implement a simple cookie-based login opt-in in my custom flow, so I did manage to get that to work, but again, only because I implemented my own login flow.

> I'm wondering the easiest way to implement this. I've been looking at the
> intercept config this morning, and it seems I could modify the conditions that
> trigger the Duo flow in conf/intercept/context-check-intercept-config.xml: if
> in group A and requested context is Duo or if in group B. This involves figuring
> out how to add the or'd comparison to that configuration, though. Can
> anyone provide guidance there?

That's not possible. Intercepts run after login, not during. So it's not really related to your problem.

> The other option would be to add the check for membership in group B to
> the password flow and, if true, call the Duo flow from the password flow.
> This seems like a less ideal candidate to me, but I could be wrong.

That is IMHO the only workable model today, a custom flow that combines the logic needed, either Password calling Duo or Duo calling Password. I did the latter.

The design I'm working on will hopefully be more generalized and handle the sequencing and checking for "completion" at each step, so if it works, that should allow the Duo flow to do Duo, the Password flow to work as is, new factors to be developed stand-alone, and then a simple config to combine them.

That's really all I can say for now: I don't think the current versions accomodate MFA well (other than simple cases like SecurID that are self-contained) other than by the ability to extend the system with custom flows, and 3.3 hopefully will advance that state significantly. As usual, it really comes down to my understanding the problem better. I can't implement (well) what I don't use, and until a few weeks ago, I didn't have Duo here.

But when the time comes I'm probably going to need more help with the attribute piece. I don't really understand how to make that work yet, but my thinking about it is that the ideal would be to do a custom transition function that can examine resolved attributes and just tell the system what to do next. That's my mental model anyway.

-- Scott