Logic for mfa-authn-config.xml
Andrew Morgan
morgan at orst.edu
Wed Jan 10 17:39:17 EST 2018
On Wed, 10 Jan 2018, Paul B. Henson wrote:
> We're currently working on a duo deployment and I'd appreciate some
> suggestions on how best to handle the logic to determine whether or not
> to continue to the mfa flow after password authentication succeeds.
>
> Duo is only going to be available for a subset of users, and there will
> be an LDAP attribute available to indicate whether or not a given user
> has duo enabled.
>
> Applications will fall into three groups; those that do not need MFA at
> all, those that will use MFA if available but still work with just a
> password otherwise, and those that strictly require MFA and will fail if
> it does not succeed. I'm not sure yet where this application delineation
> information will be stored.
>
> Given these two pieces of information, the logic needs to either not
> instantiate MFA and succeed (applications that don't support MFA, or
> applications that optionally support MFA but user does not have it
> enabled), fail hard (application strictly requires MFA and user does not
> have it enabled), or instantiate MFA and return the result of that
> (application optionally or strictly requires MFA and user has MFA
> enabled).
>
> Is there any way to store the ternary value for the application MFA
> support somewhere within the idp configuration or do I need to find a
> place to stick it in LDAP or elsewhere? I think once I can get the
> values into the mfa script I'll be able to sort out the commands to do
> the logic, but any suggestions on those won't be turned down :).
Paul,
The signal to the IDP that MFA is required is the authnContextClassRef.
This can be sent in the SAML request by the SP or hard-coded in
relying-party.xml on the IDP.
You can also detect the SP entityID in your MFA logic and switch Duo on
programmatically in the MFA script. In my opinion, that is needlessly
complex.
Andy
More information about the users
mailing list