Open Stack

Adam,

   In this model can I do a...

   grant trust key for user foo that is read on keystone, constrained to
tenant uuid bar  ?

   That's probably enough for my needs.

-Matt

On Wed, 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.
>
> 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.
>
>
>
>
>> -joe
>>
>> 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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121128/9278d365/attachment.html>