So I've actually been using the credentials API for some of my work
towards MFA, different types of MFA, and even different stages for MFA.
For example (totp in this case), I first have a service create a user's
totp secret as type 'totp-draft' so that the totp auth method can't use
it, but so that my service can store and then access it in Keystone to
do an initial challenge response before making it type 'totp' so it can
be used for MFA.
I'm also playing with a credential type for MFA of the type CIDR which
takes a CIDR formatted ip address, and allows an additional auth factor
which is source ip address. In the auth module we check that the CIDR
credentials for the user match the proxy forwarded source IP. So for
service/automated accounts you can set a range of ips that it can auth
from. This is useful because often these could have a lot of power but
since they are automated TOTP is not a valid multi-factor auth.
So, for me, the flexibility of the credentials API is really useful. I'm
trying to find useful/different MFA options, and credentials is a great
place to store data about them, so I want/need something like it. If
moved to the user object, and we make it flexible rather than hard .totp
or .ec2 values, I'm all for it. Maybe user.credentials and have that act
as a mini credentials manager of sorts, or a mini credentials API on a
per user basis.
I'd love to help here, but I've been swamped as is. I haven't even had
time to even properly finish/continue work on upstream Keystone MFA in
ages. So I only tentatively put my hand up for helping with this!
Following that, the way we handle ec2 currently is fairly awful. The
access secret is pretty much a password and we store that in plain text,
and even with the addition of encryption for credentials, that's stupid.
The access key, sure, but the access secret should have always been
hashed because a user should only even see that secret the first time
when we generate it just like on real AWS. I'll be honest I haven't
looked at how the auth works for ec2, I'd assume it could be changed to
hash and compare, but I could be wrong.
On 27/05/17 03:21, Lance Bragstad wrote:
> At the PTG in Atlanta, we talked about deprecating the policy and
> credential APIs. The policy API doesn't do anything and secrets
> shouldn't be stored in credential API. Reasoning and outcomes can be
> found in the etherpad from the session [0]. There was some progress
> made on the policy API [1], but it's missing a couple patches to
> tempest. Is anyone willing to carry the deprecation over the finish
> line for Pike?
>
> According to the outcomes from the session, the credential API needs a
> little bit of work before we can deprecate it. It was determined at
> the PTG that we if keystone absolutely has to store ec2 and totp
> secrets, they should be formal first-class attributes of the user
> (i.e. like how we treat passwords `user.password`). This would require
> refactoring the existing totp and ec2 implementations to use user
> attributes. Then we could move forward with deprecating the actual
> credential API. Depending on the amount of work required to make .totp
> and .ec2 formal user attributes, I'd be fine with pushing the
> deprecation to Queens if needed.
>
> Does this interest anyone?
>
>
> [0] https://etherpad.openstack.org/p/pike-ptg-keystone-deprecations
> [1] https://review.openstack.org/#/c/438096/
>
>
> __
> 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
__
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
