Open Stack

>
>>
>> However, Kerberos, X509 and most other mechanisms have a comparable
>> mechanism, and they are all fairly new.
>
> Actually I am very familiar with X.509 delegation since I edited the 
> 2001 spec in which it was first included using attribute certificates. 
> So it is not new, its over 10 years old.

Heh,  new in implementation, then.  Good stuff, and I would rather be 
working on top of an established spec like this than inventing our own 
but...

>
>   In Kerberos, it is S4U2Proxy.
>> In X509, Proxy certificates http://www.ietf.org/rfc/rfc3820.txt
>
> Proxy certs are not delegation, they are impersonation.
> You effectively give your identity cert to someone else.

Yes, that is exactly what we are doing here.  Impersonation.  The terms 
are used differently in different places.  I suspect that is the cause 
of any confusion here.  I realize that in Kerberos the term trusts is 
used almost exclusively cross domain.  You can understand why I wanted 
to avoid the term proxy.  I had thought about using impersonation, but 
that has negative connotations.

>
>  .  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.
>
> What I am suggesting is that a delegator should delegate an attribute 
> (type-value pair) to a delegate. In this way a delegator can finely 
> control which permissions he delegates, and the delegate will always 
> present this attribute for authorisation to the service. The delagate 
> will authenticate with its own name and not that of the delegator.
>
> Unless I am wrong, I think your solution has a delegator (user ID) and 
> delegate (user ID) but is missing the attribute that is delegated. So 
> the implicit assumption must be that the delegator is giving all his 
> privileges in an unrestricted manner to the delegate (which is dangerous)

So in this case, it is not an unrestricted delegation, but rather 
confined based on:

A subset of roles and/or A subset of endpoints.  I thought we had linked 
to that etherpad from the spec, but I see we haven't.  My origianl write 
up is here:

http://adam.younglogic.com/2012/10/preauthorization-in-keystone/

I can't seem to find the Etherpad from the summit.  I know we discussed 
it, but maybe iut was in the context of one of the other sessions.






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