MFA vs. Password and Extended Flow in IDP

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

MFA vs. Password and Extended Flow in IDP

Losen, Stephen C (scl)
Hi folks,

I am wondering about the advantages/disadvantages of the following.

For authn am using MFA with Password and Duo.  I am also using RemoteUser for client cert authn.

In my current config, RemoteUser is an "Extended flow" invoked by the Password flow.  In the login.vm view I have a "Use my Cert" button that returns "authn/RemoteUser".  So MFA does not directly invoke RemoteUser.

However, I could configure MFA to invoke Password and have Password return a custom "useCert" event in response to the "Use my Cert" button on the login.vm view.  Then in the MFA transition map, I can have MFA invoke RemoteUser.

Are there any strong reasons to prefer one method over the other? I think that the "extended flow" feature of Password predates MFA, so is MFA now the preferred, more general solution?

Stephen C. Losen
ITS - Systems and Storage
University of Virginia
[hidden email]    434-924-0640


--
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: MFA vs. Password and Extended Flow in IDP

Cantor, Scott E.
> Are there any strong reasons to prefer one method over the other? I think
> that the "extended flow" feature of Password predates MFA, so is MFA now
> the preferred, more general solution?

I didn't deprecate that particular feature, but I would always use MFA in preference to anything else.

-- 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: MFA vs. Password and Extended Flow in IDP

Peter Schober
In reply to this post by Losen, Stephen C (scl)
* Losen, Stephen C. (scl) <[hidden email]> [2018-06-25 13:02]:
> For authn am using MFA with Password and Duo.  I am also using
> RemoteUser for client cert authn.

Also, why RemoteUser and not the existing X.509 support?
https://wiki.shibboleth.net/confluence/display/IDP30/X509AuthnConfiguration
-peter
--
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: MFA vs. Password and Extended Flow in IDP

Losen, Stephen C (scl)
Hi folks,

In my development environment I currently have SSL configured on Apache httpd which is a reverse proxy to jetty and the IDP (non-SSL port 8080).  So I would need to learn how to configure SSL on jetty.  I also have a F5 BigIP in front of Apache httpd. The F5 does not terminate SSL.  Much of this comes from our current production configuration, where the IDP offloads authentication to a legacy SSO system via authn/RemoteUser.

I am building a new configuration where the IDP authenticates directly. I want to eliminate Apache httpd and terminate SSL on the F5.  The F5 will reverse proxy to jetty/IDP (non-SSL port 8080).  When appropriate, the F5 will pass information about the client cert in HTTP headers.  And yes, I will be careful to prevent HTTP header forgery on the F5, and jetty/IDP will only allow requests from the F5.  So that is why I am using authn/RemoteUser for client certs.  Jetty/IDP gets the client cert info from HTTP headers.

I can't think of a mechanism other than HTTP headers to pass "environment" info from the F5 to jetty/IDP.

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 Peter Schober
Sent: Wednesday, June 27, 2018 9:10 AM
To: [hidden email]
Subject: Re: MFA vs. Password and Extended Flow in IDP

* Losen, Stephen C. (scl) <[hidden email]> [2018-06-25 13:02]:
> For authn am using MFA with Password and Duo.  I am also using
> RemoteUser for client cert authn.

Also, why RemoteUser and not the existing X.509 support?
https://wiki.shibboleth.net/confluence/display/IDP30/X509AuthnConfiguration
-peter
--
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: MFA vs. Password and Extended Flow in IDP

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

> I am building a new configuration where the IDP authenticates directly. I want to eliminate Apache httpd and terminate > SSL on the F5.  The F5 will reverse proxy to jetty/IDP (non-SSL port 8080).  When appropriate, the F5 will pass
> information about the client cert in HTTP headers.  And yes, I will be careful to prevent HTTP header forgery on the F5,
> and jetty/IDP will only allow requests from the F5.  So that is why I am using authn/RemoteUser for client certs.  
> Jetty/IDP gets the client cert info from HTTP headers.

Just FYI, this doesn't go hand in hand. Java consumes the cert via an attribute with a special name in the servlet spec, so to use the X509 flows, all you really have to do is populate that attribute from the header containing the certificate. I believe there's donated code for that via a filter that we offered to include with 3.4.

Not that that argues either way, just saying it doesn't imply Jetty's doing the TLS (and yes, client authn in Jetty is horrific).

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