Open Stack

On Sun, Jul 17, 2016 at 10:37 PM, Steve Martinelli <s.martinelli at gmail.com>
wrote:

> Several comments inline
>
> On Mon, Jul 18, 2016 at 12:20 AM, Adrian Turjak <adriant at catalyst.net.nz>
> wrote:
>
>> Hello,
>>
>> I've been looking at options for doing multi-factor auth (MFA) on our
>> infrastructure and I'm just wanting to know if the option I've decided
>> to go with seems sensible.
>>
>> As context, we are running stock Keystone (to be backed by LDAP), we
>> wanted to be able to enable MFA on a per user basis, and a user with MFA
>> enabled should either be blocked from using the APIs or required MFA to
>> use the APIs.
>>
>>
> We discussed adding MFA support in Newton at the Austin summit and didn't
> come to a happy conclusion (aside from "let federated users have MFA since
> it's built in"). Part of the trouble was deciding where to enforce MFA.
> Should a user *always* require MFA just because he has a TOTP credential?
> What if the user has multiple projects, and wants MFA to access projectA,
> but not projectB.
>
>
>> I was looking at the current TOTP module in keystone, but seeing as that
>> simply adds another optional Auth method to keystone it seems fairly
>> useless for our needs. Unless I'm missing something, there seems to be
>> no way in Keystone to enforce "use these two auth methods together". Is
>> that the case? If not, it is something that has been considered? Or it
>> is assumed people will write their own auth plugins rather than
>> combining existing ones?
>>
>
> It was definitely not assumed that folks would write there own auth
> plugins. The TOTP auth plugin was meant to be just be an alternative to
> password auth. We had hoped it would provide the building blocks for MFA,
> but see above comment.
>
> From there I went toward writing our own Keystone Auth plugin and had a
>> lot of success with that. The current iteration is a combination of the
>> password and totp plugins where for users with TOTP credentials we
>> expect a 6 digit password appended to the password. In the config I then
>> replace the default password plugin with my own.
>>
>
> I assume appending the TOTP password to the regular password is gonna be a
> big 'nope' from UX folks :)
> Though points for being clever and avoiding the whole negotiate/challenge
> the user for extra information.
>
>

For what it's worth, this is typically how TOTP works with federated users,
you have a fixed known number of digits (6) added to a known password. For
example, when I auth, I have my "password" and then the TOTP token
concatenated. The server then splits the passed in value and handles
authentication. I've seen it where it is done both with a fixed length
"pin/password" and a "up to XXX characters" password.

I don't know why the UX folks would have issues with this, since it is a
common and relatively painless option. The hard part still is "does this
user always need 2FA or only for certain projects?" As to that, my
inclination is the user must always use 2FA if it is enabled for the user;
some projects may require a user to have 2FA. So in short, if you use a
project that requires 2FA, the user will always use 2FA. Alternatively, the
user could disable 2FA but would be restricted from using the projects that
require it.

Since we aren't guaranteed a web-interface, the really cool things like
U2F, wont always work (which is more of the challenge/response style).


>
>> In testing this seems to work as intended. All normal users are
>> unaffected while users with a TOTP credential now must append their
>> passcode to their password.
>>
>> I've made a blueprint for this plugin:
>> https://blueprints.launchpad.net/keystone/+spec/password-totp-plugin
>>
>> and the code I am currently testing is in the associated review:
>> https://review.openstack.org/#/c/343422/
>>
>> If this plugin is useful to others, and this seemed like a sensible
>> solution, I will write some unit tests and work on getting it merged.
>>
>>
>> So, my main question, does this plugin seem like a sensible solution to
>> MFA in OpenStack in the way we needed or are there other paths I should
>> be going down?
>>
>> Cheers,
>> -Adrian Turjak
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160717/1d225887/attachment.html>