In our case implicit flow was not available so we had to use auth code flow - PKCE was the place to go from there for CLI. I would like to see some of this functionality integrated into the existing CLI tools, requiring an external auth plugin is currently not great user experience. Jonathan. On 15/02/2022 16:31, Jason Anderson wrote:
On Feb 15, 2022, at 4:59 AM, Jonathan Rosser <jonathan.rosser@rd.bbc.co.uk> wrote:
We have patched a keystoneauth plugin to support PKCE which does not require a client secret. It is not strictly required to use PKCE if you want public access grants, it depends on your threat model. As I understand, PKCE adds additional security on top of the implicit authentication flow.
If your IdP supports public access method and it is enabled, you can set OS_CLIENT_SECRET to any value, e.g., “none”. I think it has to be non-empty though for the keystoneauth library to accept it.
It requires your identity provider to support PKCE, keycloak in our case.
https://github.com/bbc/keystoneauth-oidc Very cool!
Hope this is useful, Jonathan.
On 15/02/2022 10:49, Francois wrote:
Hi Keystone users! I am wondering if anyone has experience with keystone openid integration. Initially I was using Keystone LDAP backend (using tripleo KeystoneLDAPDomainEnable and KeystoneLDAPBackendConfigs parameters) and it works! Users are able to log in through Horizon or through the cli, roles can be given per LDAP group, and you can click in Horizon and download a working openrc or clouds.yaml file (minus the root CA that has to be added) to authenticate with the cli (and your password ends as an OS_PASSWORD variable in your environment).
I am now trying the Keystone Openid backend (using the enable-federation-openidc.yaml provided by tripleo - https://github.com/openstack/tripleo-heat-templates/blob/master/environments...) with a mapping like this:
[{"local":[{"user":{"name":"{0}"},"group":{"domain":{"name":"Default"},"name":"federated_users"}}],"remote":[{"type":"HTTP_OIDC_EMAIL"}]}]
The SSO works superb with Horizon, however - logging with the cli seems impractical. I see some doc here: https://docs.ukcloud.com/articles/openstack/ostack-how-use-api-sso.html where you need to provide a secret, I am skeptical I want to do that. The openrc file downloaded from Horizon is not usable as is and needs some tuning. And there is no SSO, and the password still ends up in the environment... For CLI, one thing you can also do is support the v3oidcpassword grant type. This relies on a password the user sets in the IdP, similar in some ways to an “application password” sometimes used for e.g., setting up mail clients.
In Horizon you can override the default OpenRC template so that it is preconfigured to authenticate using OIDC: https://docs.openstack.org/horizon/latest/configuration/settings.html#openrc...
- I don't see how I can grant roles to groups anymore. It seems I need an extra mechanism to grant permissions (as I used to do that using LDAP groups). You’re right, I’m not sure this is possible. You can assign user project memberships but not group project memberships as far as I can tell.
Some other notes on our journey around this, we had additional patches to get things working w/ our model, maybe it can help guide you: https://diurnal.st/2021/07/17/openstack-keystone-federation-part-1.html
I am wondering if anyone is willing to share their experience dealing with Keystone and OpenID.
Thanks! Francois (frigo)