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.
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. 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. On Wed, Apr 6, 2016 at 2:26 PM, Boris Pavlovic <bpavlo...@mirantis.com> wrote: > Hi stackers, > > I would like to suggest very simple idea of splitting out of Keystone > authentication > part in the separated project. > > Such change has 2 positive outcomes: > 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]. > 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. > > 2) This will reduce scope of Keystone, which means 2 things > 2.1) Smaller code base that has less issues and is simpler for testing > 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. > (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." > > Thoughts? > > [1] http://web.mit.edu/kerberos/ > [2] http://ldapcon.org/2011/downloads/hummel-slides.pdf > > Best regards, > Boris Pavlovic > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev