Open Stack

More comments inline.

On Mon, Jul 18, 2016 at 9:13 AM, Adrian Turjak <adriant at catalyst.net.nz>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160718/2c62c400/attachment.html>