Open Stack

Bah! I saw this while on holiday and didn't get a chance to respond,
sorry for being late to the conversation.

On 11/08/18 3:46 AM, Colleen Murphy wrote:
> ### Self-Service Keystone
>
> At the weekly meeting Adam suggested we make self-service keystone a focus point of the PTG[9]. Currently, policy limitations make it difficult for an unprivileged keystone user to get things done or to get information without the help of an administrator. There are some other projects that have been created to act as workflow proxies to mitigate keystone's limitations, such as Adjutant[10] (now an official OpenStack project) and Ksproj[11] (written by Kristi). The question is whether the primitives offered by keystone are sufficient building blocks for these external tools to leverage, or if we should be doing more of this logic within keystone. Certainly improving our RBAC model is going to be a major part of improving the self-service user experience.
>
> [9] http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-08-07-16.00.log.html#l-121
> [10] https://adjutant.readthedocs.io/en/latest/
> [11] https://github.com/CCI-MOC/ksproj

As you can probably expect, I'd love to be a part of any of these
discussions. Anything I can nicely move to being logic directly
supported in Keystone, the less I need to do in Adjutant. The majority
of things though I think I can do reasonably well with the primitives
Keystone gives me, and what I can't I tend to try and work with upstream
to fill the gaps.

System vs project scope helps a lot though, and I look forward to really
playing with that.

I sadly won't be at the PTG, but will be at the Berlin summit. Plus I
have a lot of Adjutant work planned for Stein, a large chunk of which is
refactors and reshuffling blueprints and writing up a roadmap, plus some
better entry point tasks for new contributors.

> ### Standalone Keystone
>
> Also at the meeting and during office hours, we revived the discussion of what it would take to have a standalone keystone be a useful identity provider for non-OpenStack projects[12][13]. First up we'd need to turn keystone into a fully-fledged SAML IdP, which it's not at the moment (which is a point of confusion in our documentation), or even add support for it to act as an OpenID Connect IdP. This would be relatively easy to do (or at least not impossible). Then the application would have to use keystonemiddleware or its own middleware to route requests to keystone to issue and validate tokens (this is one aspect where we've previously discussed whether JWT could benefit us). Then the question is what should a not-OpenStack application do with keystone's "scoped RBAC"? It would all depend on how the resources of the application are grouped and whether they care about multitenancy in some form. Likely each application would have different needs and it would be difficult to find a one-size-fits-all approach. We're interested to know whether anyone has a burning use case for something like this.
>
> [12] http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-08-07-16.00.log.html#l-192
> [13] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-08-07.log.html#t2018-08-07T17:01:30

This one is interesting because another department at Catalyst is
actually looking to use Keystone outside of the scope of OpenStack. They
are building a SaaS platform, and they need authn, authz (with some
basic RBAC), a service catalog (think API endpoint per software
offering), and most of those things are useful outside of OpenStack.
They can then use projects to signify a customer, and a project
(customer) could have one or more users accessing the management GUIs,
with roles giving them some RBAC. A large part of this is because they
can then also piggy back on a lot of work our team has done with
OpenStack and Keystone and even reuse some of our projects and tools for
billing and other things (Adjutant maybe?). They could use KeystoneAuth
for CLI and client tools, they can build their APIs using
Keystonemiddleware.


Then another reason why this actually interests the Catalyst Cloud team
is because we actually use Keystone with an SQL backend for our public
cloud, with the db in a multi-region galera cluster. Keystone is our
Idp, we don't federate it, and we now have a reasonably passable 2FA
option on it, with a better MFA option coming in Stein when I'm done
with Auth Receipts. We actually kind of like Keystone for our authn, and
because we didn't have any existing users when we first built our cloud
so using vanilla Keystone seemed like a sensible solution. We had plans
to migrate users and federate, or move to LDAP, but they never
materialized because maintaining more systems didn't make sense and did
add many useful benefits. Making Keystone a fully fledged Idp with SAML
and OpenID support would be fantastic because we could then build a tiny
single sign on around Keystone and use that for all our non-openstack
services.

In fact I had a prototype side project planned which would be a tiny
Flask or Django app that would act as a single sign on for Keystone. It
would have a login form that handles the new MFA process with auth
receipts in Keystone, and on getting the token it would wrap that into
an OpenID token which other systems could interpret. With the
appropriate APIs for acting as a provider and most of those just doing
user actions with that token in Keystone. In theory I could have made it
a tiny entirely ephemeral app which only needs to know where keystone is
(no admin creds). Basically a tiny Idp around Keystone.

But if Keystone goes down the path of supporting SAML and OpenID then
all we really need is a login GUI that supports auth receipts (and
plugin support for different types of MFA to match ones in Keystone),
which probably still should be a tiny side project rather than views in
Keystone (should Keystone really serve HTML?), or requiring Horizon
(Horizon could use it as a SSO). I would love to help with something
like this if we do go down that path. :)