Open Stack

this is delegation pure and simple.

The only thing you need to change this from trust (which is actually
impersonation) to delegation is the following

when cinder authenticates as itself, the token it gets says the user is
cinder but the resource owner is Joe. The tenant and role remain the 
same. The policy of swift needs enhancing to say that anyone who is the 
resource owner or his delegate can access the resource.

regards

David

On 28/11/2012 23:21, heckj wrote:
>
> On Nov 28, 2012, at 2:53 PM, Adam Young <ayoung at redhat.com> wrote:
>> On 11/28/2012 05:23 PM, heckj wrote:
>>> To be a little more specific, what I'm trying to understand is
>>> the workflow beyond the initial request to a service with the
>>> trust concept already set up -
>>>
>>> Say Joe requests a snapshot to be taken of a volume, and wants
>>> that dumped into object storage. The service doing the snapshot
>>> takes a while (sorry, it's just slow) - and 30 minutes later the
>>> service (cinder in my little example) wants to write data to
>>> object storage (swift) - what allows this to happen? What
>>> interactions and with what data stored where?
>> OK, let me get a better write up going.  I'll try to post something
>> in the next couple of days as far as how I think this is supposed
>> to work, but the short form:
>>
>>
>> user joe creates a trust.  trustor is joe, trustee is cinder,
>> tenant is joes_restaurant (eat at Joes!) and the role is what ever
>> is required to write to swift, so we will call it swift_write.
>>
>> when cinder goes to perform the action for joe, it authenticates to
>> keystone passing its service token and the trust id.  In return, it
>> gets back a token that has joe as the user_id, as well as all the
>> other information specified by the trust.  It uses that token to
>> write to swift.
>>
>> So swift would have to be modified to know about trusts.
>
> swift or the auth_token middleware pieces?
>
>> so the APIs would be something like
>>
>> POST v3/trusts  (create a new one) DELETE v3/trusts/<id>  (create a
>> new one) POST v3/tokens (get a token for a trust)
>>
>> But I'll write it up in more detail.
>>
>>
>>> On Nov 28, 2012, at 2:14 PM, heckj <heckj at mac.com> wrote:
>>>> Hey Adam -
>>>>
>>>> so what I'm missing on all of this is
>>>>
>>>> 1) what's the API and how does a service and user interact with
>>>> it?
>>>>
>>>> 2) what's the gist of the code - have it in a github repo or
>>>> something to see your initial implementation?
>>>>
>>>> Trust, delegation, impersonation - whatever - the need that you
>>>> laid out in your blog post is great. Glance and Nova have the
>>>> exact same needs (the blog post isn't a spec, by the way - you
>>>> should update the BP to point to something other than your
>>>> motivations for making it)
>>>>
>>>> In terms of the choices, I'd like to see the API and how you've
>>>> taken a stab at implementing it to suggest some possible
>>>> solutions. With no other knowledge, I'm tempted to assert it
>>>> should be it's own backend, even knowing that's relatively
>>>> heavy weight.
>>>>
>>>> -joe
>>>>
>>>> On Nov 28, 2012, at 7:45 AM, Adam Young <ayoung at redhat.com>
>>>> 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
>>>>
>>>>
>>>>>
_______________________________________________
>>>> OpenStack-dev mailing list OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>>
_______________________________________________
>>> OpenStack-dev mailing list OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>>
_______________________________________________
>> OpenStack-dev mailing list OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________ OpenStack-dev mailing
> list OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>