[keystone] Federated users who wish to use CLI
Hi all,
I'm in the process of prototyping a federated Keystone using OpenID Connect, which will place ephemeral users in a group that has roles in existing projects. I was testing how it felt from the user's perspective and am confused how I'm supposed to be able to use the openstacksdk with federation. For one thing, the RC files I can download from the "API Access" section of Horizon don't seem like they work; the domain is hard-coded to "Federated", and it also uses a username/password authentication method.
I can see that there is a way to use KSA to use an existing OIDC token, which I think is probably the most "user-friendly" way, but the user still has to obtain this token themselves out-of-band, which is not trivial. Has anybody else set this up for users who liked to use the CLI? Is the solution to educate users about creating application credentials instead?
Thank you in advance,
-- Jason Anderson
Chameleon DevOps Lead Consortium for Advanced Science and Engineering, The University of Chicago Mathematics & Computer Science Division, Argonne National Laboratory
Hi Jason,
On Mon, Oct 21, 2019, at 14:35, Jason Anderson wrote:
Hi all,
I'm in the process of prototyping a federated Keystone using OpenID Connect, which will place ephemeral users in a group that has roles in existing projects. I was testing how it felt from the user's perspective and am confused how I'm supposed to be able to use the openstacksdk with federation. For one thing, the RC files I can download from the "API Access" section of Horizon don't seem like they work; the domain is hard-coded to "Federated",
This should be fixed in the latest version of keystone...
and it also uses a username/password authentication method.
...but this is not, horizon only knows about the 'password' authentication method and can't provide RC files for other types of auth methods (unless you create an application credential).
I can see that there is a way to use KSA to use an existing OIDC token, which I think is probably the most "user-friendly" way, but the user still has to obtain this token themselves out-of-band, which is not trivial. Has anybody else set this up for users who liked to use the CLI?
All of KSA's auth types are supported by the openstack CLI. Which one you use depends on your OpenID Connect provider. If your provider supports it, you can use the "v3oidcpassword" auth method with the openstack CLI, following this example:
https://support.massopen.cloud/kb/faq.php?id=16
On the other hand if you are using something like Google which only supports the authorization_code grant type, then you would have to get the authorization code out of band and then use the "v3oidcauthcode" auth type, and personally I've never gotten that to work with Google.
Is the solution to educate users about creating application credentials instead?
This is the best option. It's much easier to manage and horizon provides openrc and clouds.yaml files for app creds.
Hope this helps,
Colleen
Thank you in advance,
-- Jason Anderson
Chameleon DevOps Lead *Consortium for Advanced Science and Engineering, The University of Chicago* *Mathematics & Computer Science Division, Argonne National Laboratory*
Hello Colleen, Have you tested the OpenStack CLI with v3oidcpassword or v3oidcauthcode and multiple IdPs configured in Keystone?
We are currently debugging and discussing on how to enable this support in the CLI. So far, we were not able to make it work with the current code. This also happens with Horizon. If one has multiple IdPs in Keystone, the "discovery" process would happen twice, one in Horizon and another in Keystone, which is executed by the OIDC plugin in the HTTPD. We already fixed the Horizon issue, but the CLI we are still investigating, and we suspect that is probably the same problem.
On Wed, Oct 23, 2019 at 1:56 PM Colleen Murphy colleen@gazlene.net wrote:
Hi Jason,
On Mon, Oct 21, 2019, at 14:35, Jason Anderson wrote:
Hi all,
I'm in the process of prototyping a federated Keystone using OpenID Connect, which will place ephemeral users in a group that has roles in existing projects. I was testing how it felt from the user's perspective and am confused how I'm supposed to be able to use the openstacksdk with federation. For one thing, the RC files I can download from the "API Access" section of Horizon don't seem like they work; the domain is hard-coded to "Federated",
This should be fixed in the latest version of keystone...
and it also uses a username/password authentication method.
...but this is not, horizon only knows about the 'password' authentication method and can't provide RC files for other types of auth methods (unless you create an application credential).
I can see that there is a way to use KSA to use an existing OIDC token, which I think is probably the most "user-friendly" way, but the user still has to obtain this token themselves out-of-band, which is not trivial. Has anybody else set this up for users who liked to use the CLI?
All of KSA's auth types are supported by the openstack CLI. Which one you use depends on your OpenID Connect provider. If your provider supports it, you can use the "v3oidcpassword" auth method with the openstack CLI, following this example:
https://support.massopen.cloud/kb/faq.php?id=16
On the other hand if you are using something like Google which only supports the authorization_code grant type, then you would have to get the authorization code out of band and then use the "v3oidcauthcode" auth type, and personally I've never gotten that to work with Google.
Is the solution to educate users about creating application credentials instead?
This is the best option. It's much easier to manage and horizon provides openrc and clouds.yaml files for app creds.
Hope this helps,
Colleen
Thank you in advance,
-- Jason Anderson
Chameleon DevOps Lead *Consortium for Advanced Science and Engineering, The University of
Chicago*
*Mathematics & Computer Science Division, Argonne National Laboratory*
Hi Rafael,
I have no experience with using multiple identity providers directly in Keystone. Does specifying the access_token_endpoint or discovery_endpoint for the specific provider you are trying to authenticate to work?
Kristi
On Wed, Oct 23, 2019 at 2:06 PM Rafael Weingärtner < rafaelweingartner@gmail.com> wrote:
Hello Colleen, Have you tested the OpenStack CLI with v3oidcpassword or v3oidcauthcode and multiple IdPs configured in Keystone?
We are currently debugging and discussing on how to enable this support in the CLI. So far, we were not able to make it work with the current code. This also happens with Horizon. If one has multiple IdPs in Keystone, the "discovery" process would happen twice, one in Horizon and another in Keystone, which is executed by the OIDC plugin in the HTTPD. We already fixed the Horizon issue, but the CLI we are still investigating, and we suspect that is probably the same problem.
On Wed, Oct 23, 2019 at 1:56 PM Colleen Murphy colleen@gazlene.net wrote:
Hi Jason,
On Mon, Oct 21, 2019, at 14:35, Jason Anderson wrote:
Hi all,
I'm in the process of prototyping a federated Keystone using OpenID Connect, which will place ephemeral users in a group that has roles in existing projects. I was testing how it felt from the user's perspective and am confused how I'm supposed to be able to use the openstacksdk with federation. For one thing, the RC files I can download from the "API Access" section of Horizon don't seem like they work; the domain is hard-coded to "Federated",
This should be fixed in the latest version of keystone...
and it also uses a username/password authentication method.
...but this is not, horizon only knows about the 'password' authentication method and can't provide RC files for other types of auth methods (unless you create an application credential).
I can see that there is a way to use KSA to use an existing OIDC token, which I think is probably the most "user-friendly" way, but the user still has to obtain this token themselves out-of-band, which is not trivial. Has anybody else set this up for users who liked to use the CLI?
All of KSA's auth types are supported by the openstack CLI. Which one you use depends on your OpenID Connect provider. If your provider supports it, you can use the "v3oidcpassword" auth method with the openstack CLI, following this example:
https://support.massopen.cloud/kb/faq.php?id=16
On the other hand if you are using something like Google which only supports the authorization_code grant type, then you would have to get the authorization code out of band and then use the "v3oidcauthcode" auth type, and personally I've never gotten that to work with Google.
Is the solution to educate users about creating application credentials instead?
This is the best option. It's much easier to manage and horizon provides openrc and clouds.yaml files for app creds.
Hope this helps,
Colleen
Thank you in advance,
-- Jason Anderson
Chameleon DevOps Lead *Consortium for Advanced Science and Engineering, The University of
Chicago*
*Mathematics & Computer Science Division, Argonne National Laboratory*
-- Rafael Weingärtner
We are using the "access_token_endpoint". The token is retrieved nicely from the IdP. However, the issue starts on Keystone side and the Apache HTTPD mod_auth_openidc. The CLI was not ready to deal with it. It is like Horizon, when we have multiple IdPs. The discovery process happens twice, once in Horizon and another one in Keystone. We already fixed the Horizon issue, and now we are working to fix the CLI. We should have something in the next few days.
On Thu, Oct 24, 2019 at 1:29 PM Kristi Nikolla kristi@nikolla.me wrote:
Hi Rafael,
I have no experience with using multiple identity providers directly in Keystone. Does specifying the access_token_endpoint or discovery_endpoint for the specific provider you are trying to authenticate to work?
Kristi
On Wed, Oct 23, 2019 at 2:06 PM Rafael Weingärtner < rafaelweingartner@gmail.com> wrote:
Hello Colleen, Have you tested the OpenStack CLI with v3oidcpassword or v3oidcauthcode and multiple IdPs configured in Keystone?
We are currently debugging and discussing on how to enable this support in the CLI. So far, we were not able to make it work with the current code. This also happens with Horizon. If one has multiple IdPs in Keystone, the "discovery" process would happen twice, one in Horizon and another in Keystone, which is executed by the OIDC plugin in the HTTPD. We already fixed the Horizon issue, but the CLI we are still investigating, and we suspect that is probably the same problem.
On Wed, Oct 23, 2019 at 1:56 PM Colleen Murphy colleen@gazlene.net wrote:
Hi Jason,
On Mon, Oct 21, 2019, at 14:35, Jason Anderson wrote:
Hi all,
I'm in the process of prototyping a federated Keystone using OpenID Connect, which will place ephemeral users in a group that has roles in existing projects. I was testing how it felt from the user's perspective and am confused how I'm supposed to be able to use the openstacksdk with federation. For one thing, the RC files I can download from the "API Access" section of Horizon don't seem like they work; the domain is hard-coded to "Federated",
This should be fixed in the latest version of keystone...
and it also uses a username/password authentication method.
...but this is not, horizon only knows about the 'password' authentication method and can't provide RC files for other types of auth methods (unless you create an application credential).
I can see that there is a way to use KSA to use an existing OIDC token, which I think is probably the most "user-friendly" way, but the user still has to obtain this token themselves out-of-band, which is not trivial. Has anybody else set this up for users who liked to use the CLI?
All of KSA's auth types are supported by the openstack CLI. Which one you use depends on your OpenID Connect provider. If your provider supports it, you can use the "v3oidcpassword" auth method with the openstack CLI, following this example:
https://support.massopen.cloud/kb/faq.php?id=16
On the other hand if you are using something like Google which only supports the authorization_code grant type, then you would have to get the authorization code out of band and then use the "v3oidcauthcode" auth type, and personally I've never gotten that to work with Google.
Is the solution to educate users about creating application credentials instead?
This is the best option. It's much easier to manage and horizon provides openrc and clouds.yaml files for app creds.
Hope this helps,
Colleen
Thank you in advance,
-- Jason Anderson
Chameleon DevOps Lead *Consortium for Advanced Science and Engineering, The University of
Chicago*
*Mathematics & Computer Science Division, Argonne National Laboratory*
-- Rafael Weingärtner
-- Kristi
Keep us posted! It would be great to have this documented for future reference.
On Thu, Oct 24, 2019 at 1:04 PM Rafael Weingärtner < rafaelweingartner@gmail.com> wrote:
We are using the "access_token_endpoint". The token is retrieved nicely from the IdP. However, the issue starts on Keystone side and the Apache HTTPD mod_auth_openidc. The CLI was not ready to deal with it. It is like Horizon, when we have multiple IdPs. The discovery process happens twice, once in Horizon and another one in Keystone. We already fixed the Horizon issue, and now we are working to fix the CLI. We should have something in the next few days.
On Thu, Oct 24, 2019 at 1:29 PM Kristi Nikolla kristi@nikolla.me wrote:
Hi Rafael,
I have no experience with using multiple identity providers directly in Keystone. Does specifying the access_token_endpoint or discovery_endpoint for the specific provider you are trying to authenticate to work?
Kristi
On Wed, Oct 23, 2019 at 2:06 PM Rafael Weingärtner < rafaelweingartner@gmail.com> wrote:
Hello Colleen, Have you tested the OpenStack CLI with v3oidcpassword or v3oidcauthcode and multiple IdPs configured in Keystone?
We are currently debugging and discussing on how to enable this support in the CLI. So far, we were not able to make it work with the current code. This also happens with Horizon. If one has multiple IdPs in Keystone, the "discovery" process would happen twice, one in Horizon and another in Keystone, which is executed by the OIDC plugin in the HTTPD. We already fixed the Horizon issue, but the CLI we are still investigating, and we suspect that is probably the same problem.
On Wed, Oct 23, 2019 at 1:56 PM Colleen Murphy colleen@gazlene.net wrote:
Hi Jason,
On Mon, Oct 21, 2019, at 14:35, Jason Anderson wrote:
Hi all,
I'm in the process of prototyping a federated Keystone using OpenID Connect, which will place ephemeral users in a group that has roles
in
existing projects. I was testing how it felt from the user's perspective and am confused how I'm supposed to be able to use the openstacksdk with federation. For one thing, the RC files I can download from the "API Access" section of Horizon don't seem like
they
work; the domain is hard-coded to "Federated",
This should be fixed in the latest version of keystone...
and it also uses a username/password authentication method.
...but this is not, horizon only knows about the 'password' authentication method and can't provide RC files for other types of auth methods (unless you create an application credential).
I can see that there is a way to use KSA to use an existing OIDC token, which I think is probably the most "user-friendly" way, but
the
user still has to obtain this token themselves out-of-band, which is not trivial. Has anybody else set this up for users who liked to use the CLI?
All of KSA's auth types are supported by the openstack CLI. Which one you use depends on your OpenID Connect provider. If your provider supports it, you can use the "v3oidcpassword" auth method with the openstack CLI, following this example:
https://support.massopen.cloud/kb/faq.php?id=16
On the other hand if you are using something like Google which only supports the authorization_code grant type, then you would have to get the authorization code out of band and then use the "v3oidcauthcode" auth type, and personally I've never gotten that to work with Google.
Is the solution to educate users about creating application credentials instead?
This is the best option. It's much easier to manage and horizon provides openrc and clouds.yaml files for app creds.
Hope this helps,
Colleen
Thank you in advance,
-- Jason Anderson
Chameleon DevOps Lead *Consortium for Advanced Science and Engineering, The University of
Chicago*
*Mathematics & Computer Science Division, Argonne National Laboratory*
-- Rafael Weingärtner
-- Kristi
-- Rafael Weingärtner
Hey all, thanks for the helpful replies!
I did discover that some of my issues were fixed in Horizon Stein (I'm on Rocky still), which added support for RC file templates. Good to know about some of the client quirks that are being sorted out. One thing to point out, v3oidcpassword requires Resource Owner Password Credential grant support (grant_type=password), which not all IdPs support (for example, the one I am integrating against!)
Application credentials are an interesting feature and I'll see how it might make sense to leverage them.
Cheers!
On 10/24/19 12:21 PM, Kristi Nikolla wrote: Keep us posted! It would be great to have this documented for future reference.
On Thu, Oct 24, 2019 at 1:04 PM Rafael Weingärtner <rafaelweingartner@gmail.commailto:rafaelweingartner@gmail.com> wrote: We are using the "access_token_endpoint". The token is retrieved nicely from the IdP. However, the issue starts on Keystone side and the Apache HTTPD mod_auth_openidc. The CLI was not ready to deal with it. It is like Horizon, when we have multiple IdPs. The discovery process happens twice, once in Horizon and another one in Keystone. We already fixed the Horizon issue, and now we are working to fix the CLI. We should have something in the next few days.
On Thu, Oct 24, 2019 at 1:29 PM Kristi Nikolla <kristi@nikolla.memailto:kristi@nikolla.me> wrote: Hi Rafael,
I have no experience with using multiple identity providers directly in Keystone. Does specifying the access_token_endpoint or discovery_endpoint for the specific provider you are trying to authenticate to work?
Kristi
On Wed, Oct 23, 2019 at 2:06 PM Rafael Weingärtner <rafaelweingartner@gmail.commailto:rafaelweingartner@gmail.com> wrote: Hello Colleen, Have you tested the OpenStack CLI with v3oidcpassword or v3oidcauthcode and multiple IdPs configured in Keystone?
We are currently debugging and discussing on how to enable this support in the CLI. So far, we were not able to make it work with the current code. This also happens with Horizon. If one has multiple IdPs in Keystone, the "discovery" process would happen twice, one in Horizon and another in Keystone, which is executed by the OIDC plugin in the HTTPD. We already fixed the Horizon issue, but the CLI we are still investigating, and we suspect that is probably the same problem.
On Wed, Oct 23, 2019 at 1:56 PM Colleen Murphy <colleen@gazlene.netmailto:colleen@gazlene.net> wrote: Hi Jason,
On Mon, Oct 21, 2019, at 14:35, Jason Anderson wrote:
Hi all,
I'm in the process of prototyping a federated Keystone using OpenID Connect, which will place ephemeral users in a group that has roles in existing projects. I was testing how it felt from the user's perspective and am confused how I'm supposed to be able to use the openstacksdk with federation. For one thing, the RC files I can download from the "API Access" section of Horizon don't seem like they work; the domain is hard-coded to "Federated",
This should be fixed in the latest version of keystone...
and it also uses a username/password authentication method.
...but this is not, horizon only knows about the 'password' authentication method and can't provide RC files for other types of auth methods (unless you create an application credential).
I can see that there is a way to use KSA to use an existing OIDC token, which I think is probably the most "user-friendly" way, but the user still has to obtain this token themselves out-of-band, which is not trivial. Has anybody else set this up for users who liked to use the CLI?
All of KSA's auth types are supported by the openstack CLI. Which one you use depends on your OpenID Connect provider. If your provider supports it, you can use the "v3oidcpassword" auth method with the openstack CLI, following this example:
https://support.massopen.cloud/kb/faq.php?id=16
On the other hand if you are using something like Google which only supports the authorization_code grant type, then you would have to get the authorization code out of band and then use the "v3oidcauthcode" auth type, and personally I've never gotten that to work with Google.
Is the solution to educate users about creating application credentials instead?
This is the best option. It's much easier to manage and horizon provides openrc and clouds.yaml files for app creds.
Hope this helps,
Colleen
Thank you in advance,
-- Jason Anderson
Chameleon DevOps Lead *Consortium for Advanced Science and Engineering, The University of Chicago* *Mathematics & Computer Science Division, Argonne National Laboratory*
-- Rafael Weingärtner
-- Kristi
-- Rafael Weingärtner
-- Kristi
Jason, just watch out for another issue, which is the group assignment permissions and app credentials. As soon, as we have some updates, I will ping you guys.
On Thu, Oct 24, 2019 at 4:49 PM Jason Anderson jasonanderson@uchicago.edu wrote:
Hey all, thanks for the helpful replies!
I did discover that some of my issues were fixed in Horizon Stein (I'm on Rocky still), which added support for RC file templates. Good to know about some of the client quirks that are being sorted out. One thing to point out, v3oidcpassword requires Resource Owner Password Credential grant support (grant_type=password), which not all IdPs support (for example, the one I am integrating against!)
Application credentials are an interesting feature and I'll see how it might make sense to leverage them.
Cheers!
On 10/24/19 12:21 PM, Kristi Nikolla wrote:
Keep us posted! It would be great to have this documented for future reference.
On Thu, Oct 24, 2019 at 1:04 PM Rafael Weingärtner < rafaelweingartner@gmail.com> wrote:
We are using the "access_token_endpoint". The token is retrieved nicely from the IdP. However, the issue starts on Keystone side and the Apache HTTPD mod_auth_openidc. The CLI was not ready to deal with it. It is like Horizon, when we have multiple IdPs. The discovery process happens twice, once in Horizon and another one in Keystone. We already fixed the Horizon issue, and now we are working to fix the CLI. We should have something in the next few days.
On Thu, Oct 24, 2019 at 1:29 PM Kristi Nikolla kristi@nikolla.me wrote:
Hi Rafael,
I have no experience with using multiple identity providers directly in Keystone. Does specifying the access_token_endpoint or discovery_endpoint for the specific provider you are trying to authenticate to work?
Kristi
On Wed, Oct 23, 2019 at 2:06 PM Rafael Weingärtner < rafaelweingartner@gmail.com> wrote:
Hello Colleen, Have you tested the OpenStack CLI with v3oidcpassword or v3oidcauthcode and multiple IdPs configured in Keystone?
We are currently debugging and discussing on how to enable this support in the CLI. So far, we were not able to make it work with the current code. This also happens with Horizon. If one has multiple IdPs in Keystone, the "discovery" process would happen twice, one in Horizon and another in Keystone, which is executed by the OIDC plugin in the HTTPD. We already fixed the Horizon issue, but the CLI we are still investigating, and we suspect that is probably the same problem.
On Wed, Oct 23, 2019 at 1:56 PM Colleen Murphy colleen@gazlene.net wrote:
Hi Jason,
On Mon, Oct 21, 2019, at 14:35, Jason Anderson wrote:
Hi all,
I'm in the process of prototyping a federated Keystone using OpenID Connect, which will place ephemeral users in a group that has roles
in
existing projects. I was testing how it felt from the user's perspective and am confused how I'm supposed to be able to use the openstacksdk with federation. For one thing, the RC files I can download from the "API Access" section of Horizon don't seem like
they
work; the domain is hard-coded to "Federated",
This should be fixed in the latest version of keystone...
and it also uses a username/password authentication method.
...but this is not, horizon only knows about the 'password' authentication method and can't provide RC files for other types of auth methods (unless you create an application credential).
I can see that there is a way to use KSA to use an existing OIDC token, which I think is probably the most "user-friendly" way, but
the
user still has to obtain this token themselves out-of-band, which is not trivial. Has anybody else set this up for users who liked to use the CLI?
All of KSA's auth types are supported by the openstack CLI. Which one you use depends on your OpenID Connect provider. If your provider supports it, you can use the "v3oidcpassword" auth method with the openstack CLI, following this example:
https://support.massopen.cloud/kb/faq.php?id=16
On the other hand if you are using something like Google which only supports the authorization_code grant type, then you would have to get the authorization code out of band and then use the "v3oidcauthcode" auth type, and personally I've never gotten that to work with Google.
Is the solution to educate users about creating application credentials instead?
This is the best option. It's much easier to manage and horizon provides openrc and clouds.yaml files for app creds.
Hope this helps,
Colleen
Thank you in advance,
-- Jason Anderson
Chameleon DevOps Lead *Consortium for Advanced Science and Engineering, The University of
Chicago*
*Mathematics & Computer Science Division, Argonne National
Laboratory*
-- Rafael Weingärtner
-- Kristi
-- Rafael Weingärtner
-- Kristi
Hey guys. Here is our fix for the issue. https://review.opendev.org/#/c/692140/1
When that PR gets merged, the CLI will be able to use federated users and authenticate them via OIDCv3password
One example of configurations to use with that PR is the following:
export OS_AUTH_URL=http://keystone:35357/v3export OS_INTERFACE=internalexport OS_IDENTITY_API_VERSION=3export OS_REGION_NAME=Z1export OS_AUTH_PLUGIN=openidexport OS_AUTH_TYPE=v3oidcpasswordexport OS_IDENTITY_PROVIDER=IDPexport OS_CLIENT_ID=IDP_CLIENT_IDexport OS_CLIENT_SECRET=IDP_CLIENT_SECRETexport OS_OPENID_SCOPE="openid address email profile phone offline_access"export OS_PROTOCOL=openidexport OS_ACCESS_TOKEN_ENDPOINT=https://IDP_SERVER_NAME:PORT/openid-connect/tokenexport OS_ACCESS_TOKEN_TYPE=access_tokenexport OS_DISCOVERY_ENDPOINT=https://IDP_SERVER_NAME:PORT/.well-known/openid-configurationexport OS_PROJECT_ID=OPENSTACK_PROJECT_IDexport OS_PROJECT_NAME="OPENSTACK_PROJECT_NAME"export OS_PROJECT_DOMAIN_ID="OPENSTACK_PROJECT_DOMAIN_ID"export OS_USERNAME=federation-testexport OS_PASSWORD=federation-test-password
On Thu, Oct 24, 2019 at 5:53 PM Rafael Weingärtner < rafaelweingartner@gmail.com> wrote:
Jason, just watch out for another issue, which is the group assignment permissions and app credentials. As soon, as we have some updates, I will ping you guys.
On Thu, Oct 24, 2019 at 4:49 PM Jason Anderson jasonanderson@uchicago.edu wrote:
Hey all, thanks for the helpful replies!
I did discover that some of my issues were fixed in Horizon Stein (I'm on Rocky still), which added support for RC file templates. Good to know about some of the client quirks that are being sorted out. One thing to point out, v3oidcpassword requires Resource Owner Password Credential grant support (grant_type=password), which not all IdPs support (for example, the one I am integrating against!)
Application credentials are an interesting feature and I'll see how it might make sense to leverage them.
Cheers!
On 10/24/19 12:21 PM, Kristi Nikolla wrote:
Keep us posted! It would be great to have this documented for future reference.
On Thu, Oct 24, 2019 at 1:04 PM Rafael Weingärtner < rafaelweingartner@gmail.com> wrote:
We are using the "access_token_endpoint". The token is retrieved nicely from the IdP. However, the issue starts on Keystone side and the Apache HTTPD mod_auth_openidc. The CLI was not ready to deal with it. It is like Horizon, when we have multiple IdPs. The discovery process happens twice, once in Horizon and another one in Keystone. We already fixed the Horizon issue, and now we are working to fix the CLI. We should have something in the next few days.
On Thu, Oct 24, 2019 at 1:29 PM Kristi Nikolla kristi@nikolla.me wrote:
Hi Rafael,
I have no experience with using multiple identity providers directly in Keystone. Does specifying the access_token_endpoint or discovery_endpoint for the specific provider you are trying to authenticate to work?
Kristi
On Wed, Oct 23, 2019 at 2:06 PM Rafael Weingärtner < rafaelweingartner@gmail.com> wrote:
Hello Colleen, Have you tested the OpenStack CLI with v3oidcpassword or v3oidcauthcode and multiple IdPs configured in Keystone?
We are currently debugging and discussing on how to enable this support in the CLI. So far, we were not able to make it work with the current code. This also happens with Horizon. If one has multiple IdPs in Keystone, the "discovery" process would happen twice, one in Horizon and another in Keystone, which is executed by the OIDC plugin in the HTTPD. We already fixed the Horizon issue, but the CLI we are still investigating, and we suspect that is probably the same problem.
On Wed, Oct 23, 2019 at 1:56 PM Colleen Murphy colleen@gazlene.net wrote:
Hi Jason,
On Mon, Oct 21, 2019, at 14:35, Jason Anderson wrote: > Hi all, > > I'm in the process of prototyping a federated Keystone using OpenID > Connect, which will place ephemeral users in a group that has roles in > existing projects. I was testing how it felt from the user's > perspective and am confused how I'm supposed to be able to use the > openstacksdk with federation. For one thing, the RC files I can > download from the "API Access" section of Horizon don't seem like they > work; the domain is hard-coded to "Federated",
This should be fixed in the latest version of keystone...
> and it also uses a > username/password authentication method.
...but this is not, horizon only knows about the 'password' authentication method and can't provide RC files for other types of auth methods (unless you create an application credential).
> > I can see that there is a way to use KSA to use an existing OIDC > token, which I think is probably the most "user-friendly" way, but the > user still has to obtain this token themselves out-of-band, which is > not trivial. Has anybody else set this up for users who liked to use > the CLI?
All of KSA's auth types are supported by the openstack CLI. Which one you use depends on your OpenID Connect provider. If your provider supports it, you can use the "v3oidcpassword" auth method with the openstack CLI, following this example:
https://support.massopen.cloud/kb/faq.php?id=16
On the other hand if you are using something like Google which only supports the authorization_code grant type, then you would have to get the authorization code out of band and then use the "v3oidcauthcode" auth type, and personally I've never gotten that to work with Google.
> Is the solution to educate users about creating application > credentials instead?
This is the best option. It's much easier to manage and horizon provides openrc and clouds.yaml files for app creds.
Hope this helps,
Colleen
> > Thank you in advance, > > -- > Jason Anderson > > Chameleon DevOps Lead > *Consortium for Advanced Science and Engineering, The University of Chicago* > *Mathematics & Computer Science Division, Argonne National Laboratory*
-- Rafael Weingärtner
-- Kristi
-- Rafael Weingärtner
-- Kristi
-- Rafael Weingärtner
participants (4)
-
Colleen Murphy
-
Jason Anderson
-
Kristi Nikolla
-
Rafael Weingärtner