Re: [openstack-dev] [Keystone] Multi-factor Auth with Keystone and TOTP

[Steve Martinelli]

You can create a new ocata directory if one is not present

On Jul 18, 2016 7:24 PM, "Adrian Turjak"  wrote:

>
>
> On 19/07/16 03:31, Steve Martinelli wrote:
> > I think the change you posted could very much just
> > replace the existing password plugin in keystone (
> > https://review.openstack.org/#/c/343422/) and not be it's own plugin.
> >
> > How about a specification instead?
> > https://github.com/openstack/keystone-specs :)
> > It's unlikely to land in Newton, but would be a candidate for O.
> >
>
> Will do. I'll edit my patch/blueprint to be clear that this is a
> replacement for password that does not affect normal username/password
> functionality, just adds MFA support, and write a spec for the O release.
> :)
>
> Although looking at that repo, since there isn't a folder yet for O,
> should I just throw it in ongoing?
>
> As for your gerrit comments:
> > Is there a reason you created totp_password plugin and not just added
> to the existing password plugin?"
>
> Mainly I wasn't sure if this was something people wanted and I didn't
> want to propose replacing the default password auth module as I thought
> an optional second plugin would be easier to get people to approve.
> Turns out I was wrong!
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] Multi-factor Auth with Keystone and TOTP

[Adrian Turjak]

On 19/07/16 03:31, Steve Martinelli wrote:
> I think the change you posted could very much just
> replace the existing password plugin in keystone (
> https://review.openstack.org/#/c/343422/) and not be it's own plugin.
> 
> How about a specification instead?
> https://github.com/openstack/keystone-specs :)
> It's unlikely to land in Newton, but would be a candidate for O.
> 

Will do. I'll edit my patch/blueprint to be clear that this is a
replacement for password that does not affect normal username/password
functionality, just adds MFA support, and write a spec for the O release. :)

Although looking at that repo, since there isn't a folder yet for O,
should I just throw it in ongoing?

As for your gerrit comments:
> Is there a reason you created totp_password plugin and not just added
to the existing password plugin?"

Mainly I wasn't sure if this was something people wanted and I didn't
want to propose replacing the default password auth module as I thought
an optional second plugin would be easier to get people to approve.
Turns out I was wrong!






__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] Multi-factor Auth with Keystone and TOTP

[Adrian Turjak]

On 19/07/16 01:49, David Stanek wrote:
> On Mon, Jul 18, 2016 at 9:13 AM, Adrian Turjak  
> wrote:
>> We need an MFA solution, and this doesn't seem like too terrible an option.
> 
> 
> One thing to note here is that the credentials for TOTP stored in the
> keystone credentials backend are not encrypted. So a breach of your
> database could expose those to an attacker. This is a review[1] to fix
> this issue that is close to merging.
> 
> 1. https://review.openstack.org/#/c/317169/
> 

Have noticed this, and we are looking at a few options to do something
about this by protecting our Keystone database. This review is ideal and
something I will keep and eye on!

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] Multi-factor Auth with Keystone and TOTP

[Steve Martinelli]

More comments inline.

On Mon, Jul 18, 2016 at 9:13 AM, Adrian Turjak 
wrote:

> Ok. So it sounds like I'm not entirely off track and this will probably be
> the road we go down for our deployment until we have a better option. We
> need an MFA solution, and this doesn't seem like too terrible an option.
>
> Basically after a bunch of digging this was the only solution I found that
> wouldn't break everything, still cover our requirements, maybe let us do
> something interesting with CLI tools.
>
> For the UX thing, we're likely going to edit our horizon login form to
> have an optional passcode field and have the form concatenate before
> passing it to the keystone client. Having a proper two-step login process
> with passcode entry on a second page didn't really seem to be viable with
> stock keystone and mostly stock horizon so this seemed easier and workable.
>
This was the disconnect I had, I initially envisioned this as a two-step
process, but I'm happy to be wrong. Didn't realize that appending the
passcode is a common practice.

