<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Jamie,<div class=""><br class=""></div><div class="">Thanks a lot for your detailed answer. We’ll think again about all that taking your comments into account.</div><div class=""><br class=""></div><div class=""><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Renat Akhmerov</div><div class="">@Nokia</div></div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On 01 Jul 2016, at 13:10, Jamie Lennox <<a href="mailto:jamielennox@gmail.com" class="">jamielennox@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On 23 June 2016 at 21:30, Renat Akhmerov <span dir="ltr" class=""><<a href="mailto:renat.akhmerov@gmail.com" target="_blank" class="">renat.akhmerov@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class="">Hi,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><b class="">Problem statement</b></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">What ideally I'd like to do is to avoid installing and configuring Keystone at all. </div></div></blockquote><div class=""><br class=""></div><div class="">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. <br class=""><br class=""></div><div class="">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.<br class=""><br class=""></div><div class="">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.<br class=""></div><div class=""> <br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""></div><div class=""><b class="">Possible solution</b></div><div class=""><br class=""></div><div class="">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.</div></div></blockquote><div class=""><br class=""></div><div class="">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. <br class=""><br class=""></div><div class="">I'm pretty sure from here you can use the new version of openstackclient and anything else that uses keystoneauth. <br class=""><br class=""></div><div class="">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. <br class=""><br class=""><br class="">[1] <a href="https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/plugin.py" class="">https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/plugin.py</a> <br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""></div><div class=""><br class=""></div><div class=""><b class="">Questions</b></div><div class=""><br class=""></div><div class=""><ol class=""><li class="">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.</li></ol></div></div></blockquote><div class="">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. <br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><ol class=""><li class="">Is there any existing code that we could reuse to solve this problem? Maybe what I’m describing is already solved by someone.</li></ol></div></div></blockquote><div class="">There are a number of different types of plugins. You can look at <br class=""> <br class=""> * the token_endpoint plugin which doesn't talk to keystone [2] <br class=""> * there is a review up at the moment for "tokenless auth" [3] which basically assumes client certs will handle negotiation. <br class=""></div><div class=""> * 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. <br class=""></div><div class=""><br class="">[2] <a href="https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/token_endpoint.py" class="">https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/token_endpoint.py</a><br class="">[3] <a href="https://review.openstack.org/#/c/283905/" class="">https://review.openstack.org/#/c/283905/</a><br class=""> <br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><ol class=""><li class="">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.</li></ol></div></div></blockquote><div class="">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. <br class=""><br class=""></div><div class="">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.<br class=""><br class=""></div><div class="">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.<br class=""></div><div class=""><br class="">[4] <a href="http://docs.openstack.org/developer/python-openstackclient/authentication.html" class="">http://docs.openstack.org/developer/python-openstackclient/authentication.html</a> <br class="">[5] <a href="http://docs.openstack.org/developer/os-client-config/index.html#auth-settings" class="">http://docs.openstack.org/developer/os-client-config/index.html#auth-settings</a><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><ol class=""><li class="">What may be some other caveats in the solution I described?</li></ol></div></div></blockquote><div class="">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.<br class=""><br class=""><br class=""><br class=""></div><div class="">Jamie <br class=""><br class=""><br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><div class=""><div class="">Thanks</div></div><div class=""><br class=""></div><div class="">[1] <a href="https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/identity/v3/oidc.py" target="_blank" class="">https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/identity/v3/oidc.py</a></div><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class=""><br class=""><div class="">
<div style="letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; word-wrap: break-word;" class=""><div class="">Renat Akhmerov</div><div class="">@Nokia</div></div>
</div>
<br class=""></div></font></span></div><br class="">__________________________________________________________________________<br class="">
OpenStack Development Mailing List (not for usage questions)<br class="">
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank" class="">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class="">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="">
<br class=""></blockquote></div><br class=""></div></div>
__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" class="">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class=""></div></blockquote></div><br class=""></div></body></html>