Open Stack

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 <bpavlovic at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160406/87f94f44/attachment.html>