Open Stack

Sending a quick update here that summarizes activity on this topic from
the last couple of weeks.

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.

[0] https://bugs.launchpad.net/keystone/+bugs?field.tag=x509

On 1/29/19 11:55 AM, Lance Bragstad wrote:
>
>
> On Fri, Jan 25, 2019 at 3:02 PM James Penick <jpenick at gmail.com
> <mailto: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 <mailto: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
>         <mailto: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/20190212/889800a9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190212/889800a9/attachment-0001.sig>