Adam, <br><br>   In this model can I do a...<br> <br>   grant trust key for user foo that is read on keystone, constrained to tenant uuid bar  ?<br><br>   That's probably enough for my needs.<br><br>-Matt<br><br><div class="gmail_quote">
On Wed, Nov 28, 2012 at 2:53 PM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 11/28/2012 05:23 PM, heckj wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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 -<br>
<br>
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?<br>

</blockquote></div>
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:<br>
<br>
<br>
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.<br>
<br>
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.<br>

<br>
So swift would have to be modified to know about trusts.<br>
<br>
so the APIs would be something like<br>
<br>
POST v3/trusts  (create a new one)<br>
DELETE v3/trusts/<id>  (create a new one)<br>
POST v3/tokens (get a token for a trust)<br>
<br>
But I'll write it up in more detail.<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-joe<br>
<br>
On Nov 28, 2012, at 2:14 PM, heckj <<a href="mailto:heckj@mac.com" target="_blank">heckj@mac.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hey Adam -<br>
<br>
so what I'm missing on all of this is<br>
<br>
1) what's the API and how does a service and user interact with it?<br>
<br>
2) what's the gist of the code - have it in a github repo or something to see your initial implementation?<br>
<br>
Trust, delegation, impersonation - whatever - the need that you laid out in your blog post is great. Glance and Nova have the exact same needs<br>
(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)<br>
<br>
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.<br>

<br>
-joe<br>
<br>
On Nov 28, 2012, at 7:45 AM, Adam Young <<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have a very rudimentary Trust  (what I used to call Preauth <a href="https://blueprints.launchpad.net/keystone/+spec/trusts" target="_blank">https://blueprints.launchpad.<u></u>net/keystone/+spec/trusts</a>) implementation working with the SQL backend for Identity.<br>

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

<br>
I see three choices.<br>
<br>
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.<br>
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.<br>

3. Move it into its own backend.  This seems a little heavy weight.<br>
<br>
<br>
Thoughts?<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br>