Open Stack

If Keystone is configured with an external identity provider (LDAP, 
OpenID, etc), how does the creation of a new user per resource affect that 
external identity source? 

My suggestion is broader, but in the same spirit: Could we consider 
defining an _authorization_ "stack" token (thanks Adam), which acts like 
an OAuth token (by delegating a set of actionable behaviors that a token 
holder may perform). The "stack" token would be managed within the stack 
in some protected form and used for any activities later performed on 
resources which are managed by the stack. Instead of imposing user 
administration tasks like creating users, deleting users, etc against the 
Keystone database, Heat would instead provide these "stack" tokens to any 
service which it connects to when managing a resource. In fact, there's no 
real reason that the "stack" token couldn't piggyback on the existing 
Keystone token mechanism, except that it would be potentially longer lived 
and restricted to the specific set of resources for which it was granted. 

Not sure if email is the best medium for this discussion, so if there's a 
better option, I'm happy to follow that path as well. 

-M 

________________________________
Kind Regards,

Michael D. Elder

STSM | Master Inventor
mdelder at us.ibm.com  | linkedin.com/in/mdelder

"Success is not delivering a feature; success is learning how to solve the 
customer’s problem.” -Mark Cook



From:   Steve Baker <sbaker at redhat.com>
To:     openstack-dev at lists.openstack.org
Date:   04/06/2014 09:16 PM
Subject:        Re: [openstack-dev] [heat] Problems with Heat software 
configurations and KeystoneV2



On 07/04/14 12:52, Michael Elder wrote:


I think the net of the statement still holds though: the Keystone token 
mechanism defines a mechanism for authorization, why doesn't the heat 
stack manage a token for any behavior that requires authorization? 
Heat does use a token, but that token is associated with a user which can 
only perform limited operations on one heat resource. This reduces the 
risk that an unauthorized action can be performed due to using some form 
of shared user._______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
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/20140406/076c218b/attachment.html>