On Mon, Feb 16, 2015 at 1:21 PM, Samuel Merritt <s...@swiftstack.com> wrote:
> On 2/14/15 9:49 PM, Adam Young wrote: > >> On 02/13/2015 04:19 PM, Morgan Fainberg wrote: >> >>> On February 13, 2015 at 11:51:10 AM, Lance Bragstad >>> (lbrags...@gmail.com <mailto:lbrags...@gmail.com>) wrote: >>> >>>> Hello all, >>>> >>>> >>>> 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]. >>>> >>>> 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. >>>> >>>> Feel free to leave your comments on the AE Token spec. >>>> >>>> Thanks! >>>> >>>> Lance >>>> >>>> [1] https://review.openstack.org/#/c/130050/ >>>> [2] https://etherpad.openstack.org/p/kilo-keystone-authorization >>>> [3] https://review.openstack.org/#/c/145317/ >>>> [4] http://dolphm.com/benchmarking-openstack-keystone-token-formats/ >>>> ____________________________________________________________ >>>> ______________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>> >>> >>> I am for granting this exception as long as it’s clear that the >>> following is clear/true: >>> >>> * All current use-cases for tokens (including federation) will be >>> supported by the new token provider. >>> >>> * 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. >>> >>> I think the length of the token is not a real issue. We need to keep >> them within header lengths. That is 8k. Anything smaller than that >> will work. >> > > 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. > > 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.) > > 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. :/ > > 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. 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? > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
