<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 12/01/2012 02:13 AM, Bhandaru,
Malini K wrote:<br>
</div>
<blockquote
cite="mid:EE6FFF4F6C34C84C8C98DD2414EEA47E2F041D8A@FMSMSX105.amr.corp.intel.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Has
anybody thought of extending this notion of trust to pass
access to objects in swift across tenants?<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Limited
read access say for a day/week etc, something that could be
revoked.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">This
could provide a mechanism in OpenStack to support access to
digital media .. pay per view style.</span></p>
</div>
</blockquote>
<br>
Yes, this is the kind of use case we want to support. I was not
originally going to put a time out in the trust, but it looks like
there is enough of demand for it that I will add it in.<br>
<br>
<blockquote
cite="mid:EE6FFF4F6C34C84C8C98DD2414EEA47E2F041D8A@FMSMSX105.amr.corp.intel.com"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Regards<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Malini<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
Dolph Mathews [<a class="moz-txt-link-freetext" href="mailto:dolph.mathews@gmail.com">mailto:dolph.mathews@gmail.com</a>]
<br>
<b>Sent:</b> Friday, November 30, 2012 9:12 AM<br>
<b>To:</b> OpenStack Development Mailing List<br>
<b>Subject:</b> Re: [openstack-dev] [Keystone] Trusts
(Preauth) and LDAP<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Fri, Nov 30, 2012 at 8:53 AM, Adam
Young <<a moz-do-not-send="true"
href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>>
wrote:<o:p></o:p></p>
<div>
<p class="MsoNormal">On 11/28/2012 11:05 AM, David
Chadwick wrote:<o:p></o:p></p>
</div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">Hi Adam<br>
<br>
I have seen your spec and commented on it. This is yet
another case of delegation is it not?<o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal">OK, we've had a long discussion on
this, and I think I can clarify.<br>
<br>
1. We've used "delegation" to mean many things. I was
using it to mean delegation from one Keystone server to
another, in a(n) hierarchy. Maybe I am showing the effects
of my time in the Army, but to me delegation is something
that goes down from superiod to subordinate.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Federation?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><br>
2. There are two related Legal terms I considered:
Proxy and Trusts. I ruled out the term "Proxy" due to
its compete overuse.<br>
<br>
3. Regardless of whether we call it delegation or
trust, we are discussing the same thing.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The concept is "delegating
authorization to trusted entities," no? Modeling it in
the API as a "trust" between "users" sounds fine to me.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">From David Chadwich"<br>
<br>
"Keystone is the Delegation Service that handles all the
delegations for users. It is trusted to ensure that<br>
<br>
i) a delegator cannot delegate an attribute he has not
already been assigned<br>
ii) a delegator cannot delegate once the delegation
depth has been consumed<br>
iv) a delegator cannot delegate outside the validity
period of his own delegation.<br>
<br>
In other words, a delegator can only delegate less than
(or equal to) what he already has, and not more than it.
"<br>
<br>
I think that is a great prelude to the design
discussion.<br>
<br>
Right now, a user delegates in a short term fashion
using tokens. Once a token has been granted to a user,
he hands that off to another (service) user in order to
prove his identity and authorization to perform some set
of actions. In addition, since tokens are not scoped to
a specific endpoint, they are currently passed on from
one endpoint to another. This is not a secure approach.
If any endpoint along the way is compromised, all the
tokens in that endpoint are usable against any other
service that accepts tokens.<br>
<br>
So we limit the scope of tokens to only that single
endpoint, and we remove the attack. As a result, we
also remove the ability of the remote service user to
request additional operations from additional remote
services on behalf of the original user. This is a
problem that the trusts are designed to serve.<br>
<br>
A trust is a promise to allow delegation at some point
in the future. The actual delegation is performed in
the token. The trust is used to get the token.<br>
<br>
Now, as far as implementation goes, I would like to
propose two phases.<br>
<br>
1. Trusts get implemented today "hard wired" with the
attributes that are currently exposed in a token:
(trustor) user, tenant, roles, endpoints.<br>
2. Tokens that get generated from the trusts will look
just like normal tokens. They will have an additional
field "trustee". This will allow the current consumers
of tokens to continue to use a trust token just like
they do now.<br>
<br>
Phase 2.<br>
1. Modify the token architecture to allow arbitrary
sets of attributes.<br>
2. Modify the trust architecture to specify arbitrary
sets of attributes to be used in a token.<br>
<br>
<br>
<br>
Regarding my original question, I am going to move the
trust driver into the token back end. It has become
apparent that this is where it belongs, as it has the
exact same dependencies and usage patterns as the
tokens, and it is the Keystone "application specific"
data.<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
<br>
<br>
<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal"><br>
regards<br>
<br>
David<br>
<br>
On 28/11/2012 15:45, Adam Young wrote:<o:p></o:p></p>
<p class="MsoNormal">I have a very rudimentary Trust
(what I used to call Preauth<br>
<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<br>
working with the SQL backend for Identity.<br>
<br>
With LDAP, I am not sure where I would store the
trust information. The<br>
data for the trust itself is simply the uuid
user_ids for the trustor<br>
and trustee and tenant Id. There is also a table
for the roles, and a<br>
second table for the endpoints associated with the
trust.While we could<br>
shoehorn this into the user object, I am not sure
that there is an<br>
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<br>
of keeping the user-ids as foreign keys. It has the
drawback of forcing<br>
an LDAP backend solution.<br>
2. Move the Trusts into the Token backend. This
will get avoid the<br>
issue of LDAP support. It does mean that tokens,
which is a schema that<br>
is high volume, read intensive, and populated by
short lifespan<br>
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><o:p></o:p></p>
<p class="MsoNormal"><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><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</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>