<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 11/28/2012 06:00 PM, Matt Joyce
wrote:<br>
</div>
<blockquote
cite="mid:CAGYSk8f3xLNfBoZbjsSEUfm_sa5xMHnNpJYdtQu1xbf=Oq06+w@mail.gmail.com"
type="cite">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>
</blockquote>
Yes.<br>
<br>
"read on keystone" might need to be slightly more defined, as it
needs to be something controlled by policy. So lets say a user has
the "read_keystone" role (we might want to make a handful of
implicit roles that every user has on all tenants...interesting
thought) tehn you would add that role to the trust:<br>
<br>
<br>
The create call would have a payload along these lines.<br>
{<br>
trustor: foo,<br>
trustee: cinder,<br>
tenant: bar,<br>
roles: [read_keystone],<br>
endpoints: [<a class="moz-txt-link-freetext" href="https://10.10.2.1/keystone/">https://10.10.2.1/keystone/</a>]<br>
}<br>
<br>
And you hould be able to see how that would map to the tokens.<br>
<br>
<br>
<br>
<blockquote
cite="mid:CAGYSk8f3xLNfBoZbjsSEUfm_sa5xMHnNpJYdtQu1xbf=Oq06+w@mail.gmail.com"
type="cite"><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
moz-do-not-send="true" 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
moz-do-not-send="true" 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
moz-do-not-send="true"
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 moz-do-not-send="true"
href="https://blueprints.launchpad.net/keystone/+spec/trusts"
target="_blank">https://blueprints.launchpad.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>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>