<div dir="ltr">More comments inline. <br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 18, 2016 at 9:13 AM, Adrian Turjak <span dir="ltr"><<a href="mailto:adriant@catalyst.net.nz" target="_blank">adriant@catalyst.net.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><p dir="ltr">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. </p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p></blockquote><div>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.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<p dir="ltr">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.</p></blockquote><div>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 (<a href="https://review.openstack.org/#/c/343422/">https://review.openstack.org/#/c/343422/</a>) and not be it's own plugin.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<p dir="ltr">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</p></blockquote><div>If you do push a specification forward, then I think this is a fine limitation to state. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<p dir="ltr">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.</p>
<p dir="ltr"></p></blockquote><div>Good point.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><p dir="ltr">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.<br></p></blockquote><div>++ <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><p dir="ltr"></p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p></blockquote><div>How about a specification instead? <a href="https://github.com/openstack/keystone-specs">https://github.com/openstack/keystone-specs</a> :)</div><div>It's unlikely to land in Newton, but would be a candidate for O.</div><div> </div></div></div></div>