<font size=2 face="sans-serif">Hi Steve,</font>
<br>
<br><font size=2 face="sans-serif">Thank you -- this clarifies things quite
a bit. </font>
<br>
<br><font size=2 face="sans-serif">I'd like to join that discussion at
the summit if possible. </font>
<br>
<br><font size=2 face="sans-serif">-M</font>
<br><font size=2 face="sans-serif"><br>
________________________________<br>
Kind Regards,<br>
<br>
Michael D. Elder<br>
<br>
STSM | Master Inventor<br>
mdelder@us.ibm.com | linkedin.com/in/mdelder<br>
<br>
"Success is not delivering a feature; success is learning how to solve
the customer’s problem.” -Mark Cook</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Steven Hardy <shardy@redhat.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"OpenStack Development
Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">04/07/2014 12:00 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [openstack-dev]
[heat] Problems with Heat software configurations and KeystoneV2</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>On Sun, Apr 06, 2014 at 10:22:15PM -0400, Michael
Elder wrote:<br>
> If Keystone is configured with an external identity provider (LDAP,
<br>
> OpenID, etc), how does the creation of a new user per resource affect
that <br>
> external identity source? <br>
<br>
My understanding is that it should be possible to configure keystone to
use<br>
multiple (domain specific) identity backends.<br>
<br>
So a possible configuration could be to have "real" users backed
by the<br>
LDAP directory, and have all projects/users associated with heat (which
are<br>
created in a special "heat" domain, completely separated from
"real" users)<br>
backed by some other identity backend, e.g Sql.<br>
<br>
</font></tt><a href="http://docs.openstack.org/developer/keystone/configuration.html#domain-specific-drivers"><tt><font size=2>http://docs.openstack.org/developer/keystone/configuration.html#domain-specific-drivers</font></tt></a><tt><font size=2><br>
<br>
This is something we should definitely test, and I'd welcome feedback from<br>
the keystone folks, or anyone who has experience with this functionality,<br>
as to how well it works in Icehouse.<br>
<br>
> My suggestion is broader, but in the same spirit: Could we consider
<br>
> defining an _authorization_ "stack" token (thanks Adam),
which acts like <br>
> an OAuth token (by delegating a set of actionable behaviors that a
token <br>
> holder may perform). The "stack" token would be managed
within the stack <br>
> in some protected form and used for any activities later performed
on <br>
> resources which are managed by the stack. Instead of imposing user
<br>
> administration tasks like creating users, deleting users, etc against
the <br>
> Keystone database, Heat would instead provide these "stack"
tokens to any <br>
> service which it connects to when managing a resource. In fact, there's
no <br>
> real reason that the "stack" token couldn't piggyback on
the existing <br>
> Keystone token mechanism, except that it would be potentially longer
lived <br>
> and restricted to the specific set of resources for which it was granted.
<br>
<br>
So oauth was considered before we implemented the domain-isolated users,<br>
but it was not possible to persue due to lack of client support:<br>
<br>
</font></tt><a href=https://wiki.openstack.org/wiki/Heat/Blueprints/InstanceUsers><tt><font size=2>https://wiki.openstack.org/wiki/Heat/Blueprints/InstanceUsers</font></tt></a><tt><font size=2><br>
</font></tt><a href="https://blueprints.launchpad.net/heat/+spec/oauth-credentials-resource"><tt><font size=2>https://blueprints.launchpad.net/heat/+spec/oauth-credentials-resource</font></tt></a><tt><font size=2><br>
<br>
The main issue with tokens as provided by keystone today, is that they
will<br>
expire. That is the main reason for chosing to create a user rather
than<br>
e.g a token limited in scope via a trust - if you put it in the instance,<br>
you have to refresh it before expiry, which may not always be possible.<br>
<br>
Additionally, you don't really want the credentials deployed inside a<br>
(implicitly untrusted) instance derived from the operator who created the<br>
stack - you want something associated with the stack but completely<br>
isolated from "real" users<br>
<br>
Your "stack" token approach above appears to indicate that Heat
would<br>
somehow generate, and maintain the lifecycle of, some special token which<br>
is not owned by keystone. This idea has been discussed, and rejected,<br>
because we would prefer to make use of keystone functionality instead of<br>
having the burden of maintaining our own bespoke authorization system.<br>
<br>
If implementing something based on oauth, or some sort of scope-limited<br>
non-expiring token, becomes possible, it's quite likely we can provide
the<br>
option to do something other than the domain isolated users which has been<br>
impelmented for Icehouse.<br>
<br>
Ultimately, we had to use what was available in keystone *now* to enable<br>
delivery of something which worked for Icehouse, hence the decision to
use<br>
what is available in the keystone v3 API.<br>
<br>
> Not sure if email is the best medium for this discussion, so if there's
a <br>
> better option, I'm happy to follow that path as well. <br>
<br>
I think it's fine, and I'm happy to get constructive feedback on the the<br>
current approach, along with ideas for roadmap items which can potentially<br>
improve it.<br>
<br>
I have proposed this summit session which may provide more opportunity
for<br>
discussion, if accepted:<br>
<br>
</font></tt><a href=http://summit.openstack.org/cfp/details/190><tt><font size=2>http://summit.openstack.org/cfp/details/190</font></tt></a><tt><font size=2><br>
<br>
Steve<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
<br>
</font></tt>
<br>