Open Stack

On 23 June 2016 at 21:30, Renat Akhmerov <renat.akhmerov at gmail.com> wrote:

> Hi,
>
> I’m looking for some hints on how to enable authentication via OpenID
> Connect protocol, particularly in Mistral. Actually, specific protocol is
> not so important. I’m mostly interested in conceptional vision here and I’d
> like to ask the community if what we would like to do makes sense.
>
> *Problem statement*
>
> Whereas there are people using Mistral as an OpenStack service with proper
> Keystone authentication etc. some people want to be able to use it w/o
> OpenStack at all or in some scenarios where OpenStack is just one thing
> that Mistral workflows should interact with.
>
> In one of our cases we want to use Mistral w/o OpenStack but we want to
> make Mistral perform authentication via OIDC. I’ve done some research on
> what Keystone already has that could help us do that and I found a group of
> plugins for OIDC authentication flows under [1]. The problem I see with
> these plugins for my particular case is that I still have to properly
> install Keystone and configure it for Federation since the plugins use
> Federation. Feels like a redundant time consuming step for me. A normal
> flow for these plugins is to first get so-called unscoped token via OIDC
> and then request a scoped token from Keystone via its Federation API. I
> think understand why it works this way, it’s well documented in Keystone
> docs. Briefly, it’s required to get user info, list of available resources
> etc, whatever OIDC server does not provide, it only works as an identity
> provider.
>
> What ideally I'd like to do is to avoid installing and configuring
> Keystone at all.
>

So with the exception of token_endpoint which is basically for debugging
yes, all the plugins in keystoneauth are designed to work with keystone.
Keystone provides a whole bunch of things here like user, role and project
management - basically the Authorization that goes with OIDC's
authentication.

It also provides the auth_token middleware which reads those tokens and
provides a series of well known headers that you can use to know what
project you're in, do policy enforcement and basically all permission
management. For most projects this is what you care about. If you write
your own version of auth_token middleware for your identity provider you
can use whatever authentication you like.

You'll basically need a way of mapping the information you get from your
OIDC provider into the projects, roles and user info that makes sense for
your service. And when it gets sufficiently complex that you have to allow
different deployers to configure this in different ways and for any number
of protocols you'll have keystone's federation implementation.


> *Possible solution*
>
> What I’m thinking about is: would it be OK to just create a set of new
> authentication plugins under keystoneauth project that would do the same as
> existing ones but w/o getting a Keystone scoped token? That way we could
> still take advantage of existing keystone auth plugins framework but w/o
> having to install and configure Keystone service. I realize that we’ll lose
> some capabilities that Keystone provides but for many cases it would be
> enough just to authenticate on a client and then validate token from HTTP
> headers via OIDC server on server side. Just one more necessary thing to do
> here is to fill tenant/project but that could be extracted from a token.
>

So you can use keystoneauth to implement plugins that do not hit keystone.
A plugin basically has to implement this[1] interface which has no direct
ties to keystone. There is then a standard subclass of this that handles
most of the work for interacting with keystone that the existing plugins
all use. It's fairly well documented but if you have additional questions
let us know.

I'm pretty sure from here you can use the new version of openstackclient
and anything else that uses keystoneauth.

These plugins would probably not live in the keystoneauth repository unless
there was a lot more people interested in using them - however
keystoneauth, OSC, shade etc all specify the plugin to use via a name which
is a setuptools entrypoint so so long as the plugin is installed on the
system you can use it even though it wasn't in the repo.


[1]
https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/plugin.py


>
> *Questions*
>
>
>    1. Would this new plugin have a right to be part of keystoneauth
>    project despite Keystone service is not involved at all? The alternative is
>    just to teach Mistral to do authentication w/o using keystone client  at
>    all. But IMO the advantage of having such plugin (group of plugins
>    actually) is that someone else could reuse it.
>
> Not initially, but as i mentioned above so long as its installed on the
machine you want to use it from that doesn't matter.

>
>    1. Is there any existing code that we could reuse to solve this
>    problem? Maybe what I’m describing is already solved by someone.
>
> There are a number of different types of plugins. You can look at

 * the token_endpoint plugin which doesn't talk to keystone [2]
 * there is a review up at the moment for "tokenless auth" [3] which
basically assumes client certs will handle negotiation.
 * I would then look for a requests OIDC plugin, if you remove all the
keystone specifics stuff keystoneauth is a wrapper around requests' auth
and you should try and reuse one of those plugins.

[2]
https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/token_endpoint.py
[3] https://review.openstack.org/#/c/283905/


>
>    1. Can you please point to some user examples on how to switch between
>    authentication plugins in both client and service for some OpenStack
>    services? I read the docs and looked at the code but it’s still not so
>    clear how to implement support for different plugins on the client in the
>    best way. I’m looking for best practices. Server side seems ok because we
>    use keystonemiddleware and it can dynamically load a plugin by name and use
>    relevant config options just by specifying “auth_plugin” property.
>
> So openstackclient has some writeup of how you select an auth plugin [4]
this behaviour is intended to come from os-client-config which has a
smaller writeup [5], the client side is a similar process to the server
side with just a different way of inputting options.

That second part though about keystonemiddleware and auth_plugin. That
auth_plugin is telling auth_token middleware how it should connect to
keystone so it can validate your keystone token. If you were to remove
keystone then auth_token is fairly useless. This is going to be the most
difficult part of your plan as you are going to need to reimplement this
with something that can understand your chosen authentication type.

Can I strongly suggest you do what keystone did here and use apache/nginx
(like mod_auth_openidc) to do the actual oidc work and just handle the
output of these plugins. Implementing these protocols yourself is generally
not a good idea.

[4]
http://docs.openstack.org/developer/python-openstackclient/authentication.html
[5]
http://docs.openstack.org/developer/os-client-config/index.html#auth-settings

>
>    1. What may be some other caveats in the solution I described?
>
> In general i think you underestimate what keystone is doing for you here,
however from a client side keystoneauth is capable of doing everything you
want.



Jamie




>
> Thanks
>
> [1]
> https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/identity/v3/oidc.py
>
>
> Renat Akhmerov
> @Nokia
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160701/803bbd8c/attachment.html>