<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 16/05/17 16:13, Colleen Murphy
wrote:<br>
</div>
<blockquote
cite="mid:CAJkgcEk_EufM3YoaWCtAPOMPHKDeOxfQaV4Uue4AfQPGG4+u0g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Tue, May 16, 2017 at 2:07 AM,
Adrian Turjak <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:adriant@catalyst.net.nz" target="_blank">adriant@catalyst.net.nz</a>></span>
wrote:</div>
<div class="gmail_quote"><snip>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"> <br>
Tangentially related to this (because my reasons are
different), on our cloud I'm actually working on
something like this, but under the hood all I'm doing is
creating a user with a generated password and enforcing
a username convention. I ask them for a name and what
roles they want for the user and I spit out:<br>
username: "service_user_for_web_app_1@<<wbr>project_id>"<br>
password: "<some_generated_password>"<br>
<br>
</div>
</blockquote>
<div> </div>
On Tue, May 16, 2017 at 4:10 AM, Adrian Turjak <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:adriant@catalyst.net.nz" target="_blank">adriant@catalyst.net.nz</a>></span> wrote:
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<div>
<div class="gmail-h5"><br>
<div
class="gmail-m_-2800704788950076425moz-cite-prefix">On
16/05/17 14:00, Adrian Turjak wrote:</div>
</div>
</div>
</div>
</blockquote>
<div><snip> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<div>
<div class="gmail-h5">
<blockquote type="cite">I'm just concerned that this
feels like a feature we don't really need when
really it's just a slight variant of a user with a
new auth model (that is really just another
flavour of username/password). The sole reason
most of the other cloud services have API keys is
because a user can't talk to the API directly.
OpenStack does not have that problem, users are
API keys. So I think what we really need to
consider is what exact benefit does API keys
actually give us that won't be solved with users
and better policy?<br>
<br>
From my look at the specs the only feature
difference compared to users is optional expiry of
the API keys. Why make something entirely
different for just that one feature when, as David
says in his spec, there is debate if that feature
is even a good idea.<br>
<br>
As an application developer, I don't see why I
can't just create a user and limit the roles. I
feel as if this is better addressed with
documentation because it almost sounds like people
are asking for something that already exists, but
just doesn't have as nice an API as they would
like. Another option, make a better API in
Keystone for user creation/management alongside
the old one? That's pretty much what we did,
except we wrote a service to act as a
proxy/wrapper around Keystone for some customer
actions.<br>
</blockquote>
</div>
</div>
If expiry is the killer feature, why no just add it to
users? Temporary user accounts could solve that, and
probably be useful beyond the scope of just API keys.<br>
</div>
</blockquote>
<div> </div>
<div>It's not just expiry. I think your proposal is missing
one of the major use cases: empowerment of non-admin
users. A non-admin can't create new users themselves, they
have to (as you've pointed out) ask an admin to do it for
them. As an application developer, I want to be able to
delegate a subset of my own roles to a programmatic entity
without being dependent on some other human. One of the
(numerous) specs proposed seeks to address that use case: <a
moz-do-not-send="true"
href="https://review.openstack.org/#/c/396634">https://review.openstack.org/#/c/396634</a></div>
<div><br>
</div>
<div>Colleen<br>
</div>
</div>
</div>
</div>
<br>
</blockquote>
<br>
That still doesn't seem like justification enough to make an
entirely new auth type and 'user-lite' model. The problem is that
you have to be admin to create users, that shouldn't have to be the
case. You should be able to create users, but ONLY give them roles
for your projects or your project tree. Keystone doesn't do that,
and there is no way with policy to do that currently. Hell, we wrote
a service just to do that on behalf our customers since keystone
didn't give us that that level of control, and because we really
didn't want them needing an admin to do it for them.<br>
<br>
So the features we are after are:<br>
- the ability as a non-admin to create user or user-like access
objects.<br>
- the ability to maybe expire those<br>
<br>
This is still sounding like a feature to get around flaws in the
current system rather than fix those flaws. Are we saying it is
easier and better to introduce more models and complexity than fix
the existing system to make it useful? We only did it in an external
service because we had additional requirements that didn't fit fit
into core keystone, but then ended up with a nice place to do some
wrapper logic around the limited keystone user management.<br>
</body>
</html>