<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">To Clarify, I meant I support this exception if the new provider supports all of our current use-cases. I was not stating this exception was approved without time for feedback from the community.</div> <br> <div id="bloop_sign_1423870633697700096" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Morgan Fainberg<br></div></div> <br><p style="color:#000;">On February 13, 2015 at 1:19:17 PM, Morgan Fainberg (<a href="mailto:morgan.fainberg@gmail.com">morgan.fainberg@gmail.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div></div><div>
<title></title>
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">
On February 13, 2015 at 11:51:10 AM, Lance Bragstad (<a href="mailto:lbragstad@gmail.com">lbragstad@gmail.com</a>) wrote:</div>
<div>
<blockquote type="cite" class="clean_bq" style="color: rgb(0, 0, 0); font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
<div>
<div>
<div dir="ltr"><span>Hello all, </span>
<div><span><br></span></div>
<div><span><br></span></div>
<div><span>I'm proposing the Authenticated Encryption (AE) Token
specification [1] as an SPFE. AE tokens increases scalability of
Keystone by removing token persistence. This provider has been
discussed prior to, and at the Paris summit [2]. There is an
implementation that is currently up for review [3], that was built
off a POC. Based on the POC, there has been some performance
analysis done with respect to the token formats available in
Keystone (UUID, PKI, PKIZ, AE) [4]. </span></div>
<div><span><br></span></div>
<div><span>The Keystone team spent some time discussing limitations
of the current POC implementation at the mid-cycle. One case that
still needs to be addressed (and is currently being worked), is
federated tokens. When requesting unscoped federated tokens, the
token contains unbound groups which would need to be carried in the
token. This case can be handled by AE tokens but it would be
possible for an unscoped federated AE token to exceed an acceptable
AE token length (i.e. < 255 characters). Long story short, a
federation migration could be used to ensure federated AE tokens
never exceed a certain length. </span></div>
<div><span><br></span></div>
<div><span>Feel free to leave your comments on the AE Token
spec. </span></div>
<div><span><br></span></div>
<div><span>Thanks! </span></div>
<div><span><br></span></div>
<div><span>Lance</span></div>
<div><span><br></span></div>
<div><span>[1] <a href="https://review.openstack.org/#/c/130050/">https://review.openstack.org/#/c/130050/</a></span></div>
<div><span>[2] <a href="https://etherpad.openstack.org/p/kilo-keystone-authorization">https://etherpad.openstack.org/p/kilo-keystone-authorization</a></span></div>
<div><span>[3] <a href="https://review.openstack.org/#/c/145317/">https://review.openstack.org/#/c/145317/</a></span></div>
<div><span>[4] <a href="http://dolphm.com/benchmarking-openstack-keystone-token-formats/">http://dolphm.com/benchmarking-openstack-keystone-token-formats/</a></span></div>
</div>
<span>__________________________________________________________________________<span class="Apple-converted-space"> </span><br>
OpenStack Development Mailing List (not for usage
questions)<span class="Apple-converted-space"> </span><br>
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<span class="Apple-converted-space"> </span><br>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<span class="Apple-converted-space"> </span></span></div>
</div>
</blockquote>
</div>
<p><br></p>
<p>I am for granting this exception as long as it’s clear that the
following is clear/true:</p>
<p>* All current use-cases for tokens (including federation) will
be supported by the new token provider.</p>
<p>* The federation tokens being possibly over 255 characters can
be addressed in the future if they are not addressed here (a
“federation migration” does not clearly state what is meant.</p>
<p>I am also ok with the AE token work being re-ordered ahead of
the provider cleanup to ensure it lands. Fixing the AE Token
provider along with PKI and UUID providers should be minimal extra
work in the cleanup.</p>
<p>This addresses a very, very big issue within Keystone as scaling
scaling up happens. There has been demand for solving token
persistence for ~3 cycles. The POC code makes this exception
possible to land within Kilo, whereas without the POC this would
almost assuredly need to be held until the L-Cycle.</p>
<p><br></p>
<p>TL;DR, I am for the exception if the AE Tokens support 100% of
the current use-cases of tokens (UUID or PKI) today.</p>
<p><br></p>
<p>—Morgan</p>
</div></div></span></blockquote></body></html>