New Duo Auth Config Page Questions

[Cantor, Scott]

> I'm a bit new to the entire workflow model but I was pretty intrigued by the
> new page put up here:
> https://wiki.shibboleth.net/confluence/display/IDP30/DuoAuthnConfiguration

Most of the stuff you're asking about is really about this:

https://wiki.shibboleth.net/confluence/display/IDP30/MultiFactorAuthnConfiguration

I've posted several times on dev about the work, but it's fairly documented/baked now, so doesn't really matter if you don't have the background.

The Duo flow itself doesn't do anything special or fancy, by design. It just "does Duo". Fancy business logic around using it doesn't get done by that flow, but by the MFA flow. Otherwise every different technology option would have to implement a ton of special features, and that doesn't make sense.

> O​ne of the desired behaviors is to allow SP's to opt in or opt out, is this what
> you were describing when modifying "supportedPrincipals" in the
> conf/authn/general-authn.xml file?

Principal support is about the authentication methods/classes a login flow can handle. That pertains to SPs opting-in/out because they can request the class they want, and you have to make sure it matches what the login flows support. It doesn't generally require much special workflow logic to make that work.

> Another one is to have different duo integration's based on user group
> membership. Is this possible via
> shibboleth.authn.Duo.DuoIntegrationStrategy by being able to inspect
> attributes?

Yes, but normally attributes wouldn't be resolved yet, so you would use the MFA flow to orchestrate:

- run Password flow (or reuse it)
- if that's sufficient, complete work
- resolve an attribute and store it in a particular AttributeContext
- run Duo

That is what's already in the MFA example illustrating IPAddress + Password, but what the factors actually are doesn't matter. Assuming you do that, there will be attributes accessible to any function/script you write.

> Could a duo flow be bypassed entirely based on not being a
> member of an eligible group (could also be used in case duo became
> unavailable for some amount of time.)

Yes, but that's done by scripting those rules in the MFA flow, per the above. Putting it inside the Duo flow isn't necessary. The Duo flow only runs because you tell it to run from the MFA flow's rules.

Once this takes over, most people won't enable individual login methods at all, they'll just enable MFA alone and put all the rules in the maps and scripts in that flow's configuration file. No writing webflows or Java code, just rules and scripts. I think it's turned out quite well.

-- Scott