<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 21, 2014 at 11:32 AM, John Dickinson <span dir="ltr"><<a href="mailto:me@not.mn" target="_blank">me@not.mn</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Thanks Dolph and Lance for the info and links.<br>
<br>
<br>
What concerns me, in general, about the current length of keystone tokens is that they are unbounded. And the proposed solutions don't change that pattern.<br>
<br>
My understanding of why PKI tokens are used is so that the system doesn't have to call to Keystone to authorize the request. This reduces the load on Keystone, but it adds significant overhead for every API request.<br>


<br>
Keystone's first system was to use UUID bearer tokens. These are fixed length, small, cacheable, and require a call to Keystone once per cache period.<br>
<br>
Moving to PKI tokens, we now have multi-kB headers that significantly increase the size of each request. Swift deployers commonly have small objects on the order of <50kB, so adding another ~10kB to each request, just to save a once-a-day call to Keystone (ie uuid tokens) seems to be a really high price to pay for not much benefit.<br>


<br>
The other benefit to PKI tokens is that services can make calls to other systems on behalf of the user (eg nova can call cinder for the user). This is great, but it's not the only usage pattern in OpenStack projects, and therefore I don't like optimizing for it at the expense of other patterns.<br>


<br>
In addition to PKI tokens (ie signed+encoded service catalogs), I'd like to see Keystone support and remain committed to fixed-length bearer tokens or a signed-with-shared-secret auth mechanism (a la AWS).<br></blockquote>

<div><br></div><div>This is a fantastic argument in favor of UUID today. PKI will likely never be fixed-length, but hopefully we can continue making them smaller such that this argument might carry substantially less weight someday.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
--John<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
On May 21, 2014, at 9:09 AM, Dolph Mathews <<a href="mailto:dolph.mathews@gmail.com">dolph.mathews@gmail.com</a>> wrote:<br>
<br>
><br>
> On Wed, May 21, 2014 at 10:41 AM, John Dickinson <<a href="mailto:me@not.mn">me@not.mn</a>> wrote:<br>
> Can you explain how PKI info is compressible? I thought it was encrypted, which should mean you can't compress it right?<br>
><br>
> They're not encrypted - just signed and then base64 encoded. The JSON (and especially service catalog) is compressible prior to encoding.<br>
><br>
><br>
><br>
> --John<br>
><br>
><br>
><br>
><br>
><br>
> On May 21, 2014, at 8:32 AM, Morgan Fainberg <<a href="mailto:morgan.fainberg@gmail.com">morgan.fainberg@gmail.com</a>> wrote:<br>
><br>
> > The keystone team is also looking at ways to reduce the data contained in the token. Coupled with the compression, this should get the tokens back down to a reasonable size.<br>
> ><br>
> > Cheers,<br>
> > Morgan<br>
> ><br>
> > Sent via mobile<br>
> ><br>
> > On Wednesday, May 21, 2014, Adam Young <<a href="mailto:ayoung@redhat.com">ayoung@redhat.com</a>> wrote:<br>
> > On 05/21/2014 11:09 AM, Chuck Thier wrote:<br>
> >> There is a review for swift [1] that is requesting to set the max header size to 16k to be able to support v3 keystone tokens.  That might be fine if you measure you request rate in requests per minute, but this is continuing to add significant overhead to swift.  Even if you *only* have 10,000 requests/sec to your swift cluster, an 8k token is adding almost 80MB/sec of bandwidth.  This will seem to be equally bad (if not worse) for services like marconi.<br>


> >><br>
> >> When PKI tokens were first introduced, we raised concerns about the unbounded size of of the token in the header, and were told that uuid style tokens would still be usable, but all I heard at the summit, was to not use them and PKI was the future of all things.<br>


> >><br>
> >> At what point do we re-evaluate the decision to go with pki tokens, and that they may not be the best idea for apis like swift and marconi?<br>
> ><br>
> > Keystone tokens were slightly shrunk at the end of the last release cycle by removing unnecessary data from each endpoint entry.<br>
> ><br>
> > Compressed PKI tokens are enroute and will be much smaller.<br>
> ><br>
> >><br>
> >> Thanks,<br>
> >><br>
> >> --<br>
> >> Chuck<br>
> >><br>
> >> [1] <a href="https://review.openstack.org/#/c/93356/" target="_blank">https://review.openstack.org/#/c/93356/</a><br>
> >><br>
> >><br>
> >> _______________________________________________<br>
> >> OpenStack-dev mailing list<br>
> >><br>
> >> <a href="mailto:OpenStack-dev@lists.openstack.org">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><br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">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><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">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><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">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><br>
<br>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">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><br>
<br></blockquote></div><br></div></div>