<div dir="ltr"><div class="gmail_extra">Big +1 from me if we can land something solid.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Fri, Feb 13, 2015 at 3:12 PM, Yee, Guang <span dir="ltr"><<a href="mailto:guang.yee@hp.com" target="_blank">guang.yee@hp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">++<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">As for the unbound groups concern, our initial internal Federation POCs worked well with a single group so far. The proposed hierarchical role groups, or perhaps
even supporting nested user groups down the road should offer us more flexibility in terms user and permission management. For example, having a single aggregated group to map to for the federated users.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Personally, I think the max 255 characters constraint is somewhat artificial, unless I am missing something here.</span></p></div></div></blockquote><div><br></div><div>It's a limitation made for social reasons: that's sort of the tipping point where tokens become unwieldy and require special treatment.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Guang<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> Brant Knudson [mailto:<a href="mailto:blk@acm.org" target="_blank">blk@acm.org</a>]
<br>
<b>Sent:</b> Friday, February 13, 2015 12:59 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption (AE) Tokens<u></u><u></u></span></p><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">We get a lot of complaints about problems caused by persistent tokens, so this would be great to see in K. Given the amount of work required to get it done, which includes taking care of some other issues, like
getting revocation events working and refactoring the token code (things which could have been progressing all along...), and considering how long it takes to get changes merged, it seems unlikely that this will make it, but I've been planning all along to
prioritize these reviews if that helps.<u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">- Brant<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Fri, Feb 13, 2015 at 1:47 PM, Lance Bragstad <<a href="mailto:lbragstad@gmail.com" target="_blank">lbragstad@gmail.com</a>> wrote:<u></u><u></u></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">Hello all, <u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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]. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Feel free to leave your comments on the AE Token spec. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks! <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Lance<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">[1] <a href="https://review.openstack.org/#/c/130050/" target="_blank">https://review.openstack.org/#/c/130050/</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">[2] <a href="https://etherpad.openstack.org/p/kilo-keystone-authorization" target="_blank">https://etherpad.openstack.org/p/kilo-keystone-authorization</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">[3] <a href="https://review.openstack.org/#/c/145317/" target="_blank">https://review.openstack.org/#/c/145317/</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">[4] <a href="http://dolphm.com/benchmarking-openstack-keystone-token-formats/" target="_blank">http://dolphm.com/benchmarking-openstack-keystone-token-formats/</a><u></u><u></u></p>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><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><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></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></div>