
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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?<div class=""><br class=""></div><div class="">Henry<br class=""><div><blockquote type="cite" class=""><div class="">On 14 Feb 2015, at 05:09, Lin Hua Cheng <<a href="mailto:os.lcheng@gmail.com" class="">os.lcheng@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">++ 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.</div><div class=""><br class=""></div><div class="">-Lin</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Feb 13, 2015 at 7:21 PM, Steve Martinelli <span dir="ltr" class=""><<a href="mailto:stevemar@ca.ibm.com" target="_blank" class="">stevemar@ca.ibm.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><tt class="">It would be great to see this land in Kilo, I'll definitely

be willing to review the code.</tt>

<br class="">

<br class=""><tt class="">Steve</tt>

<br class="">

<br class=""><tt class="">Morgan Fainberg <<a href="mailto:morgan.fainberg@gmail.com" target="_blank" class="">morgan.fainberg@gmail.com</a>>

wrote on 02/13/2015 04:19:15 PM:<br class="">

<br class="">

> From: Morgan Fainberg <<a href="mailto:morgan.fainberg@gmail.com" target="_blank" class="">morgan.fainberg@gmail.com</a>></tt>

<br class=""><tt class="">> To: Lance Bragstad <<a href="mailto:lbragstad@gmail.com" target="_blank" class="">lbragstad@gmail.com</a>>,

"OpenStack Development <br class="">

> Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank" class="">openstack-dev@lists.openstack.org</a>></tt>

<br class=""><tt class="">> Date: 02/13/2015 04:24 PM</tt>

<br class=""><span class=""><tt class=""><font class="">> Subject: Re: [openstack-dev] [keystone] SPFE:

Authenticated <br class="">

> Encryption (AE) Tokens</font></tt>

<br class=""></span><tt class="">> <br class=""><div class=""><div class="h5">

> On February 13, 2015 at 11:51:10 AM, Lance Bragstad (<a href="mailto:lbragstad@gmail.com" target="_blank" class="">lbragstad@gmail.com</a><br class="">

> ) wrote:</div></div></tt>

<br class=""><div class="HOEnZb"><div class="h5"><tt class="">> Hello all, </tt>

<br class=""><tt class="">> <br class="">

> I'm proposing the Authenticated Encryption (AE) Token specification

<br class="">

> [1] as an SPFE. AE tokens increases scalability of Keystone by <br class="">

> removing token persistence. This provider has been discussed prior

<br class="">

> to, and at the Paris summit [2]. There is an implementation that is

<br class="">

> currently up for review [3], that was built off a POC. Based on the

<br class="">

> POC, there has been some performance analysis done with respect to

<br class="">

> the token formats available in Keystone (UUID, PKI, PKIZ, AE) [4].

</tt>

<br class=""><tt class="">> <br class="">

> The Keystone team spent some time discussing limitations of the <br class="">

> current POC implementation at the mid-cycle. One case that still <br class="">

> needs to be addressed (and is currently being worked), is federated

<br class="">

> tokens. When requesting unscoped federated tokens, the token <br class="">

> contains unbound groups which would need to be carried in the token.<br class="">

> This case can be handled by AE tokens but it would be possible for

<br class="">

> an unscoped federated AE token to exceed an acceptable AE token <br class="">

> length (i.e. < 255 characters). Long story short, a federation

<br class="">

> migration could be used to ensure federated AE tokens never exceed

a<br class="">

> certain length. </tt>

<br class=""><tt class="">> <br class="">

> Feel free to leave your comments on the AE Token spec. </tt>

<br class=""><tt class="">> <br class="">

> Thanks! </tt>

<br class=""><tt class="">> <br class="">

> Lance</tt>

<br class=""><tt class="">> <br class="">

> [1] </tt><a href="https://review.openstack.org/#/c/130050/" target="_blank" class=""><tt class="">https://review.openstack.org/#/c/130050/</tt></a>

<br class=""><tt class="">> [2] </tt><a href="https://etherpad.openstack.org/p/kilo-keystone-authorization" target="_blank" class=""><tt class="">https://etherpad.openstack.org/p/kilo-keystone-authorization</tt></a>

<br class=""><tt class="">> [3] </tt><a href="https://review.openstack.org/#/c/145317/" target="_blank" class=""><tt class="">https://review.openstack.org/#/c/145317/</tt></a>

<br class=""><tt class="">> [4] </tt><a href="http://dolphm.com/benchmarking-openstack-keystone-token-formats/" target="_blank" class=""><tt class="">http://dolphm.com/benchmarking-openstack-keystone-token-formats/</tt></a>

<br class=""><tt class="">> __________________________________________________________________________

<br class="">

> OpenStack Development Mailing List (not for usage questions) <br class="">

> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank" class="">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>

<br class="">

> </tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" class=""><tt class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</tt></a><tt class=""><font class="">

</font></tt>

<br class=""><tt class="">> <br class="">

> I am for granting this exception as long as it’s clear that the <br class="">

> following is clear/true:</tt>

<br class=""><tt class="">> * All current use-cases for tokens (including

federation) will be <br class="">

> supported by the new token provider.</tt>

<br class=""><tt class="">> * The federation tokens being possibly over 255

characters can be <br class="">

> addressed in the future if they are not addressed here (a <br class="">

> “federation migration” does not clearly state what is meant.</tt>

<br class=""><tt class="">> I am also ok with the AE token work being re-ordered

ahead of the <br class="">

> provider cleanup to ensure it lands. Fixing the AE Token provider

<br class="">

> along with PKI and UUID providers should be minimal extra work in

the cleanup.</tt>

<br class=""><tt class="">> This addresses a very, very big issue within

Keystone as scaling <br class="">

> scaling up happens. There has been demand for solving token <br class="">

> persistence for ~3 cycles. The POC code makes this exception <br class="">

> possible to land within Kilo, whereas without the POC this would <br class="">

> almost assuredly need to be held until the L-Cycle.</tt>

<br class=""><tt class="">> <br class="">

> TL;DR, I am for the exception if the AE Tokens support 100% of the

<br class="">

> current use-cases of tokens (UUID or PKI) today.</tt>

<br class=""><tt class="">> <br class="">

> —Morgan<br class="">

> __________________________________________________________________________<br class="">

> OpenStack Development Mailing List (not for usage questions)<br class="">

> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank" class="">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class="">

> </tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" class=""><tt class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</tt></a><tt class=""><br class="">

</tt></div></div><br class="">__________________________________________________________________________<br class="">

OpenStack Development Mailing List (not for usage questions)<br class="">

Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank" class="">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class="">

<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="">

<br class=""></blockquote></div><br class=""></div>

__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" class="">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class=""></div></blockquote></div><br class=""></div></body></html>