<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 04/06/2016 04:56 PM, Dolph Mathews
wrote:<br>
</div>
<blockquote
cite="mid:CAC=h7gUyvQXDy2Tq5K5gbdpLZyEDWSzr_gsX15z3O-=EWZa9Ew@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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>
</div>
</blockquote>
<br>
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.<br>
<br>
A comparble middleware/apache module could also be used in other
services, allowing the identity inside of Keystone to be used with
remote services.<br>
<br>
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.<br>
<br>
<br>
<br>
<blockquote
cite="mid:CAC=h7gUyvQXDy2Tq5K5gbdpLZyEDWSzr_gsX15z3O-=EWZa9Ew@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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 moz-do-not-send="true"
href="http://web.mit.edu/kerberos/" target="_blank">http://web.mit.edu/kerberos/</a></div>
<div>[2] <a moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>