<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 25, 2014 at 3:21 PM, Ved Lad <span dir="ltr"><<a href="mailto:vedlad@gmail.com" target="_blank">vedlad@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">The Openstack installation (Havana) at our company has a large number of service endpoints in the catalog. As a consequence, when using PKI tokens, my HTTP request header gets too big to handle for services like neutron. Im evaluating different options for reducing the size of the catalog in the PKI token. Some that I have found are:</span><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">1. Using the per tenant endpoint filtering extension: This could break if the per tenant endpoint list gets too big</div></div></blockquote><div><br></div><div>In Juno, there's a revision to this which makes the management easier:</div><div><br></div><div>  <a href="https://blueprints.launchpad.net/keystone/+spec/multi-attribute-endpoint-grouping">https://blueprints.launchpad.net/keystone/+spec/multi-attribute-endpoint-grouping</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">2. Using PKIZ Tokens(In Juno): Were using Havana, so I cant use this feature, but it still doesnt look scalable</div></div></blockquote><div><br></div><div>You're correct, it's a step in the right direction that we should have taken in the first place, but it's still going to run into the same problem with (even larger) large catalogs.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">3. Using the ?nocatalog option. This is the best option for scalability but isnt the catalog a required component for authorization?</div></div></blockquote><div><br></div><div>The catalog (historically) does not convey any sort of authorization information, but does provide some means of obscurity. There's been an ongoing effort to make keystonemiddleware aware of the endpoint it's protecting, and thus the catalog becomes pertinent authZ data in that scenario. The bottom line is that the ?nocatalog auth flow is not a completely viable code path yet.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">Are there any other solutions that i am unaware of, that scale with number of endpoints?</div></div></blockquote><div><br></div><div>Use UUID tokens, which Keystone defaults to in Juno for some of the same pain points that you're experiencing. UUID provides the same level of security as PKI, with different scaling characteristics.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">Thanks,</div><div style="font-family:arial,sans-serif;font-size:13px">Ved</div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</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>