Open Stack

On Fri, Nov 30, 2012 at 8:53 AM, Adam Young <ayoung at redhat.com> 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?
>>
> 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.
>

Federation?


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

The concept is "delegating authorization to trusted entities," no? Modeling
it in the API as a "trust" between "users" sounds fine to me.


> 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<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 <OpenStack-dev at lists.openstack.org>
>>> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>>
>>
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121130/3b64508c/attachment.html>