openstack client integration to fetch and provide OIDC access tokens (v3oidcaccesstoken)?
Hey openstack-discuss,
while there is support for OpenID Connect and its various flows in the openstack client (https://docs.openstack.org/python-openstackclient/latest/cli/man/openstack.h...).
I would like to have the user authenticate only with central IdP login via a web page and then receive an access token and not have each user's openstack cli be a full OIDC client handling credentials and authenticating against the IdP via the users password itself.
The tricky bit here is having good tooling for users to authenticate via the existing SSO and then to get and refresh tokens which are then fed to the openstack CLI. I was wondering if anybody knows of some nice integrations / plugins / hooks to make it easy for users to deal with the authentication (usually via some web site) and then to inject the token (v3oidcaccesstoken) into openstack-cli?
I found that Fedcloud.eu (https://www.fedcloud.eu/) does something like this (see https://fedcloudclient.fedcloud.eu/usage.html#authentication) via OIDC-Agent. But most platforms making use of OIDC seem to configure the openstack client with client_id and secret and have it authenticate directly with the IdP.
Regards,
Christian
On 20/01/2023 21:22, Christian Rohmann wrote:
I found that Fedcloud.eu (https://www.fedcloud.eu/) does something like this (see https://fedcloudclient.fedcloud.eu/usage.html#authentication) via OIDC-Agent. But most platforms making use of OIDC seem to configure the openstack client with client_id and secret and have it authenticate directly with the IdP.
My team contributed patches to https://github.com/IFCA/keystoneauth-oidc to use PKCE so that a client ID and client secret do not need to be given to users.
Hope this is useful, Jon.
Thanks Jonathan for your response!
On 23/01/2023 11:09, Jonathan Rosser wrote:
My team contributed patches to https://github.com/IFCA/keystoneauth-oidc to use PKCE so that a client ID and client secret do not need to be given to users.
That sounds interesting - I suppose this patch would extend the auth plugins listed at https://docs.openstack.org/keystoneauth/latest/plugin-options.html#available... ? Could you elaborate a little more on the architecture and auth workflow you have using this patch?
Do you have any plans to push this upstream to become part of the standard plugins by any chance?
Thanks again and with kind regards,
Christian
Hi Christian,
We deploy openstack with keystone behind Apache and mod_oidc, using Keycloak as an IdP with the client set as 'public' to enable PKCE.
We provide a 'helper' git repo to setup a correctly configured virtualenv for users which also installs keystoneauth-oidc. A script in that repo lets a user trigger the login flow (essentially openstack <options> token issue) which launches a local browser window to complete the SSO / 2FA process. Environment vars including OS_TOKEN are exported by the script.
If my memory serves correctly I did approach the Keystone team in IRC to have one of my developers contribute better support for OIDC in keystoneauth, but there was a preference for a much more significant rewrite of parts of keystone. Unfortunately time has passed and I think that an external plugin is still needed for a secure OIDC cli experience using a modern auth flow.
Jon.
On 23/01/2023 12:19, Christian Rohmann wrote:
Thanks Jonathan for your response!
On 23/01/2023 11:09, Jonathan Rosser wrote:
My team contributed patches to https://github.com/IFCA/keystoneauth-oidc to use PKCE so that a client ID and client secret do not need to be given to users.
That sounds interesting - I suppose this patch would extend the auth plugins listed at https://docs.openstack.org/keystoneauth/latest/plugin-options.html#available... ? Could you elaborate a little more on the architecture and auth workflow you have using this patch?
Do you have any plans to push this upstream to become part of the standard plugins by any chance?
Thanks again and with kind regards,
Christian
Hey Jon, all,
Jose, Nikolla, Francois: You did discuss about the current state of using OIDC with keystone and about a secure flow to use existing SSO and only provide tokens to the openstack cli in https://lists.openstack.org/pipermail/openstack-discuss/2022-February/027313..., sorry I did not find this prior to me posting and asking about this. I took the liberty to CC you. Alvaro you did apparently write up the below referenced spec about improving on the OIDC support in keystone so I CCed you as well.
1) On 16/02/2022 15:45, Jose Castro Leon wrote:
Hi, We are preparing something based on keystoneauth1 that uses an authorization code grant in OIDC that will send you an url address to the client so they can do the SSO there and receive a validation code. Then you input the validation code in the CLI and receive an OIDC.
Once it receives the OIDC access token and refresh token, we cache them on the filesystem for subsequent calls.
The idea was to contribute it upstream once we clean it up a bit
Cheers Jose
Jose, could you maybe give an update on your endeavors? Do you have your code public anywhere? Do you still plan to upstream this code?
2) On 23/01/2023 13:59, Jonathan Rosser wrote:
If my memory serves correctly I did approach the Keystone team in IRC to have one of my developers contribute better support for OIDC in keystoneauth, but there was a preference for a much more significant rewrite of parts of keystone. Unfortunately time has passed and I think that an external plugin is still needed for a secure OIDC cli experience using a modern auth flow.
That is exactly where we ended up when diving deeper into the existing OIDC capabilities :-) Would you then consider contributing your code upstream?
3) There likely would have to be a spec first do do any major change / addition to keystone auth capabilties. But there already are some specs / ideas discussing the OIDC integration:
* https://opendev.org/openstack/keystone-specs/src/branch/master/specs/keyston... * less related, but quite recent: https://opendev.org/openstack/keystone-specs/src/branch/master/specs/keyston...
4) I certainly understand that my naive initial question about fetching a v3oidcaccesstoken and use it comes way short of the actually intended authentication flows, such as using existing SSO (via PKCE) and then receiving the callback. But also making use of refresh tokens, handling expired tokens, ...
My intention is simply to revive the discussion around this topic and to potentially join forces / code to make keystone, keystoneauth1 and the openstack clients integrate nicely and securely with (existing) OIDC infrastructure and flows
Regards
Christian
Dear all.
This has been a long time ago since we implemented this, so I had to refresh my mind. Also, long time without contributing to OpenStack.
See my responses inline.
On 16/02/2022 15:45, Jose Castro Leon wrote:
We are preparing something based on keystoneauth1 that uses an authorization code grant in OIDC that will send you an url address to the client so they can do the SSO there and receive a validation code. Then you input the validation code in the CLI and receive an OIDC.
Once it receives the OIDC access token and refresh token, we cache them on the filesystem for subsequent calls.
The idea was to contribute it upstream once we clean it up a bit
Cheers Jose
Jose, could you maybe give an update on your endeavors? Do you have your code public anywhere? Do you still plan to upstream this code?
So far the first part is already implemented, using the Client Credentials grant type:
https://github.com/openstack/keystoneauth/commit/e5fd66ca35424108ca0c1234119...
The part about storing the access and refresh tokens on disk was never addressed though.
There likely would have to be a spec first do do any major change / addition to keystone auth capabilties. But there already are some specs / ideas discussing the OIDC integration:
* https://opendev.org/openstack/keystone-specs/src/branch/master/specs/keyston...
We implemented a prototype plugin for the Keystone server here:
https://github.com/IFCA/keystone-oidc-auth-plugin
And the client part here:
https://github.com/IFCA/keystone-oidc-auth-plugin
However, this was blocked due to this issue, that IIRC was introduced when Keystone removed the custom WSGI stack.
https://bugs.launchpad.net/keystone/+bug/1854041 https://review.opendev.org/c/openstack/keystone/+/754694
I certainly understand that my naive initial question about fetching a v3oidcaccesstoken and use it comes way short of the actually intended authentication flows, such as using existing SSO (via PKCE) and then receiving the callback. But also making use of refresh tokens, handling expired tokens, ...
We had that interest too, but to be honest then we quit.
However, I think that there is still a better approach, that is to use an OpenID Connect agent (that handles all the nasty handling of tokens) and then using the keystonauth1 v3oidcaccesstoken plugin, modifying it to get the token from the agent:
https://github.com/indigo-dc/oidc-agent
We have implemented this internally, and it has been a long time since we implemented it, but I think that I can test it (tomorrow CEST) and try to prepare a patch, also writing some documentation, if that helps. If there is some movement arount it will be easier to get things merged.
Best,
participants (3)
-
Christian Rohmann
-
Jonathan Rosser
-
Álvaro López García