> A side UX part that is good here though is that the CLI is still usable
> without any extra work. Just enter your password+passcode and it works.
> Although for the CLI and clients we are actually looking at options to
> allow a sort of wrapper script to connect to a Yubikey and ask for a
> passcode. I'm not sure how doable that is, but anything that let's us do
> MFA while still working as simply as using envvars is good. Would be
> interesting if we can get something working with a Yubikey.
>
Making sure we have CLI, python bindings (via a keystoneauth plugin) and
horizon support is of course the most important, but it seems like the
first two are freebies. I think the change you posted could very much just
replace the existing password plugin in keystone (
https://review.openstack.org/#/c/343422/) and not be it's own plugin.

As for the MFA on one project but not another... That doesn’t really work.
> MFA only makes sense on a per user basis. Plus if you need an account for
> API actions and automation, you make another user with limited roles, but
> trying to make something like MFA work on a per project basis is something
> we ruled out very early. For my testing I never actually bothered even
> setting or using the project field on the credentials construct as it
> seemed redundant
>
If you do push a specification forward, then I think this is a fine
limitation to state.

> The best way to think about it I've found  is: imagine the horizon UX. You
> are logged into one project without MFA and then you swap to another that
> somehow now magically does need MFA. How do you enforce that? How do you
> log the user out, and make them enter MFA to then move to the other
> project? You are logged in already, with a valid token, how could you even
> tag that token as not logged via MFA? There are so many problems, and so
> many questions.
>
> Good point.


> MFA on a per project basis might be doable, but with a lot of pain and
> refactoring it seems like, none of which is worth it, and most of which
> makes for awful UX.
>
++

> At any rate, I would love to help if I can in this area, as it is
> something that interests me and something that we are going to be doing for
> our deployment. If worth the effort, I can polish up and write tests for
> the plugin I've written. It may not be the best solution long term, but it
> is the only one that seemed workable with what is present in OpenStack and
> without considerable effort.
>
> At the very least, I'll do a full write up as to what we end up doing with
> our deployment, and how that went for us.
>
How about a specification instead?
https://github.com/openstack/keystone-specs :)
It's unlikely to land in Newton, but would be a candidate for O.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] Multi-factor Auth with Keystone and TOTP

[David Stanek]

On Mon, Jul 18, 2016 at 9:13 AM, Adrian Turjak  wrote:
> We need an MFA solution, and this doesn't seem like too terrible an option.


One thing to note here is that the credentials for TOTP stored in the
keystone credentials backend are not encrypted. So a breach of your
database could expose those to an attacker. This is a review[1] to fix
this issue that is close to merging.

1. https://review.openstack.org/#/c/317169/

-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
www: http://dstanek.com

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] Multi-factor Auth with Keystone and TOTP

[Adrian Turjak]

Ok. So it sounds like I'm not entirely off track and this will probably be the road we go down for our deployment until we have a better option. We need an MFA solution, and this doesn't seem like too terrible an option. 
Basically after a bunch of digging this was the only solution I found that wouldn't break everything, still cover our requirements, maybe let us do something interesting with CLI tools.
For the UX thing, we're likely going to edit our horizon login form to have an optional passcode field and have the form concatenate before passing it to the keystone client. Having a proper two-step login process with passcode entry on a second page didn't really seem to be viable with stock keystone and mostly stock horizon so this seemed easier and workable.
A side UX part that is good here though is that the CLI is still usable without any extra work. Just enter your password+passcode and it works. Although for the CLI and clients we are actually looking at options to allow a sort of wrapper script to connect to a Yubikey and ask for a passcode. I'm not sure how doable that is, but anything that let's us do MFA while still working as simply as using envvars is good. Would be interesting if we can get something working with a Yubikey.
As for the MFA on one project but not another... That doesn’t really work. MFA only makes sense on a per user basis. Plus if you need an account for API actions and automation, you make another user with limited roles, but trying to make something like MFA work on a per project basis is something we ruled out very early. For my testing I never actually bothered even setting or using the project field on the credentials construct as it seemed redundant.
The best way to think about it I've found  is: imagine the horizon UX. You are logged into one project without MFA and then you swap to another that somehow now magically does need MFA. How do you enforce that? How do you log the user out, and make them enter MFA to then move to the other project? You are logged in already, with a valid token, how could you even tag that token as not logged via MFA? There are so many problems, and so many questions.
MFA on a per project basis might be doable, but with a lot of pain and refactoring it seems like, none of which is worth it, and most of which makes for awful UX.
At any rate, I would love to help if I can in this area, as it is something that interests me and something that we are going to be doing for our deployment. If worth the effort, I can polish up and write tests for the plugin I've written. It may not be the best solution long term, but it is the only one that seemed workable with what is present in OpenStack and without considerable effort.
At the very least, I'll do a full write up as to what we end up doing with our deployment, and how that went for us.
On 18/07/2016 6:51 PM, Morgan Fainberg  wrote:On Sun, Jul 17, 2016 at 10:37 PM, Steve Martinelli  wrote:Several comments inlineOn Mon, Jul 18, 2016 at 12:20 AM, Adrian Turjak  wrote:Hello,

I've been looking at options for doing multi-factor auth (MFA) on our
infrastructure and I'm just wanting to know if the option I've decided
to go with seems sensible.

