Open Stack

Hey Adam - 

so what I'm missing on all of this is 

1) what's the API and how does a service and user interact with it?

2) what's the gist of the code - have it in a github repo or something to see your initial implementation?

Trust, delegation, impersonation - whatever - the need that you laid out in your blog post is great. Glance and Nova have the exact same needs
(the blog post isn't a spec, by the way - you should update the BP to point to something other than your motivations for making it)

In terms of the choices, I'd like to see the API and how you've taken a stab at implementing it to suggest some possible solutions. With no other knowledge, I'm tempted to assert it should be it's own backend, even knowing that's relatively heavy weight.

-joe

On Nov 28, 2012, at 7:45 AM, Adam Young <ayoung at redhat.com> wrote:
> I have a very rudimentary Trust  (what I used to call Preauth https://blueprints.launchpad.net/keystone/+spec/trusts) implementation working with the SQL backend for Identity.
> 
> With LDAP, I am not sure where I would store the trust information. The data for the trust itself is simply the uuid user_ids for the trustor and  trustee and tenant Id.  There is also a table for the roles, and a second table for the endpoints associated with the trust.While we could shoehorn this into the user object, I am not sure that there is an intuitive way to implement it in LDAP.
> 
> I see three choices.
> 
> 1.  Leave the Trusts in the identity schema.  This has the nice effect of keeping the user-ids as foreign keys.  It has the drawback of forcing an LDAP backend solution.
> 2.  Move the Trusts into the Token backend.  This will get avoid the issue of LDAP support.  It does mean that tokens, which is a schema that is high volume, read intensive, and populated by short lifespan entities, gets mixed with trusts, which is low volume, and long lived.
> 3. Move it into its own backend.  This seems a little heavy weight.
> 
> 
> Thoughts?
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev