MFA - TOTP plugin

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

MFA - TOTP plugin

Joseph Fischetti
Good morning,

I've done some work developing an MFA plugin (which I forked off from what mostly seemed to be a POC) to support OTP.  Thanks Korteke for laying the groundwork.

There doesn't seem to be much discussion on here about such support; The go-to really appears to be Duo.  The main differences between what I've implemented and Duo is that here there's no reliance on an outside connection for validating the OTP.  Once you get passed the setup, there's also 0 cost.  

OTP seeds are stored encrypted in the attribute store of your choosing (accessible via the attribute resolver).  Flow control is done via the MFA flow.  The IdP does nothing to maintain the seed storage. i.e. token enrollment is done out of band.   There's more in the readme included in the repo. [1]

Any input is appreciated (both here and offline).  

-------

[1] https://github.com/joeFischetti/Shibboleth-IdP3-TOTP-Auth



Joe Fischetti
Linux System Administrator
Marist College

E-mail: [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 - TOTP plugin

Cantor, Scott E.
On 12/9/19, 7:43 AM, "users on behalf of Joseph Fischetti" <[hidden email] on behalf of [hidden email]> wrote:

> There doesn't seem to be much discussion on here about such support; The go-to really appears to be Duo.  The main
> differences between what I've implemented and Duo is that here there's no reliance on an outside connection for
> validating the OTP.  Once you get passed the setup, there's also 0 cost.  

Yes, but Duo has the entire enrollment component, token management, revocation, and of course the form factors that people actually like (they hate codes). So that's the "cost" inherent in any other solution, it's not free.

> OTP seeds are stored encrypted in the attribute store of your choosing (accessible via the attribute resolver).  Flow
> control is done via the MFA flow.  The IdP does nothing to maintain the seed storage. i.e. token enrollment is done out
> of band.   There's more in the readme included in the repo. [1]

That's kind of the problem, it's not a complete solution, but using the resolver to access the data is a strong play for us as a project and I'm more than happy to evaluate the code for inclusion in a release (possibly the next, just depends how much work it might be, we're close to beta).

I don't foresee significant adoption without those other pieces, but I'm also prepared to be wrong, and it isn't likely much for us to maintain because of that omission. It's a start, at least.

It appears to be Apache-licensed, so technically that frees it up for possible inclusion, but it's only polite to ask.

-- 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 - TOTP plugin

Joseph Fischetti
Scott
I completely understand the point that there isn't any token management
worked into the solution.  The main reason that I (personally) feel it's out
of scope is because the IdP is an identity provider, not an identity
manager.  It's up to the deployer to handle password management outside of
the IdP, so token/seed management should be the same way.

> Yes, but Duo has the entire enrollment component, token management,
revocation, and of course the form factors that people actually like (they
hate codes). So that's the "cost" inherent in any other solution, it's not
free.

There's pros and cons.  I never said this plugin was free, I said there was
0 cost to running it after it was set up.  Sure, there's development time on
the front end for token enrollment, and you'll need a helpdesk... but Duo is
some fixed cost per user per period (it's been a while since I had a pricing
talk with them).  This is the same cost for 5 users to 40,000 users.  

