[keystone] anyone using OpenID with Keystone?

Jonathan Rosser jonathan.rosser at rd.bbc.co.uk
Tue Feb 15 16:57:04 UTC 2022

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.


On 15/02/2022 16:31, Jason Anderson wrote:
>> On Feb 15, 2022, at 4:59 AM, Jonathan Rosser <jonathan.rosser at 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/enable-federation-openidc.yaml)
>>> 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-custom-template
>>> - 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)

More information about the openstack-discuss mailing list