<div dir="ltr">For some historical perspective, that's basically how v2 was designed. The "public" service (port 5000) did nothing but the auth flow. The "admin" service (port 35357) was identity management.<div><br></div><div>Unfortunately, there are (perhaps uncommon) authentication flows where, for example, you need to 1) authenticate for an unscoped token, 2) retrieve a list of tenants where you have some authorization, 3) re-authenticate for a scoped token. There was a lot of end-user confusion over what port was used for what operations (Q: "Why is my curl request returning 404? I'm doing what the docs say to do!" A: "You're calling the wrong port."). More and more calls straddled the line between the two APIs, blurring their distinction.<div><br></div><div>The approach we took in v3 was to consolidate the APIs into a single, functional superset, and use RBAC to distinguish between use cases in a more flexible manner.</div></div><div><br></div><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 6, 2016 at 2:26 PM, Boris Pavlovic <span dir="ltr"><<a href="mailto:bpavlovic@mirantis.com" target="_blank">bpavlovic@mirantis.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"><div>Hi stackers, </div><div><br></div><div>I would like to suggest very simple idea of splitting out of Keystone authentication</div><div>part in the separated project. </div><div><br></div><div>Such change has 2 positive outcomes: </div><div>1) It will be quite simple to create scalable service with high performance for authentication based on very mature projects like: Kerberos[1] and OpenLDAP[2].</div></div></blockquote><div><br></div><div>You can basically do this today if you just focus on implementing drivers for the few bits of keystone you need, and disable the rest.</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><br></div><div>2) This will reduce scope of Keystone, which means 2 things</div><div>2.1) Smaller code base that has less issues and is simpler for testing</div><div>2.2) Keystone team would be able to concentrate more on fixing perf/scalability issues of authorization, which is crucial at the moment for large clouds.</div></div></blockquote><div><br></div><div>(2.2) is particularly untrue, because this will cause at least 2 releases worth of refactoring work for everyone, and another 6 releases justifying to deployers why their newfound headaches are worthwhile. Perhaps after burning those ~4 years of productivity, we'd be able to get back to "fixing perf/scalability issues of authorization."</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><br></div><div>Thoughts?  </div><div><br></div><div>[1] <a href="http://web.mit.edu/kerberos/" target="_blank">http://web.mit.edu/kerberos/</a></div><div>[2] <a href="http://ldapcon.org/2011/downloads/hummel-slides.pdf" target="_blank">http://ldapcon.org/2011/downloads/hummel-slides.pdf</a></div><div><br></div><div>Best regards,</div><div>Boris Pavlovic </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" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>