To Clarify, I meant I support this exception if the new provider supports all 
of our current use-cases. I was not stating this exception was approved without 
time for feedback from the community.

-- 
Morgan Fainberg

On February 13, 2015 at 1:19:17 PM, Morgan Fainberg (morgan.fainb...@gmail.com) 
wrote:

On February 13, 2015 at 11:51:10 AM, Lance Bragstad (lbrags...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to