<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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!<br>
<br>
<br>
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.<br>
<br>
<div class="moz-cite-prefix">On 27/05/17 03:21, Lance Bragstad
wrote:<br>
</div>
<blockquote
cite="mid:CAE6oFcGG_6NiEM3e0Ak9jXVzZvCUiPb=Upkb3syhfF+QpwcpKQ@mail.gmail.com"
type="cite">
<div dir="ltr">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?
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Does this interest anyone?</div>
<div>
<div><br>
</div>
<div><br>
</div>
<div>[0] <a moz-do-not-send="true"
href="https://etherpad.openstack.org/p/pike-ptg-keystone-deprecations">https://etherpad.openstack.org/p/pike-ptg-keystone-deprecations</a></div>
<div>[1] <a moz-do-not-send="true"
href="https://review.openstack.org/#/c/438096/">https://review.openstack.org/#/c/438096/</a></div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>