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 mdel...@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 <sba...@redhat.com> To: openstack-dev@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev