<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 02/18/2013 01:56 PM, Ali, Haneef
      wrote:<br>
    </div>
    <blockquote
cite="mid:D1EC508A39233D48A3F3FA9188A4BBF8371D3C20@G9W0725.americas.hpqcorp.net"
      type="cite">
      <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;}
/* 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;}
tt
        {mso-style-priority:99;
        font-family:"Courier New";}
span.EmailStyle18
        {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]-->
      <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">Do
            you have request/response for the following steps based on
            V3 token structure?<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="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><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"> 
          </span><span
            style="font-size:11.0pt;font-family:Wingdings;color:#1F497D">à</span></p>
      </div>
    </blockquote>
    the V3-auth API implementation is still under review.  Take a look
    at:<br>
    <br>
<a class="moz-txt-link-freetext" 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>
    <blockquote
cite="mid:D1EC508A39233D48A3F3FA9188A4BBF8371D3C20@G9W0725.americas.hpqcorp.net"
      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">Also,
            what is the token expiry time?  I believe it is lesser of
            default token expiry time and trust duration.</span></p>
      </div>
    </blockquote>
    Correct.<br>
    <blockquote
cite="mid:D1EC508A39233D48A3F3FA9188A4BBF8371D3C20@G9W0725.americas.hpqcorp.net"
      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">Thanks<o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Haneef<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 [<a class="moz-txt-link-freetext" 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 class="moz-txt-link-abbreviated" 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<o:p></o:p></span></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>
          <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 moz-do-not-send="true" 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 moz-do-not-send="true"
              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" style="text-align:center" align="center">
          <hr style="color:#A0A0A0" align="center" noshade="noshade"
            size="2" width="100%">
        </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 moz-do-not-send="true"
                href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a></tt><br>
          </span><a moz-do-not-send="true"
            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>
          </span><o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
      </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>