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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Losen, Stephen C. (scl)-2

Hi folks,


I am configuring MFA to first authenticate with username/password, or with a client cert.  The login form has a button that triggers authn/RemoteUser and the RemoteUser endpoint requires a client cert.  Then MFA runs Duo as the second factor.


We have two flavors of client certs and I can distinguish them via the cert issuer.  We have hardware token certs and "standard assurance" (file) certs.


We would like to bypass Duo when a hardware token is used.  I know how to do this in my MFA transition map script.  However, we want a hardware token to be "as good as" two factor with Duo. So if the SP requests an auth context class that ordinarily requires Duo, we want the hardware token cert to satisfy the request without running Duo. But a standard assurance cert should cause MFA to run Duo.


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.)


Thanks,


Steve Losen


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Cantor, Scott E.
On 6/13/18, 6:12 PM, "users on behalf of Losen, Stephen C. (scl)" <[hidden email] on behalf of [hidden email]> 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 [hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Losen, Stephen C. (scl)-2
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
[hidden email]    434-924-0640


-----Original Message-----
From: users [mailto:[hidden email]] On Behalf Of Cantor, Scott
Sent: Wednesday, June 13, 2018 11:55 PM
To: Shib Users <[hidden email]>
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)" <[hidden email] on behalf of [hidden email]> 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 [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Cantor, Scott E.
On 6/14/18, 6:18 PM, "users on behalf of Losen, Stephen C. (scl)" <[hidden email] on behalf of [hidden email]> wrote:

> 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?

Correct. What it specifically does is interrogate the flow descriptor bean with the supportedPrincipals property and look through that collection and if it finds a simple string match between the header value and one of those Principals, it will stuff that into the Subject.
 
Make sure you set the shibboleth.authn.RemoteUser.addDefaultPrincipals bean to false to avoid it just adding everything anyway, you're taking control of that decision if you use the header.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Cantor, Scott E.
(And I would have mentioned this header if I'd remembered it, half the point of the documentation is to remind myself of what actually got built.)

-- Scott

´╗┐On 6/14/18, 8:11 PM, "users on behalf of Cantor, Scott" <[hidden email] on behalf of [hidden email]> wrote:

On 6/14/18, 6:18 PM, "users on behalf of Losen, Stephen C. (scl)" <[hidden email] on behalf of [hidden email]> wrote:

> 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?


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