Jamie, Thanks a lot for your detailed answer. We’ll think again about all that taking your comments into account.
Renat Akhmerov @Nokia > On 01 Jul 2016, at 13:10, Jamie Lennox <[email protected]> wrote: > > > > On 23 June 2016 at 21:30, Renat Akhmerov <[email protected] > <mailto:[email protected]>> 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 > <https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/plugin.py> > > > > Questions > > 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. > 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 > > <https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/token_endpoint.py> > [3] https://review.openstack.org/#/c/283905/ > <https://review.openstack.org/#/c/283905/> > > 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 > > <http://docs.openstack.org/developer/python-openstackclient/authentication.html> > > [5] > http://docs.openstack.org/developer/os-client-config/index.html#auth-settings > <http://docs.openstack.org/developer/os-client-config/index.html#auth-settings> > 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 > > <https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/identity/v3/oidc.py> > > > Renat Akhmerov > @Nokia > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > <http://[email protected]/?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
