F-024 S5b: one-provider SSO-only mode and safe account migration
Maintainers usually reply within 1 day
Assessment
This issue has not been assessed yet.
Description
Outcome
One self-hosted installation uses one operator-configured OIDC provider. Ordinary authentication is password-only without active SSO, or SSO-only when it is enabled. Safely move existing Flux accounts to that provider without losing their identity/data or creating a second ordinary login path.
Part of #273 / F-024. Required in v0.1. Superseding founder direction from Hubert's supervising session, 2026-10-07, recorded in #360. This replaces optional mixed password/SSO mode and removes the old #316 recent-auth dependency. S1/S4/S2/S5a/S3 and their existing authority/standing/offboarding gates remain.
Acceptance criteria
- AC-1 — One provider, exclusive ordinary mode. Keep one active provider per installation. Enforce password-only without active SSO and SSO-only with it at the server and UI. With active SSO, reject ordinary password sign-in/signup/reset and password-only session/authority continuation; hiding a form is insufficient. New SSO accounts come through the verified IdP flow. Retain scoped managed-account/operator recovery safeguards, without an ordinary password fallback or simultaneous provider selector/list.
- AC-2 — Explicit existing-account migration before cutover. In the prepared-provider migration phase, the explicitly authenticated owner completes a verified provider round trip bound to the same Flux account/session and intent before SSO-only activation. Preserve account ID, data, memberships and applicable grants; reject provider identities held by another account, identity substitution and automatic email matching. Activation must not silently lock out required accounts; document and test the audited operator recovery route for accounts that cannot be converted normally. An authoritative identity cannot be removed to evade offboarding and the last usable identity cannot be removed. No #316 ten-minute/password/step-up requirement. Compose the link-first collision guidance from #313; claiming an unverified email never transfers its old data.
- AC-3 — Provider claims and audited recovery. Retain verified OIDC defaults and required Entra/Google claim adapters for the one chosen provider. Compatibility profiles are not concurrent providers or people-profile pages. Operator re-key recovery preserves Flux identity/history, audits old/new issuer+subject and revokes old MCP authority. A recovery tool does not become ordinary password login while SSO is active. Real-provider support stays unverified until corresponding integration evidence; mocks alone do not establish Entra/Google compatibility.
- AC-4 — Evidence. Docker Keycloak, scripted MCP/client and mock-provider negative controls prove exclusive mode at UI/API/session boundaries, old password-account migration, identity collisions/substitution, refused email auto-linking, preserved data/rights, cutover/lockout handling, offboarding, authority revocation, audited recovery and relevant verified claims. Preserve the remaining accepted S5b tests, replacing only simultaneous-provider scenarios with separate single-provider configuration runs. Independent evaluation pins the final head.
Owner: @PelikanFix16. Independent GitHub evaluator: @Zamojski5. Dependencies: #310/S1 and #313/S5a account-safety interfaces; #311/#312 standing/offboarding interfaces where applicable. #316 now controls MCP capabilities and is not a linking reauthentication dependency. All application/toolchain/services/tests run in Docker. Canonical contract: MCP identity S5b, synchronized through #360 / PR #361. No implementation completion is claimed.
- Dominant language
- TypeScript
- Stars
- 3
- Forks
- 0
- Avg merge
- 13h 27m
- Merged PRs (30d)
- 224
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from ColdPhase/flux
-
good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 1 day
-
good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
WebKit: cancelled API requests surface as uncaught 'access control checks' page errorsPossibly taken @Zamojski5 claimed this today. Open
ColdPhase/flux#471 · 1 assignee ·
Maintainers usually reply within 1 day
Similar issues
-
area/frontend area/v2 kind/bug priority/needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
kubeflow/notebooks#1498 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
P1
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
SuruchBoss/Cwork#90 ·
-
bug cli service
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
521xueweihan/HelloGitHub#3922 ·