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?

Yes it is.  It is required for many use cases, and in this particular 
case, it is somerthing that has to be done within the scope of the 
existing providers.

If you are suggesting that we should have started with SAML or some 
other starting point, I won't argue with you.

However, Kerberos, X509 and most other mechanisms have a comparable 
mechanism, and they are all fairly new.  In Kerberos, it is S4U2Proxy.  
In X509, Proxy certificates http://www.ietf.org/rfc/rfc3820.txt  .  So, 
while I agree that we are reinventing the wheel here, we are doing so in 
a fairly limited, light weight way that is essential the rest of the 
Keystone-dependent services.


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