Open Stack

Call a dog a dog. If you are doing impersonation call it that, along 
with all its negative connotations, because it is BAD!!!


But I think you can modify your model slightly to make it good old 
delegation, true and proper, as per my previous email

David
On 28/11/2012 17:38, Adam Young wrote:
>
>>
>>>
>>> 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
>>>
>