On 04/06/2016 04:56 PM, Dolph Mathews wrote:
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
<mailto: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.
We should deprecate the userid/password in the token Body and use the
BasicAuth mechanism in its place. Then Password could be a Federated
call like anything else. We could do that logic in Middleware instead
of an apache module.
A comparble middleware/apache module could also be used in other
services, allowing the identity inside of Keystone to be used with
remote services.
Ideally, we would get out of the business of distributing tokens
altogether, and use the standar Mechanism for authentication that the
web has when talking to the services directly. Keystone then reduces to
a service catalog look up for end users.
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://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
__________________________________________________________________________
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
