[Edge-computing] [keystone] x509 authentication
jpenick at gmail.com
Fri Jan 25 21:01:52 UTC 2019
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.
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
> 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  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 , 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.
>  https://bugs.launchpad.net/keystone/+bugs?field.tag=x509
> Edge-computing mailing list
> Edge-computing at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Edge-computing