<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Sending a quick update here that summarizes activity on this topic
from the last couple of weeks.<br>
<br>
A few more bugs have trickled in regarding x509 federation support
[0]. One of the original authors of the feature has started chipping
away at fixing them, but they can be worked in parallel if others
are interested in this work. As a reminder, there are areas of the
docs that can be improved, in case you don't have time to dig into a
patch.<br>
<br>
[0] <a class="moz-txt-link-freetext" href="https://bugs.launchpad.net/keystone/+bugs?field.tag=x509">https://bugs.launchpad.net/keystone/+bugs?field.tag=x509</a><br>
<br>
<div class="moz-cite-prefix">On 1/29/19 11:55 AM, Lance Bragstad
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAE6oFcEWjZ1i0f=gfTZyas6o=xoaH05KjRPFWiZyr1=FygwzvA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Jan 25, 2019 at 3:02
PM James Penick <<a href="mailto:jpenick@gmail.com"
moz-do-not-send="true">jpenick@gmail.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">Hey Lance,
<div> We'd definitely be interested in helping with the
work. I'll grab some volunteers from my team and get
them in touch within the next few days.</div>
<div><br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Awesome, that sounds great! I'm open to using this thread
for more technical communication if needed. Otherwise,
#openstack-keystone is always open for folks to swing by if
they want to discuss things there.</div>
<div><br>
</div>
<div>FWIW - we brought this up in the keystone meeting today
and there several other people interested in this work.
There is probably going to be an opportunity to break the
work up a bit.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>-James</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr"
class="gmail-m_-3216276696108083358gmail_attr">On Fri,
Jan 25, 2019 at 11:16 AM Lance Bragstad <<a
href="mailto:lbragstad@gmail.com" target="_blank"
moz-do-not-send="true">lbragstad@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div dir="ltr">Hi all,
<div><br>
</div>
<div>We've been going over keystone gaps that need
to be addressed for edge use cases every Tuesday.
Since Berlin, Oath has open-sourced some of their
custom authentication plugins for keystone that
help them address these gaps.</div>
<div><br>
</div>
<div>The basic idea is that users authenticate to
some external identity provider (Athenz in Oath's
case), and then present an Athenz token to
keystone. The custom plugins decode the token from
Athenz to determine the user, project, roles
assignments, and other useful bits of information.
After that, it creates any resources that don't
exist in keystone already. Ultimately, a user can
authenticate against a keystone node and have
specific resources provisioned automatically. In
Berlin, engineers from Oath were saying they'd
like to move away from Athenz tokens altogether
and use x509 certificates issued by Athenz
instead. The auto-provisioning approach is very
similar to a feature we have in keystone already.
In Berlin, and shortly after, there was general
agreement that if we could support x509
authentication with auto-provisioning via keystone
federation, that would pretty much solve Oath's
use case without having to maintain custom
keystone plugins.</div>
<div><br>
</div>
<div>Last week, Colleen started digging into
keystone's existing x509 authentication support.
I'll start with the good news, which is x509
authentication works, for the most part. It's been
a feature in keystone for a long time, and it
landed after we implemented federation support
around the Kilo release. Chances are there won't
be a need for a keystone specification like we
were initially thinking in the edge meetings.
Unfortunately, the implementation for x509
authentication has outdated documentation, is
extremely fragile, hard to set up, and hasn't been
updated with improvements we've made to the
federation API since the original implementation
(like shadow users or auto-provisioning, which
work with other federated protocols like OpenID
Connect and SAML). We've started tracking the gaps
with bugs [0] so that we have things written down.</div>
<div><br>
</div>
<div>I think the good thing is that once we get this
cleaned up, we'll be able to re-use some of the
newer federation features with x509
authentication/federation. These updates would
make x509 a first-class federated protocol. The
approach, pending the bug fixes, would remove the
need for Oath's custom authentication plugins. It
could be useful for edge deployments, or even
deployments with many regions, by allowing users
to be auto-provisioned in each region. Although,
it doesn't necessarily solve the network partition
issue.</div>
<div><br>
</div>
<div>Now that we have an idea of where to start and
some bug reports [0], I'm wondering if anyone is
interested in helping with the update or refactor.
Because this won't require a specification, we can
get started on it sooner, instead of having to
wait for Train development and a new
specification. I'm also curious if anyone has
comments or questions about the approach.</div>
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div>Lance</div>
<div><br>
</div>
<div>[0] <a
href="https://bugs.launchpad.net/keystone/+bugs?field.tag=x509"
target="_blank" moz-do-not-send="true">https://bugs.launchpad.net/keystone/+bugs?field.tag=x509</a></div>
</div>
</div>
_______________________________________________<br>
Edge-computing mailing list<br>
<a href="mailto:Edge-computing@lists.openstack.org"
target="_blank" moz-do-not-send="true">Edge-computing@lists.openstack.org</a><br>
<a
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing</a><br>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>