On 09/02/18 15:50, Lance Bragstad wrote: > On 02/08/2018 03:36 PM, Adrian Turjak wrote: >> My plan for the Rocky cycle is to work in Keystone and address the missing >> pieces I need to get MFA working properly throughout OpenStack in an >> actually useful way, and I'll provide updates for that once I have the specs >> ready to submit (am waiting until start of Rocky for that). The good thing, >> is that this current solution for MFA works, and it can be migrated from to >> the methods I intend to work on for Rocky. The same credential models will >> be used in Keystone, and I will write tools to take users with TOTP >> credentials and configure auth rules for them for more official MFA support >> in Keystone once it is useful. > Are you planning to revive the previous proposal [0]? We should have > stable/queens branch by EOW, so Rocky development will be here soon. Are > you planning on attending the PTG? It might be valuable to discuss what > you have and how we can integrate it upstream. I thought I remember the > issue being policy related (where admins were required to update user > secrets and it wasn't necessarily a self-serving API). Now that we're in > a better place with system-scope, we might be able to move the ball > forward a bit regarding your use case. > > [0] https://review.openstack.org/#/c/345705/ So the use case is not just self-management, that's a part of it, but one at least we've solved outside of Keystone. The bigger issue is that MFA as we currently have it in Keystone is... unfinished and very hard to consume.
And no I won't be coming to the PTG. :( The multi-auth-method approach is good, as are the per user auth rules, but right now nothing is consuming it using more than one method. In fact KeystoneAuth doesn't know how to deal with it. In part that is my fault since I put my hand up to make KeystoneAuth work with Multi-method auth, but... I gave up because it got ugly fast. We could make auth methods in KeystoneAuth that are made up of multiple methods, but then you need an explicit auth module for each combination... We need to refactor that code to allow you to specify a combination and have the code underneath do the right thing. The other issue is that you always need to know ahead of time how to auth for a given user and their specific auth rules, and you can't programmatically figure that out. The missing piece is something that allows us to programmatically know what is missing when 1 out of 2+ auth rules succeeds. When a user with more than 1 auth rule attempts to auth to Keystone, if they auth with 1 rule, but need 2 (password and totp), then the auth will fail and the error will be unhelpful. Even if the error was helpful, we can't rely on parsing error messages, that's unsafe. What should happen is Keystone acknowledges they were successful with one of their configured auth rules, at which point we know this user is 'probably' who they say they are. We now pass them a Partially Authed Token, which says they've already authed with 'password', but are missing 'totp' to complete their auth. The user can now return that token, and the missing totp auth method, and get back a full token. So the first spec I intend to propose is the Partially Authed Token type. Which solves the challenge response problem we have, and lets us actually know how to proceed when auth is unfinished. Once we have that, we can update KeystoneAuth, then the CLI to support challenge response, and then Horizon as well. Then we can look at user self management of MFA. Amusingly the very original spec that brought it multi-auth methods into Keystone talked about the need for a 'half-token': https://adam.younglogic.com/2012/10/multifactor-auth-and-keystone/ https://blueprints.launchpad.net/keystone/+spec/multi-factor-authn https://review.openstack.org/#/c/21487/ But the 'half-token' was never implemented. :( The MFA method in this original email was just... replace the password auth method with one that expects an appended totp passcode. It's simple, it doesn't break anything nor expect more than one auth method, it works with Horizon and the CLI because of that, but it doesn't do real challenge response. It's a stop gap measure for us since we're on an older version of Keystone, and because the current methods are too hard for our customers to actually consume. And most importantly, I can migrate users from using it to using user auth rules, since Keystone already stores the totp credential and all I need to then do is make auth rules for users with a totp cred. Hope that explains my plan, and why I'm going to be proposing it. It's going to be a lot of work. :P _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
