++ 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 <steve...@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.fainb...@gmail.com> wrote on 02/13/2015 04:19:15 > PM: > > > From: Morgan Fainberg <morgan.fainb...@gmail.com> > > To: Lance Bragstad <lbrags...@gmail.com>, "OpenStack Development > > Mailing List (not for usage questions)" < > openstack-dev@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 (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 > > __________________________________________________________________________ > 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 > >
__________________________________________________________________________ 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
