Open Stack

On 02/16/2015 02:21 PM, Samuel Merritt 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.

Actually, the only tokens that are going to be non-fixed size will be 
the ones for Federation, since they need groups.  They won't be within 
the 255 byte boundary, but they will be small.




>
> __________________________________________________________________________ 
>
> 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