authn/MFA and authn/RemoteUser with two flavors of client certs

[Losen, Stephen C. (scl)]

Hi Scott,

Thanks for narrowing this down for me.

Looking at the documentation for authn/RemoteUser I see that it supports a "servlet init parameter" called "authnMethodHeader"  I think this is just what I need. I am using httpd as a reverse proxy so I can define a request header named something like "X-Auth-Method".  Httpd can inspect the client cert issuer and if the client cert is a token, then pass our "enhanced" auth method value via the X-Auth-Method header.  Otherwise not.

Am I correct that this the purpose of the "authnMethodHeader" feature?

Stephen C. Losen
ITS - Systems and Storage
University of Virginia
scl at virginia.edu    434-924-0640


-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Wednesday, June 13, 2018 11:55 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: authn/MFA and authn/RemoteUser with two flavors of client certs

On 6/13/18, 6:12 PM, "users on behalf of Losen, Stephen C. (scl)" <users-bounces at shibboleth.net on behalf of scl at virginia.edu> wrote:

> Is there some way for the MFA transition map script to modify an authn result so that when a token cert is used, Duo is
> bypassed and the the overall MFA result appears as if Duo was run?  Can I manipulate a data structure,
> and if so, which one and how?  (For specific details I can refer to the javadoc.)

Ideally you shouldn't make it appear Duo was run, but rather ensure that the right Principal objects are present in the AuthenticationResult to satisfy a request, and you should never define those context class Principals in terms of Duo, or certificates, or any technology. They should be strictly abstracted away from those details. The original SAML values are a mistake and should be avoided, and any new ones shouldn't emulate them.

In most cases, then, you shouldn't need the MFA logic to do anything special, because it should be the job of the individual "factor" flows to make sure that the right AuthnContextClassRef Principal objects are in the Subject they produce, in this case by differentiating the two certificate types *in that flow* and then having the result populated with different Principals in each of the two cases to reflect different meaning.

Then the MFA logic doesn't have to do anything but its job: decide whether Duo should run or not (which it might be able to do simply with the usual isAcceptable() calls.

That's the best case.

The worst case is if you have to go hacking around at the back-end, you can supply a custom merge function to the MFA flow so that at the very end when it combines everything together, it has the ability to dynamically construct the final Subject however you want it to, which by default is a pretty simple union of what got produced by the individual factors. There's a brief mention of it under Merging Results in the documentation.

-- Scott



-- 
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net