Open Stack

It would be great to see this land in Kilo, I'll definitely be willing to 
review the code.

Steve

Morgan Fainberg <morgan.fainberg at gmail.com> wrote on 02/13/2015 04:19:15 
PM:

> From: Morgan Fainberg <morgan.fainberg at gmail.com>
> To: Lance Bragstad <lbragstad at gmail.com>, "OpenStack Development 
> Mailing List (not for usage questions)" 
<openstack-dev at lists.openstack.org>
> Date: 02/13/2015 04:24 PM
> Subject: Re: [openstack-dev] [keystone] SPFE: Authenticated 
> Encryption (AE) Tokens
> 
> On February 13, 2015 at 11:51:10 AM, Lance Bragstad (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/20150213/90668468/attachment.html>