For what it's worth... I already have a token enrollment tool built that
would be straightforward enough to implement (with QR codes and verification
etc), but it would just require the IdP's ability to write back to the
directory (which I don't like the idea of).  

As with anything else, it also doesn't need to be an either-or.  

Thanks for the response


Joe Fischetti
Linux System Administrator
Marist College

-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Monday, December 9, 2019 11:32 AM
To: Shib Users <[hidden email]>
Subject: Re: MFA - TOTP plugin

[EXTERNAL EMAIL]

On 12/9/19, 7:43 AM, "users on behalf of Joseph Fischetti"
<[hidden email] on behalf of [hidden email]>
wrote:

> There doesn't seem to be much discussion on here about such support;
> The go-to really appears to be Duo.  The main differences between what
> I've implemented and Duo is that here there's no reliance on an outside
connection for validating the OTP.  Once you get passed the setup, there's
also 0 cost.

Yes, but Duo has the entire enrollment component, token management,
revocation, and of course the form factors that people actually like (they
hate codes). So that's the "cost" inherent in any other solution, it's not
free.

> OTP seeds are stored encrypted in the attribute store of your choosing
> (accessible via the attribute resolver).  Flow control is done via the MFA
flow.  The IdP does nothing to maintain the seed storage. i.e. token
enrollment is done out
> of band.   There's more in the readme included in the repo. [1]

That's kind of the problem, it's not a complete solution, but using the
resolver to access the data is a strong play for us as a project and I'm
more than happy to evaluate the code for inclusion in a release (possibly
the next, just depends how much work it might be, we're close to beta).

I don't foresee significant adoption without those other pieces, but I'm
also prepared to be wrong, and it isn't likely much for us to maintain
because of that omission. It's a start, at least.

It appears to be Apache-licensed, so technically that frees it up for
possible inclusion, but it's only polite to ask.

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

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MFA - TOTP plugin

Cantor, Scott E.
On 12/9/19, 10:59 AM, "users on behalf of Joseph Fischetti" <[hidden email] on behalf of [hidden email]> wrote:

> I completely understand the point that there isn't any token management
> worked into the solution.  The main reason that I (personally) feel it's out
> of scope is because the IdP is an identity provider, not an identity
> manager.  It's up to the deployer to handle password management outside of
> the IdP, so token/seed management should be the same way.

That's always been our purist view, but increasingly people don't buy those boundaries in a lot of cases, so I've had to start evaluating new feature additions in a more holistic way than in the past.

Believe me, we get plenty of people complaining we don't do password management, and some of the UI hooks were done with that at least in mind.

> For what it's worth... I already have a token enrollment tool built that
> would be straightforward enough to implement (with QR codes and verification
>  etc), but it would just require the IdP's ability to write back to the
> directory (which I don't like the idea of).  

I don't either. I think it's easy to make that leg pluggable but I also had hoped by now there might be some kind of standardized API for these functions, and that hasn't really happened.

Please don't take any of my comments as criticisms, I was just trying to explain why you had to do that work to begin with. But in any case, I assume you don't object to us evaluating it for inclusion.

-- 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 - TOTP plugin

Joseph Fischetti
> Please don't take any of my comments as criticisms, I was just trying to explain why you had to do that work to begin with. But in any case, I assume you don't object to us evaluating it for inclusion.

No worries, I sent the email for input.  That was the whole idea.
I have no objections at all.  Please feel free to reach out to me offline if there's anything I can do (or anything that should be done differently).

Joe Fischetti
Linux System Administrator
Marist College

E-mail: [hidden email]
Cell:  914-552-0129


-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Monday, December 9, 2019 12:23 PM
To: Shib Users <[hidden email]>
Subject: Re: MFA - TOTP plugin

[EXTERNAL EMAIL]

On 12/9/19, 10:59 AM, "users on behalf of Joseph Fischetti" <[hidden email] on behalf of [hidden email]> wrote:

> I completely understand the point that there isn't any token
> management worked into the solution.  The main reason that I
> (personally) feel it's out of scope is because the IdP is an identity
> provider, not an identity manager.  It's up to the deployer to handle
> password management outside of the IdP, so token/seed management should be the same way.

That's always been our purist view, but increasingly people don't buy those boundaries in a lot of cases, so I've had to start evaluating new feature additions in a more holistic way than in the past.

Believe me, we get plenty of people complaining we don't do password management, and some of the UI hooks were done with that at least in mind.

> For what it's worth... I already have a token enrollment tool built
> that would be straightforward enough to implement (with QR codes and
> verification  etc), but it would just require the IdP's ability to
> write back to the directory (which I don't like the idea of).

I don't either. I think it's easy to make that leg pluggable but I also had hoped by now there might be some kind of standardized API for these functions, and that hasn't really happened.

Please don't take any of my comments as criticisms, I was just trying to explain why you had to do that work to begin with. But in any case, I assume you don't object to us evaluating it for inclusion.

-- 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: MFA - TOTP plugin

Cantor, Scott E.
On 12/9/19, 12:14 PM, "users on behalf of Joseph Fischetti" <[hidden email] on behalf of [hidden email]> wrote:

> I have no objections at all.  Please feel free to reach out to me offline if there's anything I can do (or anything that should
> be done differently).

Normally I don't pester contributors over style points, but with the shorter timeline it's possible I might have to do that, I will if needed.

There's actually already a ticket open for OATH support (IDP-1014) so I will add a pointer to github there.

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