[Edge-computing] [keystone] x509 authentication

James Penick jpenick at gmail.com
Fri Jan 25 21:01:52 UTC 2019


Hey Lance,
 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.

-James


On Fri, Jan 25, 2019 at 11:16 AM Lance Bragstad <lbragstad at gmail.com> wrote:

> 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
> _______________________________________________
> Edge-computing mailing list
> Edge-computing at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190125/256be8ea/attachment-0001.html>


More information about the openstack-discuss mailing list