Open Stack

On Mon, Feb 16, 2015 at 1:21 PM, Samuel Merritt <sam at 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
>>> (lbragstad at gmail.com <mailto:lbragstad at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150216/d0b67624/attachment.html>