starred/cloudbeaver

Fork 0

mirror of https://github.com/dbeaver/cloudbeaver.git synced 2026-04-25 05:36:14 +03:00

[GH-ISSUE #3666] CloudBeaver behind oauth2-proxy does not recognize SSO #1299

New issue

Open

opened 2026-03-07 21:02:11 +03:00 by kerem · 2 comments

kerem commented

2026-03-07 21:02:11 +03:00

Owner

Originally created by @sathwick-p on GitHub (Aug 18, 2025).
Original GitHub issue: https://github.com/dbeaver/cloudbeaver/issues/3666

CloudBeaver behind oauth2-proxy does not recognize SSO; shows local login or “Please configure authentication methods” after removing local provider

Environment

CloudBeaver CE container: dbeaver/cloudbeaver:25.1
CloudBeaver server reports: CloudBeaver CE Server 25.1.4.202508041622
Kubernetes (AWS ALB/ELB in front)
oauth2-proxy Helm chart: oauth2-proxy 7.11.0 (OIDC with Microsoft Entra)
Ingress routes app traffic to oauth2-proxy; upstream is the CloudBeaver Service (port 80)

CloudBeaver deployment (Kubernetes)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cloudbeaver
  namespace: cloudbeaver
spec:
  replicas: 1
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: cloudbeaver
  template:
    metadata:
      labels:
        app: cloudbeaver
    spec:
      serviceAccountName: cloudbeaver-sa
      containers:
      - name: cloudbeaver
        image: dbeaver/cloudbeaver:25.1
        ports:
        - containerPort: 8978
        env:
        - name: CB_SERVER_URL
          value: "https://cloudbeaver.<domain>.io"
        - name: CB_DISABLE_FORCE_HTTPS
          value: "true"
        volumeMounts:
        - name: cloudbeaver-data
          mountPath: /opt/cloudbeaver/workspace
      volumes:
      - name: cloudbeaver-data
        persistentVolumeClaim:
          claimName: cloudbeaver-workspace

oauth2-proxy configuration (key args)

--provider=oidc
--oidc-issuer-url=https://login.microsoftonline.com/<tenant>/v2.0
--redirect-url=https://cloudbeaver-qa.<domain>.io/oauth2/callback
--scope=openid profile email
--user-id-claim=email
--prefer-email-to-user=true
--pass-user-headers=true
--set-xauthrequest=true
--oidc-groups-claim=roles
--allowed-group=Administrators
--allowed-group=Developers
--reverse-proxy=true
--cookie-secure=true
--cookie-samesite=none
--cookie-expire=8h
--cookie-refresh=1h
--cookie-domain=cloudbeaver-qa.<domain>.io
--upstream=http://cloudbeaver.cloudbeaver.svc.cluster.local:80/

CloudBeaver configuration notes

Base config file in container: /opt/cloudbeaver/conf/cloudbeaver.conf
Runtime file path (as logged by server): /opt/cloudbeaver/workspace/.data/.cloudbeaver.runtime.conf

Representative base config excerpts (as seen inside the pod):

app: {
    anonymousAccessEnabled: "${CLOUDBEAVER_APP_ANONYMOUS_ACCESS_ENABLED:true}",
    enabledAuthProviders: [
        "local"
    ]
}

There is also a repository JSON with reverse proxy provider configuration (values/us/cloudbeaver.runtime.conf.json) that includes:

"enableReverseProxyAuth": true,
"enabledAuthProviders": ["local", "reverseProxy"],
"authConfigurations": [
  {
    "id": "oauth2-proxy",
    "provider": "reverseProxy",
    "parameters": {
      "logout-url": "https://cloudbeaver-qa.<domain>.io/oauth2/sign_out",
      "user-header": "X-Forwarded-User",
      "team-header": "X-Forwarded-Groups"
    }
  }
]

Steps to reproduce

Deploy CloudBeaver behind oauth2-proxy with the configuration above.
Access https://cloudbeaver-qa.<domain>.io.
Attempt to sign in via SSO.
Observed two behaviors across attempts/changes:
- Initially: CloudBeaver shows the local login form and proceeds with local auth.
- After enabling reverse proxy and saving once setup is done and trying to log back in via oauth2-proxy it takes me to the local login page and not via SSO

Expected behavior

After successful OIDC authentication at oauth2-proxy, CloudBeaver should recognize the forwarded auth headers and log the user into CloudBeaver using the reverse proxy provider, without showing the local login form or the “configure authentication methods” screen.

Actual behavior

When local provider is enabled: CloudBeaver falls back to local login and creates/uses a local user.
When local provider is removed: CloudBeaver shows “Please configure authentication methods” and does not proceed with SSO.

Relevant logs

CloudBeaver (startup and requests):

Initialize web platform...
CloudBeaver CE Server 25.1.4.202508041622 is starting
Global access server URL: https://cloudbeaver-qa.<domain>.io
Runtime configuration [/opt/cloudbeaver/workspace/.data/.cloudbeaver.runtime.conf]
...
API > openSession [user: null, sessionId: null]
API > getActiveUser [user: null, sessionId: null]
API > getAuthProviders [user: null, sessionId: null]
...
API > authLogin [user: null, sessionId: null]
refresh permissions admin@qa 336dfbdb-8f4f-4608-8207-74acfa3ce458
Project created: [ID=u_admin@qa, Name=admin@qa, Type=USER, Creator=null]

oauth2-proxy:

[oauthproxy.go:1026] No valid authentication in request. Initiating login.   # prior to login (expected)
[AuthSuccess] Authenticated via OAuth2: Session{email:sathwick.p@<domain>.com ... groups:[Administrators]}
GET "/" 200
POST "/api/gql" 200
[session_store.go:170] WARNING: Multiple cookies are required for this session as it exceeds the 4kb cookie limit.
ELB health checks to "/oauth2/health" return 403 (observed)

Additional context

Ingress points cloudbeaver-qa.<domain>.io to the oauth2-proxy Service; oauth2-proxy upstream is the CloudBeaver Service on port 80.
After removing the local provider from CloudBeaver, the UI displays: “Authentication — Please configure authentication methods.”
I followed the same steps to enable SSO, and it was working fine until a few days ago. However, after the CloudBeaver pod restarted, authentication stopped working through SSO and now it always redirects me to the local login page. I’ve already reverted changes and tried a few troubleshooting steps, but it still isn’t working as expected. Any help would be appreciated.

Originally created by @sathwick-p on GitHub (Aug 18, 2025). Original GitHub issue: https://github.com/dbeaver/cloudbeaver/issues/3666 CloudBeaver behind oauth2-proxy does not recognize SSO; shows local login or “Please configure authentication methods” after removing local provider ### Environment - CloudBeaver CE container: `dbeaver/cloudbeaver:25.1` CloudBeaver server reports: `CloudBeaver CE Server 25.1.4.202508041622` - Kubernetes (AWS ALB/ELB in front) - oauth2-proxy Helm chart: `oauth2-proxy 7.11.0` (OIDC with Microsoft Entra) - Ingress routes app traffic to `oauth2-proxy`; upstream is the CloudBeaver Service (port 80) ### CloudBeaver deployment (Kubernetes) ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: cloudbeaver namespace: cloudbeaver spec: replicas: 1 strategy: type: Recreate selector: matchLabels: app: cloudbeaver template: metadata: labels: app: cloudbeaver spec: serviceAccountName: cloudbeaver-sa containers: - name: cloudbeaver image: dbeaver/cloudbeaver:25.1 ports: - containerPort: 8978 env: - name: CB_SERVER_URL value: "https://cloudbeaver.<domain>.io" - name: CB_DISABLE_FORCE_HTTPS value: "true" volumeMounts: - name: cloudbeaver-data mountPath: /opt/cloudbeaver/workspace volumes: - name: cloudbeaver-data persistentVolumeClaim: claimName: cloudbeaver-workspace ``` ### oauth2-proxy configuration (key args) ```text --provider=oidc --oidc-issuer-url=https://login.microsoftonline.com/<tenant>/v2.0 --redirect-url=https://cloudbeaver-qa.<domain>.io/oauth2/callback --scope=openid profile email --user-id-claim=email --prefer-email-to-user=true --pass-user-headers=true --set-xauthrequest=true --oidc-groups-claim=roles --allowed-group=Administrators --allowed-group=Developers --reverse-proxy=true --cookie-secure=true --cookie-samesite=none --cookie-expire=8h --cookie-refresh=1h --cookie-domain=cloudbeaver-qa.<domain>.io --upstream=http://cloudbeaver.cloudbeaver.svc.cluster.local:80/ ``` ### CloudBeaver configuration notes - Base config file in container: `/opt/cloudbeaver/conf/cloudbeaver.conf` - Runtime file path (as logged by server): `/opt/cloudbeaver/workspace/.data/.cloudbeaver.runtime.conf` Representative base config excerpts (as seen inside the pod): ```text app: { anonymousAccessEnabled: "${CLOUDBEAVER_APP_ANONYMOUS_ACCESS_ENABLED:true}", enabledAuthProviders: [ "local" ] } ``` There is also a repository JSON with reverse proxy provider configuration (`values/us/cloudbeaver.runtime.conf.json`) that includes: ```json "enableReverseProxyAuth": true, "enabledAuthProviders": ["local", "reverseProxy"], "authConfigurations": [ { "id": "oauth2-proxy", "provider": "reverseProxy", "parameters": { "logout-url": "https://cloudbeaver-qa.<domain>.io/oauth2/sign_out", "user-header": "X-Forwarded-User", "team-header": "X-Forwarded-Groups" } } ] ``` ### Steps to reproduce 1. Deploy CloudBeaver behind oauth2-proxy with the configuration above. 2. Access `https://cloudbeaver-qa.<domain>.io`. 3. Attempt to sign in via SSO. 4. Observed two behaviors across attempts/changes: - Initially: CloudBeaver shows the local login form and proceeds with local auth. - After enabling reverse proxy and saving once setup is done and trying to log back in via oauth2-proxy it takes me to the local login page and not via SSO ### Expected behavior After successful OIDC authentication at oauth2-proxy, CloudBeaver should recognize the forwarded auth headers and log the user into CloudBeaver using the reverse proxy provider, without showing the local login form or the “configure authentication methods” screen. ### Actual behavior - When local provider is enabled: CloudBeaver falls back to local login and creates/uses a local user. - When local provider is removed: CloudBeaver shows “Please configure authentication methods” and does not proceed with SSO. ### Relevant logs CloudBeaver (startup and requests): ```text Initialize web platform... CloudBeaver CE Server 25.1.4.202508041622 is starting Global access server URL: https://cloudbeaver-qa.<domain>.io Runtime configuration [/opt/cloudbeaver/workspace/.data/.cloudbeaver.runtime.conf] ... API > openSession [user: null, sessionId: null] API > getActiveUser [user: null, sessionId: null] API > getAuthProviders [user: null, sessionId: null] ... API > authLogin [user: null, sessionId: null] refresh permissions admin@qa 336dfbdb-8f4f-4608-8207-74acfa3ce458 Project created: [ID=u_admin@qa, Name=admin@qa, Type=USER, Creator=null] ``` oauth2-proxy: ```text [oauthproxy.go:1026] No valid authentication in request. Initiating login. # prior to login (expected) [AuthSuccess] Authenticated via OAuth2: Session{email:sathwick.p@<domain>.com ... groups:[Administrators]} GET "/" 200 POST "/api/gql" 200 [session_store.go:170] WARNING: Multiple cookies are required for this session as it exceeds the 4kb cookie limit. ELB health checks to "/oauth2/health" return 403 (observed) ``` ### Additional context - Ingress points `cloudbeaver-qa.<domain>.io` to the `oauth2-proxy` Service; oauth2-proxy upstream is the CloudBeaver Service on port 80. - After removing the `local` provider from CloudBeaver, the UI displays: “Authentication — Please configure authentication methods.” - I followed the same steps to enable SSO, and it was working fine until a few days ago. However, after the CloudBeaver pod restarted, authentication stopped working through SSO and now it always redirects me to the local login page. I’ve already reverted changes and tried a few troubleshooting steps, but it still isn’t working as expected. Any help would be appreciated.

kerem added the

xf:authentication

wait for review

labels

2026-03-07 21:02:11 +03:00

kerem commented

2026-03-07 21:02:13 +03:00

Author

Owner

@EvgeniaBzzz commented on GitHub (Aug 18, 2025):

Could you please verify that /opt/cloudbeaver/workspace/.data/.cloudbeaver.runtime.conf actually contains the values from values/us/cloudbeaver.runtime.conf.json after the pod has restarted (i.e. that it is still properly mounted/applied)?

“Please configure authentication methods” is expected for now when the local provider is disabled (as proxy doesn't have ui tab). You won’t see it once the proxy is working.

@EvgeniaBzzz commented on GitHub (Aug 18, 2025): Could you please verify that `/opt/cloudbeaver/workspace/.data/.cloudbeaver.runtime.conf` actually contains the values from `values/us/cloudbeaver.runtime.conf.json` after the pod has restarted (i.e. that it is still properly mounted/applied)? “Please configure authentication methods” is expected for now when the local provider is disabled (as proxy doesn't have ui tab). You won’t see it once the proxy is working.

kerem commented

2026-03-07 21:02:13 +03:00

Author

Owner

@sathwick-p commented on GitHub (Aug 18, 2025):

@EvgeniaBzzz I restarted the pods and can confirm that the same configuration was still present at /opt/cloudbeaver/workspace/.data/.cloudbeaver.runtime.conf after the restart. I’m currently using EBS as a PVC for storage.

Could you clarify how the authentication flow works? Does it first attempt an SSO connection and then fall back to local login if that fails? If so, is there a way to confirm that this fallback is happening, or do you think something else might be causing the issue?

@sathwick-p commented on GitHub (Aug 18, 2025): @EvgeniaBzzz I restarted the pods and can confirm that the same configuration was still present at `/opt/cloudbeaver/workspace/.data/.cloudbeaver.runtime.conf` after the restart. I’m currently using EBS as a PVC for storage. Could you clarify how the authentication flow works? Does it first attempt an SSO connection and then fall back to local login if that fails? If so, is there a way to confirm that this fallback is happening, or do you think something else might be causing the issue?

kerem referenced this issue

2026-03-07 21:08:43 +03:00

[PR #1299] [MERGED] unexpected error in update session #2391