Open Stack

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