As context, we are running stock Keystone (to be backed by LDAP), we
wanted to be able to enable MFA on a per user basis, and a user with MFA
enabled should either be blocked from using the APIs or required MFA to
use the APIs.
We discussed adding MFA support in Newton at the Austin summit and didn't come to a happy conclusion (aside from "let federated users have MFA since it's built in"). Part of the trouble was deciding where to enforce MFA. Should a user *always* require MFA just because he has a TOTP credential? What if the user has multiple projects, and wants MFA to access projectA, but not projectB.  
I was looking at the current TOTP module in keystone, but seeing as that
simply adds another optional Auth method to keystone it seems fairly
useless for our needs. Unless I'm missing something, there seems to be
no way in Keystone to enforce "use these two auth methods together". Is
that the case? If not, it is something that has been considered? Or it
is assumed people will write their own auth plugins rather than
combining existing ones?It was definitely not assumed that folks would write there own auth plugins. The TOTP auth plugin was meant to be just be an alternative to password auth. We had hoped it would provide the building blocks for MFA, but see above comment.
From there I went toward writing our own Keystone Auth plugin and had a
lot of success with that. The current iteration is a combination of the
password and totp plugins where for users with TOTP credentials we
expect a 6 digit password appended to the password. In the config I then
replace the default password plugin with my own.I assume appending the TOTP password to the regular password is 

Re: [openstack-dev] [Keystone] Multi-factor Auth with Keystone and TOTP

[Morgan Fainberg]

On Sun, Jul 17, 2016 at 10:37 PM, Steve Martinelli 
wrote:

> Several comments inline
>
> On Mon, Jul 18, 2016 at 12:20 AM, Adrian Turjak 
> wrote:
>
>> Hello,
>>
>> I've been looking at options for doing multi-factor auth (MFA) on our
>> infrastructure and I'm just wanting to know if the option I've decided
>> to go with seems sensible.
>>
>> As context, we are running stock Keystone (to be backed by LDAP), we
>> wanted to be able to enable MFA on a per user basis, and a user with MFA
>> enabled should either be blocked from using the APIs or required MFA to
>> use the APIs.
>>
>>
> We discussed adding MFA support in Newton at the Austin summit and didn't
> come to a happy conclusion (aside from "let federated users have MFA since
> it's built in"). Part of the trouble was deciding where to enforce MFA.
> Should a user *always* require MFA just because he has a TOTP credential?
> What if the user has multiple projects, and wants MFA to access projectA,
> but not projectB.
>
>
>> I was looking at the current TOTP module in keystone, but seeing as that
>> simply adds another optional Auth method to keystone it seems fairly
>> useless for our needs. Unless I'm missing something, there seems to be
>> no way in Keystone to enforce "use these two auth methods together". Is
>> that the case? If not, it is something that has been considered? Or it
>> is assumed people will write their own auth plugins rather than
>> combining existing ones?
>>
>
> It was definitely not assumed that folks would write there own auth
> plugins. The TOTP auth plugin was meant to be just be an alternative to
> password auth. We had hoped it would provide the building blocks for MFA,
> but see above comment.
>
> From there I went toward writing our own Keystone Auth plugin and had a
>> lot of success with that. The current iteration is a combination of the
>> password and totp plugins where for users with TOTP credentials we
>> expect a 6 digit password appended to the password. In the config I then
>> replace the default password plugin with my own.
>>
>
> I assume appending the TOTP password to the regular password is gonna be a
> big 'nope' from UX folks :)
> Though points for being clever and avoiding the whole negotiate/challenge
> the user for extra information.
>
>

For what it's worth, this is typically how TOTP works with federated users,
you have a fixed known number of digits (6) added to a known password. For
example, when I auth, I have my "password" and then the TOTP token
concatenated. The server then splits the passed in value and handles
authentication. I've seen it where it is done both with a fixed length
"pin/password" and a "up to XXX characters" password.

I don't know why the UX folks would have issues with this, since it is a
common and relatively painless option. The hard part still is "does this
user always need 2FA or only for certain projects?" As to that, my
inclination is the user must always use 2FA if it is enabled for the user;
some projects may require a user to have 2FA. So in short, if you use a
project that requires 2FA, the user will always use 2FA. Alternatively, the
user could disable 2FA but would be restricted from using the projects that
require it.

Since we aren't guaranteed a web-interface, the really cool things like
U2F, wont always work (which is more of the challenge/response style).


