Open Stack

On 11/28/2012 11:05 AM, David Chadwick wrote:
> Hi Adam
>
> I have seen your spec and commented on it. This is yet another case of 
> delegation is it not?
OK,  we've had a long discussion on this, and I think I can clarify.

1.  We've used "delegation" to mean many things.  I was using it to mean 
delegation from one Keystone server to another, in a(n) hierarchy. Maybe 
I am showing the effects of my time in the Army, but to me delegation is 
something that goes down from superiod to subordinate.

2.  There are two related Legal terms I considered: Proxy and Trusts.  I 
ruled out the term "Proxy" due to its compete overuse.

3.  Regardless of whether we call it delegation or trust, we are 
discussing the same thing.
 From David Chadwich"

"Keystone is the Delegation Service that handles all the delegations for 
users. It is trusted to ensure that

i) a delegator cannot delegate an attribute he has not already been 
assigned
ii) a delegator cannot delegate once the delegation depth has been consumed
iv) a delegator cannot delegate outside the validity period of his own 
delegation.

In other words, a delegator can only delegate less than (or equal to) 
what he already has, and not more than it. "

I think that is a great prelude to the design discussion.

Right now, a user delegates in a short term fashion using tokens. Once a 
token has been granted to a user, he hands that off to another (service) 
user in order to prove his identity and authorization to perform some 
set of actions.  In addition, since tokens are not scoped to a specific 
endpoint, they are currently passed on from one endpoint to another.  
This is not a secure approach.  If any endpoint along the way is 
compromised, all the tokens in that endpoint are usable against any 
other service that accepts tokens.

So  we limit the scope of tokens to only that single endpoint, and we 
remove the attack.  As a result, we also remove the ability of the 
remote service user  to request additional operations from additional 
remote services on behalf of the original user.  This is a problem that 
the trusts are designed to serve.

A trust is a promise to allow delegation at some point in the future.  
The actual delegation is performed in the token.  The trust is used to 
get the token.

Now,  as far as implementation goes, I would like to propose two phases.

1.  Trusts get implemented today "hard wired" with the attributes that 
are currently exposed in a token:  (trustor) user, tenant, roles, endpoints.
2.  Tokens that get generated from the trusts will look just like normal 
tokens.  They will have an additional field "trustee".  This will allow 
the current consumers of tokens to continue to use a trust token just 
like they do now.

Phase 2.
1.  Modify the token architecture to allow arbitrary sets of attributes.
2.  Modify the trust architecture to specify arbitrary sets of 
attributes to be used in a token.



Regarding my original question, I am going to move the trust driver into 
the token back end.  It has become apparent that this is where it 
belongs, as it has the exact same dependencies and usage patterns as the 
tokens, and it is the Keystone "application specific" data.






>
> regards
>
> David
>
> 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 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