Skip to content

fix: seed tenant for SSO auth types (OKTA/KEYCLOAK/AZUREAD) on fresh database#6247

Open
ahbeigi wants to merge 2 commits intokeephq:mainfrom
ahbeigi:fix/sso-tenant-seeding-on-fresh-db
Open

fix: seed tenant for SSO auth types (OKTA/KEYCLOAK/AZUREAD) on fresh database#6247
ahbeigi wants to merge 2 commits intokeephq:mainfrom
ahbeigi:fix/sso-tenant-seeding-on-fresh-db

Conversation

@ahbeigi
Copy link
Copy Markdown

@ahbeigi ahbeigi commented Apr 14, 2026

on_starting() skipped try_create_single_tenant() for OKTA, KEYCLOAK, and AZUREAD auth types because they were missing from the allowlist. On a fresh database this leaves the tenant table empty, causing an infinite redirect loop after successful SSO login.

Add all three to the allowlist and to excluded_from_default_user (SSO types delegate auth to the IdP so no local user is needed).

try_create_single_tenant() is already idempotent, so existing deployments are unaffected.

Closes #6246

📑 Description

When AUTH_TYPE is set to OKTA, KEYCLOAK, or AZUREAD and the database is fresh (new PG cluster, PVC recreated, etc.), on_starting() in keep/api/config.py never calls try_create_single_tenant() because these auth types are missing from the allowlist. The tenant table stays empty, and authenticated users hit an infinite redirect loop between /signin and /incidents.

This PR adds the three missing auth types to the allowlist and to excluded_from_default_user so the tenant row is seeded on startup without creating a local default user (SSO delegates auth to the IdP).

Note: AZUREAD has no IdentityManagerTypes enum entry (it is enterprise-only under ee/ and loaded dynamically), so the raw string "azuread" is used.

  • Add OKTA, KEYCLOAK, "azuread" to auth-type allowlist
  • Add OKTA, KEYCLOAK, "azuread" to excluded_from_default_user

✅ Checks

  • My pull request adheres to the code style of this project
  • My code requires changes to the documentation
  • I have updated the documentation as required
  • All the tests have passed

ℹ Additional Information

The bug went unnoticed because the PVC normally persists across redeployments — the tenant row created during initial setup survives indefinitely. It only surfaces on a fresh database bootstrap.

Workaround for anyone on older versions: add an idempotent INSERT INTO tenant (id, name) VALUES ('keep', 'Single Tenant') ON CONFLICT (id) DO NOTHING; to the backend init container.

…database

on_starting() skipped try_create_single_tenant() for OKTA, KEYCLOAK, and
AZUREAD auth types because they were missing from the allowlist. On a fresh
database this leaves the tenant table empty, causing an infinite redirect
loop after successful SSO login.

Add all three to the allowlist and to excluded_from_default_user (SSO types
delegate auth to the IdP so no local user is needed).

try_create_single_tenant() is already idempotent, so existing deployments
are unaffected.
@cursor
Copy link
Copy Markdown

cursor bot commented Apr 14, 2026

You have used all of your free Bugbot PR reviews.

To receive reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.

@dosubot dosubot bot added size:XS This PR changes 0-9 lines, ignoring generated files. Bug Something isn't working labels Apr 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Bug Something isn't working size:XS This PR changes 0-9 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[🐛 Bug]: AUTH_TYPE=OKTA/KEYCLOAK/AZUREAD skips tenant seeding on fresh database → infinite redirect loop

2 participants