[Kubernetes] Workspace creation fails when using alternate OIDC provider

[johnmcollier]

Description

I've set up Eclipse Che (latest) on IBM Cloud Private (ICP), using its OIDC provider instead of Keycloak. When I log in to the dashboard and go to create a Che 7 workspace, I am presented with the following error:

Error: Failed to get the workspace: "Workspace with name '//mycluster.icp:9443/oidc/endpoint/OP:<email>@ibm.com/wksp-y8yn' in namespace 'https' doesn't exist"

Which seems to be coming from this function: https://github.com/eclipse/che/blob/master/ide/che-ide-gwt-app/src/main/resources/org/eclipse/che/ide/public/IDE.html#L175

The URL in my browser looks like: https://che-che.<IP>.nip.io/dashboard/#/ide/https://mycluster.icp:9443/oidc/endpoint/OP:<email>@ibm.com/wksp-y8yn, which seems to be the issue here. Che seems to think the workspace name is mycluster.icp:9443/oidc/endpoint/OP:<email>@ibm.com/wksp-y8yn instead of wksp-y8yn

Note: I've redacted both <IP> and <email> here

As to where Che is getting that link from, in my OpenID configuration, it lists that link as the issuer:

issuer:  "https://mycluster.icp:9443/oidc/endpoint/OP"

And lastly, if I reload the Che dashboard, it now shows the workspace name as mycluster.icp:9443/oidc/endpoint/OP:<email>@ibm.com/wksp-y8yn instead of wksp-y8yn:

Edit:
What's interesting is that if I try to create a workspace from a Devfile, it gets farther along in the creation process, failing due to a separate issue (secret <workspaceid>-che-self-signed-cert> is missing).

[johnmcollier]

I've attached a screenshot with the Javascript Console output from Chrome:

[ghost]

@johnmcollier I think it is related to single host ingress strategy.

What's interesting is that if I try to create a workspace from a Devfile, it gets farther along in the creation process, failing due to a separate issue (secret -che-self-signed-cert> is missing).

That's a known issue.

[johnmcollier]

@eivantsov I'm running on multi-host strategy. I looked into it a little further, and found this line https://github.com/eclipse/che/blob/315767ea5d76703d4aeacb163bdcc3af689b71eb/multiuser/keycloak/che-multiuser-keycloak-server/src/main/java/org/eclipse/che/multiuser/keycloak/server/KeycloakEnvironmentInitalizationFilter.java#L102, which seemed to be the issue.

Che wasn't able to retrieve username, so it was using the <issuer>:<subject> instead: https://mycluster.icp:9443/oidc/endpoint/OP:<email>@ibm.com, which Che was rejecting. If I changed it to just use the subject (so <email>@ibm.com), the error goes away.

username = claims.getSubject();

And thanks, #12634 is indeed the other issue I'm running into.

[tetchel]

To add on to what John said above, I don't see why the issuer would be used here - it will always be an HTTPS URL (spec):

Issuer Identifier
Verifiable Identifier for an Issuer. An Issuer Identifier is a case sensitive URL using the https scheme that contains scheme, host, and optionally, port number and path components and no query or fragment components.

Likely Che wants to use the tuple of [issuer, subject] to identify users uniquely in case there is a case where there are multiple issuers that have matching subjects (spec), but there has to be a better way.

[johnmcollier]

What about computing a UUID or hash (say sha256 maybe?) of <issuer>:<subject> instead if we can't retrieve the username? It would be almost certainly unique and wouldn't have the issues that something like <issuer>:<subject> would have

[mshaposhnik]

I think we can accept this in an PR form :) @davidfestal WDYT?

[davidfestal]

@mshaposhnik @johnmcollier I assume that might be an acceptable solution for the (somewhat strange) case when no user name can be found in any of the JWT token claims.

However, in the case the user name is still provided in your JWT tokens, did you try to use the che.keycloak.username_claim property in order to retrieve the user name from the claim that is used for it in your OIDC provider ?

Here is the definition of this property:

#     Username claim to be used as user display name
#     when parsing JWT token
#     if not defined the fallback value is 'preferred_username'
che.keycloak.username_claim=NULL

[johnmcollier]

@davidfestal @mshaposhnik Sorry, meant to respond to this earlier and forgot.

Setting che.keycloak.username_claim to the sub worked for me, and a code change in Che wasn't required, so I can close this out.