More comments inline. On Mon, Jul 18, 2016 at 9:13 AM, Adrian Turjak <adri...@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.
__________________________________________________________________________ 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