Open Stack

So I’m Ok with an exception for this, but still have reservations of the this AE technique (at least the one that is currently proposed). I assume this will be marked as experimental - since we have not formally agreed that this is a standard we want to lock into core?

Henry
> On 14 Feb 2015, at 05:09, Lin Hua Cheng <os.lcheng at gmail.com> wrote:
> 
> ++ One of the feature that I am looking forward to see in Kilo, this feature will solve one of the pain points from operators in maintaining the token db backend.
> 
> -Lin
> 
> On Fri, Feb 13, 2015 at 7:21 PM, Steve Martinelli <stevemar at ca.ibm.com <mailto:stevemar at ca.ibm.com>> wrote:
> 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 <mailto:morgan.fainberg at gmail.com>> wrote on 02/13/2015 04:19:15 PM:
> 
> > From: Morgan Fainberg <morgan.fainberg at gmail.com <mailto:morgan.fainberg at gmail.com>> 
> > To: Lance Bragstad <lbragstad at gmail.com <mailto:lbragstad at gmail.com>>, "OpenStack Development 
> > Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org <mailto: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 <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/ <https://review.openstack.org/#/c/130050/> 
> > [2] https://etherpad.openstack.org/p/kilo-keystone-authorization <https://etherpad.openstack.org/p/kilo-keystone-authorization> 
> > [3] https://review.openstack.org/#/c/145317/ <https://review.openstack.org/#/c/145317/> 
> > [4] http://dolphm.com/benchmarking-openstack-keystone-token-formats/ <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://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe> 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <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://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> 
> __________________________________________________________________________
> 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/20150214/c13b9680/attachment.html>