<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 16, 2015 at 1:21 PM, Samuel Merritt <span dir="ltr"><<a href="mailto:sam@swiftstack.com" target="_blank">sam@swiftstack.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2/14/15 9:49 PM, Adam Young wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On 02/13/2015 04:19 PM, Morgan Fainberg wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On February 13, 2015 at 11:51:10 AM, Lance Bragstad<br></span><div><div class="h5">
(<a href="mailto:lbragstad@gmail.com" target="_blank">lbragstad@gmail.com</a> <mailto:<a href="mailto:lbragstad@gmail.com" target="_blank">lbragstad@gmail.com</a>>) wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello all,<br>
<br>
<br>
I'm proposing the Authenticated Encryption (AE) Token specification<br>
[1] as an SPFE. AE tokens increases scalability of Keystone by<br>
removing token persistence. This provider has been discussed prior<br>
to, and at the Paris summit [2]. There is an implementation that is<br>
currently up for review [3], that was built off a POC. Based on the<br>
POC, there has been some performance analysis done with respect to<br>
the token formats available in Keystone (UUID, PKI, PKIZ, AE) [4].<br>
<br>
The Keystone team spent some time discussing limitations of the<br>
current POC implementation at the mid-cycle. One case that still<br>
needs to be addressed (and is currently being worked), is federated<br>
tokens. When requesting unscoped federated tokens, the token contains<br>
unbound groups which would need to be carried in the token. This case<br>
can be handled by AE tokens but it would be possible for an unscoped<br>
federated AE token to exceed an acceptable AE token length (i.e. <<br>
255 characters). Long story short, a federation migration could be<br>
used to ensure federated AE tokens never exceed a certain length.<br>
<br>
Feel free to leave your comments on the AE Token spec.<br>
<br>
Thanks!<br>
<br>
Lance<br>
<br>
[1] <a href="https://review.openstack.org/#/c/130050/" target="_blank">https://review.openstack.org/#<u></u>/c/130050/</a><br>
[2] <a href="https://etherpad.openstack.org/p/kilo-keystone-authorization" target="_blank">https://etherpad.openstack.<u></u>org/p/kilo-keystone-<u></u>authorization</a><br>
[3] <a href="https://review.openstack.org/#/c/145317/" target="_blank">https://review.openstack.org/#<u></u>/c/145317/</a><br>
[4] <a href="http://dolphm.com/benchmarking-openstack-keystone-token-formats/" target="_blank">http://dolphm.com/<u></u>benchmarking-openstack-<u></u>keystone-token-formats/</a><br>
______________________________<u></u>______________________________<u></u>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe:<br>
<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<u></u>openstack.org?subject:<u></u>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote>
<br>
<br>
I am for granting this exception as long as it’s clear that the<br>
following is clear/true:<br>
<br>
* All current use-cases for tokens (including federation) will be<br>
supported by the new token provider.<br>
<br>
* The federation tokens being possibly over 255 characters can be<br>
addressed in the future if they are not addressed here (a “federation<br>
migration” does not clearly state what is meant.<br>
<br>
</div></div></blockquote><div><div class="h5">
I think the length of the token is not a real issue.  We need to keep<br>
them within header lengths.  That is 8k.  Anything smaller than that<br>
will work.<br>
</div></div></blockquote>
<br>
I'd like to respectfully disagree here. Large tokens can dramatically increase the overhead for users of Swift with small objects since the token must be passed along with every request.<br>
<br>
For example, I have a small static web site: 68 files, mean file size 5508 bytes, median 636 bytes, total 374517 bytes. (It's an actual site; these are genuine data.)<br>
<br>
If I upload these things to Swift using a UUID token, then I incur maybe 400 bytes of overhead per file in the HTTP request, which is a 7.3% bloat. On the other hand, if the token + other headers is 8K, then I'm looking at 149% bloat, so I've more than doubled my transfer requirements just from tokens. :/<br>
<br>
I think that, for users of Swift and any other OpenStack data-plane APIs, token size is a definite concern. I am very much in favor of anything that shrinks token sizes while keeping the scalability benefits of PKI tokens.</blockquote><div><br></div><div>Ideally, what's the threshold you consider acceptable for token length from a non-persistent perspective? Does under 255 work or do you need something smaller? </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>______________________________<u></u>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<u></u>openstack.org?subject:<u></u>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>