[Edge-computing] [keystone] x509 authentication

Lance Bragstad lbragstad at gmail.com
Tue Jan 29 17:55:09 UTC 2019


On Fri, Jan 25, 2019 at 3:02 PM James Penick <jpenick at gmail.com> wrote:

> 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.
>
>
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.

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.


> -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/20190129/106c6632/attachment.html>


More information about the openstack-discuss mailing list