<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<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]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<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.<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 [mailto:dolph.mathews@gmail.com]
<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 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 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 href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a 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 href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a 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>
</body>
</html>