Open Stack

Hi Adam

On 28/11/2012 16:16, Adam Young wrote:
> 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.

  No I am not suggesting that, since delegation should ideally be 
independent of protocol. What I am suggesting is that delegation is 
implemented, as a general purpose delegation service, that can be used 
by all the multiple use cases that require delegation, rather then 
implementing a very narrow functional spec of delegation that might only 
be applicable for this one use case only, because then you will end up 
with multiple different delegation mechanisms that only serve to confuse 
and add redundant code and complexity to the overall implementation.


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

   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.

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

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
>