Open Stack

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 <bpavlovic at mirantis.com 
> <mailto: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.

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-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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-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/13f61b1f/attachment.html>