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... - 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). I am wondering if anyone is willing to share their experience dealing with Keystone and OpenID. Thanks! Francois (frigo)
We have patched a keystoneauth plugin to support PKCE which does not require a client secret. It requires your identity provider to support PKCE, keycloak in our case. https://github.com/bbc/keystoneauth-oidc 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... - 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).
I am wondering if anyone is willing to share their experience dealing with Keystone and OpenID.
Thanks! Francois (frigo)
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.
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)
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)
Would application credentials fit your use case for CLI access? Users will be able to create them through Horizon, and after creation they will be prompted to download either a clouds.yaml or an openrc file, so the process is pretty straightforward. https://docs.openstack.org/keystone/latest/user/application_credentials.html Can you elaborate more on your issue with not being able to grant roles to groups? Best, Kristi On Feb 15, 2022, at 05:49, Francois <rigault.francois@gmail.com<mailto:rigault.francois@gmail.com>> 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... - 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). I am wondering if anyone is willing to share their experience dealing with Keystone and OpenID. Thanks! Francois (frigo)
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 On 2/16/22 15:23, Nikolla, Kristi wrote:
Would application credentials fit your use case for CLI access? Users will be able to create them through Horizon, and after creation they will be prompted to download either a clouds.yaml or an openrc file, so the process is pretty straightforward.
https://docs.openstack.org/keystone/latest/user/application_credentials.html <https://docs.openstack.org/keystone/latest/user/application_credentials.html>
Can you elaborate more on your issue with not being able to grant roles to groups?
Best, Kristi
On Feb 15, 2022, at 05:49, Francois <rigault.francois@gmail.com <mailto:rigault.francois@gmail.com>> 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... <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 <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... - 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).
I am wondering if anyone is willing to share their experience dealing with Keystone and OpenID.
Thanks! Francois (frigo)
participants (5)
-
Francois
-
Jason Anderson
-
Jonathan Rosser
-
Jose Castro Leon
-
Nikolla, Kristi