Open Stack

Reading this again, why dont you rename this to delegation and change 
the spec as follows


On 28/11/2012 15:45, Adam Young 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
delegation

  itself is simply the uuid user_ids for the
delegator and delegate, along with the privileges that are being delegated.
The delegated privileges are a combination of a tenant id and a number 
of roles (that must belong to the delegator). If all privileges are 
missing, then nothing is being delegated (ie. there is not a way of 
saying "delegate everything"). A final parameter, delegation depth, says 
whether the delegation is recursive or not, and if recursive specifies 
the length of the delegation chain. A value of 0 (or missing) means that 
the delegate cannot delegate these permissions further. A value of 1 
means that the delegate can delegate the permissions to any set of 
delegates but the latter cannot delegate further. A value of 2 means the 
delegation chain can be extended by a further length of 2 (ie. delegator 
to delegate to subdelegate to subsubdelegate). A value of infinity means 
that the delegation is infinitely recursive.

  There is also an optional
> second table for the endpoints associated with the
delegation. This further restricts the delegation to only the endpoints 
in this table. If the endpoints are missing, then the delegation is for 
all endpoints associated with the delegated tenant.

There is also an optional third table for the delegation duration, which 
comprises the start time and end time for the delegation.

regards

David


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