<div dir="ltr"><div>++ 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><br></div><div>-Lin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 13, 2015 at 7:21 PM, Steve Martinelli <span dir="ltr"><<a href="mailto:stevemar@ca.ibm.com" target="_blank">stevemar@ca.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><tt><font>It would be great to see this land in Kilo, I'll definitely
be willing to review the code.</font></tt>
<br>
<br><tt><font>Steve</font></tt>
<br>
<br><tt><font>Morgan Fainberg <<a href="mailto:morgan.fainberg@gmail.com" target="_blank">morgan.fainberg@gmail.com</a>>
wrote on 02/13/2015 04:19:15 PM:<br>
<br>
> From: Morgan Fainberg <<a href="mailto:morgan.fainberg@gmail.com" target="_blank">morgan.fainberg@gmail.com</a>></font></tt>
<br><tt><font>> To: Lance Bragstad <<a href="mailto:lbragstad@gmail.com" target="_blank">lbragstad@gmail.com</a>>,
"OpenStack Development <br>
> Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>></font></tt>
<br><tt><font>> Date: 02/13/2015 04:24 PM</font></tt>
<br><span class=""><tt><font>> Subject: Re: [openstack-dev] [keystone] SPFE:
Authenticated <br>
> Encryption (AE) Tokens</font></tt>
<br></span><tt><font>> <br><div><div class="h5">
> On February 13, 2015 at 11:51:10 AM, Lance Bragstad (<a href="mailto:lbragstad@gmail.com" target="_blank">lbragstad@gmail.com</a><br>
> ) wrote:</div></div></font></tt>
<br><div class="HOEnZb"><div class="h5"><tt><font>> Hello all, </font></tt>
<br><tt><font>> <br>
> I'm proposing the Authenticated Encryption (AE) Token specification
<br>
> [1] as an SPFE. AE tokens increases scalability of Keystone by <br>
> removing token persistence. This provider has been discussed prior
<br>
> to, and at the Paris summit [2]. There is an implementation that is
<br>
> currently up for review [3], that was built off a POC. Based on the
<br>
> POC, there has been some performance analysis done with respect to
<br>
> the token formats available in Keystone (UUID, PKI, PKIZ, AE) [4].
</font></tt>
<br><tt><font>> <br>
> The Keystone team spent some time discussing limitations of the <br>
> current POC implementation at the mid-cycle. One case that still <br>
> needs to be addressed (and is currently being worked), is federated
<br>
> tokens. When requesting unscoped federated tokens, the token <br>
> contains unbound groups which would need to be carried in the token.<br>
> This case can be handled by AE tokens but it would be possible for
<br>
> an unscoped federated AE token to exceed an acceptable AE token <br>
> length (i.e. < 255 characters). Long story short, a federation
<br>
> migration could be used to ensure federated AE tokens never exceed
a<br>
> certain length. </font></tt>
<br><tt><font>> <br>
> Feel free to leave your comments on the AE Token spec. </font></tt>
<br><tt><font>> <br>
> Thanks! </font></tt>
<br><tt><font>> <br>
> Lance</font></tt>
<br><tt><font>> <br>
> [1] </font></tt><a href="https://review.openstack.org/#/c/130050/" target="_blank"><tt><font>https://review.openstack.org/#/c/130050/</font></tt></a>
<br><tt><font>> [2] </font></tt><a href="https://etherpad.openstack.org/p/kilo-keystone-authorization" target="_blank"><tt><font>https://etherpad.openstack.org/p/kilo-keystone-authorization</font></tt></a>
<br><tt><font>> [3] </font></tt><a href="https://review.openstack.org/#/c/145317/" target="_blank"><tt><font>https://review.openstack.org/#/c/145317/</font></tt></a>
<br><tt><font>> [4] </font></tt><a href="http://dolphm.com/benchmarking-openstack-keystone-token-formats/" target="_blank"><tt><font>http://dolphm.com/benchmarking-openstack-keystone-token-formats/</font></tt></a>
<br><tt><font>> __________________________________________________________________________
<br>
> OpenStack Development Mailing List (not for usage questions) <br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><font>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font>
</font></tt>
<br><tt><font>> <br>
> I am for granting this exception as long as it’s clear that the <br>
> following is clear/true:</font></tt>
<br><tt><font>> * All current use-cases for tokens (including
federation) will be <br>
> supported by the new token provider.</font></tt>
<br><tt><font>> * The federation tokens being possibly over 255
characters can be <br>
> addressed in the future if they are not addressed here (a <br>
> “federation migration” does not clearly state what is meant.</font></tt>
<br><tt><font>> I am also ok with the AE token work being re-ordered
ahead of the <br>
> provider cleanup to ensure it lands. Fixing the AE Token provider
<br>
> along with PKI and UUID providers should be minimal extra work in
the cleanup.</font></tt>
<br><tt><font>> This addresses a very, very big issue within
Keystone as scaling <br>
> scaling up happens. There has been demand for solving token <br>
> persistence for ~3 cycles. The POC code makes this exception <br>
> possible to land within Kilo, whereas without the POC this would <br>
> almost assuredly need to be held until the L-Cycle.</font></tt>
<br><tt><font>> <br>
> TL;DR, I am for the exception if the AE Tokens support 100% of the
<br>
> current use-cases of tokens (UUID or PKI) today.</font></tt>
<br><tt><font>> <br>
> —Morgan<br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><font>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font><br>
</font></tt></div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>