Open Stack

It seems like I should just have to know the User ID of the person that
trusts me, not an ID of the relationship. I'm not even sure the
relationship needs an ID, unless there's some metadata involved (e.g.
expiration).


-Dolph


On Thu, Nov 29, 2012 at 8:49 AM, Adam Young <ayoung at redhat.com> wrote:

> On 11/28/2012 06:21 PM, 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?
>>
>
> Swift.  It has to know how to fetch the token to use for its call.
> Anything that is currently cacheing a userid/password in order to create a
> token will, in the future, use a Trust ID and its own credentials to get a
> token instead.
>
>
>
>>  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<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>
>>>>>
>>>> ______________________________**_________________
>>>> 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>
>>>
>>
>> ______________________________**_________________
>> 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/20121129/3c547662/attachment.html>