[Kubernetes] Workspace creation fails when using alternate OIDC provider

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]

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

[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.