<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/29/2012 09:59 AM, Dolph Mathews
wrote:<br>
</div>
<blockquote
cite="mid:CAC=h7gXWxkXEZUyiZYTvBqg9thueDhtQ-yvxYt323X-pP9xDVg@mail.gmail.com"
type="cite">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).</blockquote>
Hmmm, we could add that to the query interface. I want the trusts
to be immutable for audit purposes. If the end user changes the
defintion of the trust, to either add or remove a role, that should
be a new trust ID. We should always be able to go back and audit
what roles and endpoints were assigned to a trust when a given
action was taken. I was thinking that the user would register the
trust ID with with remote service when setting up the contract for
some future action. The only thing is if we want to be able to
designate different trusts for different actions by the same
trustee.<br>
<br>
<br>
<blockquote
cite="mid:CAC=h7gXWxkXEZUyiZYTvBqg9thueDhtQ-yvxYt323X-pP9xDVg@mail.gmail.com"
type="cite">
<div class="gmail_extra">
<br clear="all">
<div><br>
</div>
-Dolph<br>
<br>
<br>
<div class="gmail_quote">On Thu, Nov 29, 2012 at 8:49 AM, 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 06:21 PM, heckj wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
On Nov 28, 2012, at 2:53 PM, 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">
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>
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>
</blockquote>
swift or the auth_token middleware pieces?<br>
</blockquote>
<br>
</div>
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.
<div class="HOEnZb">
<div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
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>
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>
</div>
<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>