Private GitLab repositories: OAuth2 flow fails in devworkspace mode (without Keycloak)

[nils-mosbach]

Describe the bug

Trying to start workspaces from private GitLab repo fails with the following message:

It seems that the token that was passed by GitLab isn't used`.

As expected authentication is triggered after https://che.company.dev/api/factory/resolver/ fails. Following the OAuth flow:

• Che dashboard will call https://che.company.dev/api/oauth/authenticate?oauth_provider=gitlab&scope...
• which redirects to https://git.company.dev/oauth/authorize?client_id=a6.
• That seems to work as well and gitlab redirects to https://che.company.dev/api/oauth/callback?code=....

Browser console shows the following output.

As a result an empty secret workspace-credentials-secret is created in the users namespace. Dex is configured using GitLab for Kubernetes native auth.

Based on the configuration and OAuth flow, that looks good. Am I missing something?

Che version

next (development version)

Steps to reproduce

Che authentication

We've deployed dex and configured the kube api server as well as Che's authentication to use it. That works as expected.

# Dex config
config:
  issuer: https://dex.company.dev
  oauth2:
    responseTypes: ["code", "token", "id_token"]
    skipApprovalScreen: true
  staticClients:
    - id: kubernetes
      name: Kubernetes native auth
      redirectURIs:
        - https://che.company.dev/api/oauth/callback
        - https://che.company.dev/oauth/callback
        - https://che.company.dev/api/oauth/callback
      secret: 798
  connectors:
    - type: gitlab
      id: gitlab
      name: GitLab
      config:
        baseURL: https://git.company.dev
        clientID: c1d
        clientSecret: b07
        redirectURI: https://dex.company.dev/callback
        useLoginAsID: false

# Che Config
spec:
  server:
    customCheProperties:
      CHE_INTEGRATION_GITLAB_SERVER__ENDPOINTS: "https://git.company.dev/"
      CHE_OIDC_USERNAME__CLAIM: email
  auth:
    externalIdentityProvider: true
    openShiftoAuth: false
    identityProviderURL: 'https://dex.company.dev'
    oAuthClientName: kubernetes
    oAuthSecret: 798

GitLab OAuth2 integration

As described by https://www.eclipse.org/che/docs/next/administration-guide/configuring-authorization/#configuring-gitlab-oauth2-with-devworkspace-engine_che, we've created a new application in GitLab Che and created a secret

# Gitlab OAuth Secret
kind: Secret
apiVersion: v1
metadata:
  name: gitlab-oauth-config
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: oauth-scm-configuration
  annotations:
    che.eclipse.org/oauth-scm-server: gitlab
    che.eclipse.org/scm-server-endpoint: http://git.company.dev
type: Opaque
data:
  id: <base64_encoded_GitLab_Application_ID>
  secret: <base64_encoded_GitLab_Secret>

From what I understand Che/Kubernetes-auth is independent from GitLab-auth that's being used for pulling projects, right? Just in case CHE_OIDC_USERNAME__CLAIM: email shouldn't cause issues, right?
We're using trusted SSL certs.

Expected behavior

Devfile should be retrieved from private GitLab repository using requested OAuth token.

Runtime

Kubernetes (vanilla)

Screenshots

No response

Installation method

chectl/next

Environment

Linux

Eclipse Che Logs

Che Server/ Dashboard don't show any logs.

Additional context

#20831 On prem private Gitlab repositores support with OAuth2 flow (without Keycloak)

[l0rd]

Related to #20583

[nils-mosbach]

Looking at the OAuth flow, what should be the preferred outcome?

Is Che Server responsible for creating the users git credentials secret?

[l0rd]

Looking at the OAuth flow, what should be the preferred outcome?

Is Che Server responsible for creating the users git credentials secret?

Correct. The secret is then used in the workspace for cloning the repository.
The che-server is also responsible for grabbing the devfile.yaml from the private Git repository and passing it to the dashaboard that will use it to create the workspace definition (the DevWorkspace).

[nils-mosbach]

Issue seems to be resolved in todays che-server:next image. The only difference I can see is an upgrade from java 11.0.14.0.9 to 11.0.14.1+1. There was some minor work on the HttpClient in this release (https://bugs.openjdk.java.net/browse/JDK-8218546). Maybe that solved it, not sure.

git-credentials-secret-*** and devworkspace-merged-git-credentials are now created. Cloning private projects work.

Closing this issue...