>
>> In testing this seems to work as intended. All normal users are
>> unaffected while users with a TOTP credential now must append their
>> passcode to their password.
>>
>> I've made a blueprint for this plugin:
>> https://blueprints.launchpad.net/keystone/+spec/password-totp-plugin
>>
>> and the code I am currently testing is in the associated review:
>> https://review.openstack.org/#/c/343422/
>>
>> If this plugin is useful to others, and this seemed like a sensible
>> solution, I will write some unit tests and work on getting it merged.
>>
>>
>> So, my main question, does this plugin seem like a sensible solution to
>> MFA in OpenStack in the way we needed or are there other paths I should
>> be going down?
>>
>> Cheers,
>> -Adrian Turjak
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [Keystone] Multi-factor Auth with Keystone and TOTP

[Steve Martinelli]

Several comments inline

On Mon, Jul 18, 2016 at 12:20 AM, Adrian Turjak 
wrote:

> Hello,
>
> I've been looking at options for doing multi-factor auth (MFA) on our
> infrastructure and I'm just wanting to know if the option I've decided
> to go with seems sensible.
>
> As context, we are running stock Keystone (to be backed by LDAP), we
> wanted to be able to enable MFA on a per user basis, and a user with MFA
> enabled should either be blocked from using the APIs or required MFA to
> use the APIs.
>
>
We discussed adding MFA support in Newton at the Austin summit and didn't
come to a happy conclusion (aside from "let federated users have MFA since
it's built in"). Part of the trouble was deciding where to enforce MFA.
Should a user *always* require MFA just because he has a TOTP credential?
What if the user has multiple projects, and wants MFA to access projectA,
but not projectB.


> I was looking at the current TOTP module in keystone, but seeing as that
> simply adds another optional Auth method to keystone it seems fairly
> useless for our needs. Unless I'm missing something, there seems to be
> no way in Keystone to enforce "use these two auth methods together". Is
> that the case? If not, it is something that has been considered? Or it
> is assumed people will write their own auth plugins rather than
> combining existing ones?
>

It was definitely not assumed that folks would write there own auth
plugins. The TOTP auth plugin was meant to be just be an alternative to
password auth. We had hoped it would provide the building blocks for MFA,
but see above comment.

>From there I went toward writing our own Keystone Auth plugin and had a
> lot of success with that. The current iteration is a combination of the
> password and totp plugins where for users with TOTP credentials we
> expect a 6 digit password appended to the password. In the config I then
> replace the default password plugin with my own.
>

I assume appending the TOTP password to the regular password is gonna be a
big 'nope' from UX folks :)
Though points for being clever and avoiding the whole negotiate/challenge
the user for extra information.


>
> In testing this seems to work as intended. All normal users are
> unaffected while users with a TOTP credential now must append their
> passcode to their password.
>
> I've made a blueprint for this plugin:
> https://blueprints.launchpad.net/keystone/+spec/password-totp-plugin
>
> and the code I am currently testing is in the associated review:
> https://review.openstack.org/#/c/343422/
>
> If this plugin is useful to others, and this seemed like a sensible
> solution, I will write some unit tests and work on getting it merged.
>
>
> So, my main question, does this plugin seem like a sensible solution to
> MFA in OpenStack in the way we needed or are there other paths I should
> be going down?
>
> Cheers,
> -Adrian Turjak
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Keystone] Multi-factor Auth with Keystone and TOTP

[Adrian Turjak]

Hello,

I've been looking at options for doing multi-factor auth (MFA) on our
infrastructure and I'm just wanting to know if the option I've decided
to go with seems sensible.

As context, we are running stock Keystone (to be backed by LDAP), we
wanted to be able to enable MFA on a per user basis, and a user with MFA
enabled should either be blocked from using the APIs or required MFA to
use the APIs.

I was looking at the current TOTP module in keystone, but seeing as that
simply adds another optional Auth method to keystone it seems fairly
useless for our needs. Unless I'm missing something, there seems to be
no way in Keystone to enforce "use these two auth methods together". Is
that the case? If not, it is something that has been considered? Or it
is assumed people will write their own auth plugins rather than
combining existing ones?

>From there I went toward writing our own Keystone Auth plugin and had a
lot of success with that. The current iteration is a combination of the
password and totp plugins where for users with TOTP credentials we
expect a 6 digit password appended to the password. In the config I then
replace the default password plugin with my own.

In testing this seems to work as intended. All normal users are
unaffected while users with a TOTP credential now must append their
passcode to their password.

I've made a blueprint for this plugin:
https://blueprints.launchpad.net/keystone/+spec/password-totp-plugin

and the code I am currently testing is in the associated review:
https://review.openstack.org/#/c/343422/

If this plugin is useful to others, and this seemed like a sensible
solution, I will write some unit tests and work on getting it merged.


So, my main question, does this plugin seem like a sensible solution to
MFA in OpenStack in the way we needed or are there other paths I should
be going down?

Cheers,
-Adrian Turjak

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev