Open Stack

Hi all,

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.

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.

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.

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.

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.

Thanks,

Lance

[0] https://bugs.launchpad.net/keystone/+bugs?field.tag=x509
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190125/55c28b21/attachment.html>