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


Morgan Fainberg <> wrote on 02/13/2015 04:19:15 

> From: Morgan Fainberg <>
> To: Lance Bragstad <>, "OpenStack Development 
> Mailing List (not for usage questions)" 
> 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 (
> ) 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]
> [2]
> [3]
> [4]

> OpenStack Development Mailing List (not for usage questions) 
> Unsubscribe: 
> 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 
> 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 Development Mailing List (not for usage questions)

Reply via email to