Open Stack

+1 from me.

On 13.02.2015 22:19, 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 am also ok with the AE token work being re-ordered ahead of the 
> provider cleanup to ensure it lands. Fixing the AE Token provider 
> along with PKI and UUID providers should be minimal extra work in the 
> cleanup.
>
> This addresses a very, very big issue within Keystone as scaling 
> scaling up happens. There has been demand for solving token 
> persistence for ~3 cycles. The POC code makes this exception possible 
> to land within Kilo, whereas without the POC this would almost 
> assuredly need to be held until the L-Cycle.
>
>
> TL;DR, I am for the exception if the AE Tokens support 100% of the 
> current use-cases of tokens (UUID or PKI) today.
>
>
> —Morgan
>
>
>
> __________________________________________________________________________
> 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/1f0361c4/attachment.html>