<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=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@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;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 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";
color:black;}
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;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
tt
{mso-style-priority:99;
font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
color:black;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";
color:black;}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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 bgcolor="white" 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">Hi Adam,<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">Will the proposed v3-auth api format change ( or include some additional meta data ) to support trust? If so what is the additional meta data that is required
to get the token defined by trust?<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" style="text-indent:.5in"><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">User B, sends a request for a token defined by this trust.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">
</span><span style="font-size:10.0pt;font-family:Wingdings">à</span><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"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"> Adam Young [mailto:ayoung@redhat.com]
<br>
<b>Sent:</b> Wednesday, February 20, 2013 7:01 AM<br>
<b>To:</b> openstack-dev@lists.openstack.org<br>
<b>Subject:</b> Re: [openstack-dev] [Keystone] Proposed change to token re--issue<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 02/18/2013 01:56 PM, Ali, Haneef wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hi Adam,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Do you have request/response for the following steps based on V3 token structure?</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> <!--</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">2. User B, sends a request for a token defined by this trust. User B authenticates with his own credential (token or username&password of user B).
</span><br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif""> 3. Based on the defined trust user B is granted a token authorizing him to have role X. User B is listed as a "trustee" in the generated token (T). </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">
</span><span style="font-size:11.0pt;font-family:Wingdings;color:#1F497D">à</span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal">the V3-auth API implementation is still under review. Take a look at:<br>
<br>
<a href="https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md">https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md</a><br>
<br>
For the docs.<br>
<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Also, what is the token expiry time? I believe it is lesser of default token expiry time and trust duration.</span><o:p></o:p></p>
<p class="MsoNormal">Correct.<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Haneef</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"> Adam Young [<a href="mailto:ayoung@redhat.com">mailto:ayoung@redhat.com</a>]
<br>
<b>Sent:</b> Monday, February 18, 2013 6:06 AM<br>
<b>To:</b> Alexandra Shulman-Peleg<br>
<b>Cc:</b> <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
<b>Subject:</b> Re: [openstack-dev] [Keystone] Proposed change to token re--issue</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<p class="MsoNormal">On 02/18/2013 08:29 AM, Alexandra Shulman-Peleg wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">Hi Adam,
</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif"">I would like to verify my understanding of trusts and their token renewal. Please read the flow below and comment whether we can achieve this. I know that there are still some missing parts at
the Swift side, but I would like to clarify the trusts flow before addressing them.
</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif"">Thank you very much,</span>
<br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif"">Alex. </span> <br>
<br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif"">Motivation: </span>
<br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif"">User A wants to grant user B an access to container (C). User A is the owner of C.
</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif"">Delegation flow: </span>
<br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif"">1. By using the API of trusts, user A (having roles X and Y) registers a "trust" to user B, granting him role X sufficient to access container C.
</span><br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif"">2. User B, sends a request for a token defined by this trust. User B authenticates with his own credential (token or username&password of user B).
</span><br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif"">3. Based on the defined trust user B is granted a token authorizing him to have role X. User B is listed as a "trustee" in the generated token (T).
</span><br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif"">4. User B presents the token T to Swift and gains access to container C.
</span><br>
<span style="font-size:10.0pt;font-family:"Arial","sans-serif"">5. When the token is expired, user B can renew it by repeating the steps 2-3 above.
</span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><br>
Yes. That is exactly how it is supposed to work.<br>
<br>
<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal"><br>
<br>
<br>
<span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F">From: </span><span style="font-size:7.5pt;font-family:"Arial","sans-serif"">Adam Young
<a href="mailto:ayoung@redhat.com"><ayoung@redhat.com></a></span> <br>
<span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F">To: </span><span style="font-size:7.5pt;font-family:"Arial","sans-serif"">OpenStack Development Mailing List
<a href="mailto:openstack-dev@lists.openstack.org"><openstack-dev@lists.openstack.org></a>,
</span><br>
<span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F">Date: </span><span style="font-size:7.5pt;font-family:"Arial","sans-serif"">13/02/2013 04:34 PM</span>
<br>
<span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:#5F5F5F">Subject: </span><span style="font-size:7.5pt;font-family:"Arial","sans-serif"">[openstack-dev] [Keystone] Proposed change to token re--issue</span>
<o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="100%" noshade="" style="color:#A0A0A0" align="center">
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
<br>
<tt><span style="font-size:10.0pt">Right now, Keystone will allow you to get a token based on a previous
</span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>token. It does not matter if the original token is for a different </tt><br>
<tt>scope, more restricted, than the second token.</tt><br>
<br>
<br>
<tt>While writing the trusts implementation, I realize that carrying this </tt><br>
<tt>rule forward would open up a security hole. A user with a token based </tt><br>
<tt>on a trust would be able to get a new token for any of the privileges of </tt>
<br>
<tt>the trustor. The whole point of trusts was to scale down the scope of </tt><br>
<tt>access from a token, not to increase it.</tt><br>
<br>
<tt>I would like to propose the following rule. It will have to apply to </tt><br>
<tt>both the V2 and V3 versions of the APIs.</tt><br>
<br>
<tt>Only an unscoped token can be used to retrieve another token.</tt><br>
<br>
<br>
<tt>In order to get an unscoped token, you have to pass in userid and </tt><br>
<tt>password, or one of the REMOTE_USER mechanisms.</tt><br>
<tt>It is technically OK to use an unscoped token to get another token, so </tt><br>
<tt>long as the time out is honored, but I am not sure if that provides any </tt>
<br>
<tt>real benefit.</tt><br>
<br>
<tt>I could make a one-off exception for trust tokens. However, if we don't </tt>
<br>
<tt>address this issue now, I suspect it will come back to haunt us later.</tt><br>
<br>
<tt>Here is a longer rationalization.</tt><br>
<br>
<tt>Tokens are a symetric shared secret. If you have the token, you have </tt><br>
<tt>the permissions of the user. Thus, a token should not be spread </tt><br>
<tt>around. Ideally, tokens should contain just the minimal amount of </tt><br>
<tt>permissions to accomplish the task at hand. THat way, if they get </tt><br>
<tt>intercepted, they can only be used to do minimal amounts of damage. If </tt>
<br>
<tt>a user has access to multiple projects (tenants), the token shoud not </tt><br>
<tt>provide access to the tenants other than the one for which it is </tt><br>
<tt>allocated. Right now, due to token reissue, a token for Project A can </tt>
<br>
<tt>be used to get a token for Project B.</tt><br>
<br>
<tt>In the future, we are talking about scoping tokens to domains, </tt><br>
<tt>endpoints, and other containers. Lets choose now to limit the amount of </tt>
<br>
<tt>exposure on a single token.</tt><br>
<br>
<tt>_______________________________________________</tt><br>
<tt>OpenStack-dev mailing list</tt><br>
<tt><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a></tt><br>
</span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><span style="font-size:10.0pt">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></tt></a><span style="font-size:10.0pt;font-family:"Courier New""><br>
<br>
<br>
</span><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><br>
<br>
<br>
<o:p></o:p></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>OpenStack-dev mailing list<o:p></o:p></pre>
<pre><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><o:p></o:p></pre>
<pre><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></pre>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>