Partner-level SSO + login page branding for self-hosted MSP deployments

[win-wxx]

Problem

We run a self-hosted Breeze deployment (v0.88.0, Docker Compose, on-prem)

Current SSO (/api/v1/sso/*) is fully org-scoped: every provider requires an org_id, defaultRoleId must resolve to an org-scoped role, and /sso/check/:orgId needs an orgId just to know whether to show a login button. This works for end-customers logging into their own org, but there's no way for our own internal team (20 technicians) to SSO into the Partner-level dashboard with orgAccess: all — which is what we actually need day to day.

We noticed partners.ssoConfig (jsonb) is documented as a field but has no endpoint, no login flow, and isn't referenced anywhere in the SSO reference doc — looks like a placeholder rather than something wired up end-to-end.

Related: because SSO buttons only resolve per-org, the top-level login page has no way to show partner branding or a partner SSO entry point before the user's org is known. It also hardcodes generic marketing copy ("10,000+ endpoints" etc.), which reads oddly on a single-partner self-hosted instance.

Proposed Solution

A partner-scoped SSO provider + login entry point (e.g. /sso/partner-login/:partnerId) that accepts partner-scoped roles (Partner Admin/Technician/etc.) as the default role instead of requiring an org-scoped role.

Same safety model as org SSO: testing > active status, break-glass password login preserved unless explicitly enforced.

A basic partner_branding config (logo, accent color, headline override, optional /login/:partnerSlug) so the login page can reflect the partner and surface the partner SSO button.

Alternatives Considered

No response

Component

Web Dashboard

Scope

Medium (new feature within existing module)

[ToddHebebrand]

Acknowledged — and your read of the code is right. partners.ssoConfig exists in the schema (apps/api/src/db/schema/orgs.ts) and is persisted through the partner routes, but nothing reads it back for authentication — there is no partner login flow and no /sso/partner-* endpoint surface. It is storage-only today; all live SSO is org-scoped exactly as you described, including defaultRoleId requiring an org-scoped role and /sso/check/:orgId needing an org up front.

On the proposal: a partner-scoped provider + login entry point that accepts partner-scoped roles as the default, with the same testing-before-active gate and preserved break-glass password login, is the right outline — that safety model is non-negotiable and your spec keeps it. Partner login-page branding (logo/accent/headline + optional /login/:partnerSlug) fits naturally alongside it, and the hardcoded marketing copy on a self-hosted single-partner instance is a fair complaint on its own.

Because this is authentication architecture (token scope, role resolution, and tenant isolation all participate), we're going to design it deliberately rather than bolt it on — it's accepted and on the roadmap rather than a quick fix. Updates will land here.

[ToddHebebrand]

Built — PR #2194 is open with the full partner-scope SSO + login branding implementation. The design followed your outline closely: partner-axis providers on the existing sso_providers model (dual-ownership, org_id XOR partner_id), GET /sso/login/partner/:partnerId as the login entry, partner-scoped roles as the provider default, the same testing→active safety gate, and break-glass password login preserved unless enforceSSO is explicitly set on an active provider. Login branding shipped as partner_login_branding (logo, accent color, headline) — on a single-partner instance like yours, the login page picks it up automatically via a new public login-context endpoint and drops the hardcoded marketing copy, with a "Sign in with {provider}" button when a partner provider is active.

Two v1 decisions worth knowing before you test:

• Identity-first, no JIT: partner SSO logs in users who already exist in Breeze. Your ~20 techs keep their accounts; since they hold passwords, first SSO use goes through a self-service Connect SSO step (Profile → Security) — an authenticated, MFA-gated round-trip that links their IdP identity, after which SSO login (and enforceSSO, if you enable it) works normally. Auto-provisioning from the IdP is a deliberate later phase.
• ssoConfig jsonb is retired, exactly as you suspected in the report — partner SSO lives in real provider rows with the same admin surface as org SSO (create with an ownership scope selector).

Your report also indirectly uncovered a pre-existing production bug: the real-database test suite added for this work showed the org SSO flow has been silently broken under row-level security on production-shaped deployments (the callback failed for every provider). PR #2194 fixes the callback path for both axes; the remaining org-side initiation/check routes are tracked in #2195.

PR #2194 will land after CI + final checks; it'll be in the next release after that, with self-hoster notes in the release body (one auto-applied migration, no env changes). Would appreciate your verification on v0.90+ once it ships.

Refs #2183, #2195.