[Question]: SSO - should the default admin be excluded from password sync

[RafPe]

Question

Looks like with recent changes we can enable a complete sync of SSO which also included the default admin - as this is not the best practice is there a room for us to amend the setup so there is always last option to access the system without external dependencies ?

Context

Security: exclude the default/break-glass admin from SSO by default (no auto-link, JIT, or role-sync) and guarantee its password login

Summary

The built-in administrator account (the seeded admin / super_admin) should be treated as a local, break-glass account that is out of scope for SSO by default. It must not be auto-linked to an IdP identity, must not have its roles driven by IdP claims, and must always retain password login — unless an operator explicitly opts in to managing the admin via SSO. Today this is only partially enforced.

Current behaviour (what the code does now)

• Role demotion is blocked, but only for roles. syncMappedRoles skips role sync entirely when the user already holds super_admin (packages/server/src/rbac/sso/service.ts, "Skipping role sync for super_admin user"). Good — IdP group claims can't demote the admin.
• The admin can still be linked to an IdP by email. When auto_link_by_email is enabled and the IdP returns a verified email matching the admin, the SSO flow links that identity to the existing admin user (packages/server/src/rbac/sso/service.ts, "Linked SSO identity to existing user by email"). After linking, the admin signs in through the IdP.
• Password login is a global toggle that also applies to the admin. When password login is disabled (a usable SSO provider exists), the login route rejects password auth for everyone, including the admin (packages/server/src/rbac/routes/auth.ts — if (!getPasswordLoginEnabled())).
• There is a global no-lockout fail-safe, but it is not admin-specific. resolvePasswordLoginEnabled (packages/server/src/rbac/authConfig.ts) forces password login back on when there is no usable SSO provider. This prevents locking out all password users, but does not guarantee the admin specifically can always get in.

Net: the admin can be partially absorbed into SSO (linked by email), and password login for the admin can be turned off as a side effect of the global toggle. There is no hard guarantee that the admin remains a local, always-password account.

Why this is a problem

1. IdP outage / misconfiguration = no way in. If the admin depends on SSO and the IdP is down, misconfigured, or the provider is deleted, there is no reliable local path to recover. This is the exact scenario break-glass accounts exist to prevent.
2. Account-takeover risk via email-based linking. Linking accounts by email trusts that the IdP-asserted email belongs to the same person as the local account. If an IdP can be made to assert the admin's email (or email verification is weak on the IdP side), an attacker could link to and then sign in as the admin. Email is an identifier, not a proof of account ownership.
3. Privilege concentration on an external system. Putting the highest-privilege account behind a third-party IdP widens the blast radius: a compromise or misconfiguration of the IdP becomes a compromise of the admin.
4. Unexpected coupling. An operator turning off password login (a reasonable hardening step for normal users) silently removes the admin's password path too, which is surprising and dangerous.

Proposed change (acceptance criteria)

Make the default admin a local break-glass account, excluded from SSO by default:

1. The seeded admin is never JIT-provisioned, never auto-linked by email, and never role-synced by the SSO flow.
2. The admin's password login is always available, independent of the global "password login enabled" toggle.
3. Provide an explicit opt-in to relax this (default off), e.g. AUTH_ADMIN_SSO_ENABLED=true (env / auth.admin_sso.enabled in YAML). Only when set may the admin be linked/managed via SSO.
4. Keep the existing protections for all other users: no super_admin demotion via claims; no global password lockout without a usable SSO provider.
5. Log loudly (audit + warn) on any attempt to link/JIT the admin while the opt-in is off, and surface it in the SSO admin UI.
6. Add tests: admin email arriving over SSO does not link or demote when the opt-in is off; admin password login still works when the global password toggle is off; opt-in path behaves as documented.

Notes / scope

• This is about the bootstrap/break-glass admin specifically, not normal RBAC users.
• Recommend documenting the admin as a break-glass account (cloud/local-only, password + ideally separate strong secret, monitored, used rarely) in the SSO setup docs.

References (why this is standard practice, not opinion)

• OWASP Authentication Cheat Sheet — local/administrative auth, lockout avoidance, recovery: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
• OWASP Top 10 (2021) — A07: Identification and Authentication Failures: https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/
• OWASP Application Security Verification Standard (ASVS) — V2 Authentication (administrative auth, federation, recovery requirements): https://owasp.org/www-project-application-security-verification-standard/
• NIST SP 800-63B — Digital Identity Guidelines (authentication, federation, account recovery): https://pages.nist.gov/800-63-3/sp800-63b.html
• Microsoft Entra ID — Manage emergency access ("break-glass") accounts (industry pattern: keep ≥1 highly-privileged account excluded from federation/SSO and Conditional Access so an IdP failure can't lock you out): https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access
• IETF RFC 9700 — Best Current Practice for OAuth 2.0 Security (identifier/account-linking trust, don't treat unverified identifiers as proof of ownership): https://www.rfc-editor.org/rfc/rfc9700

Topic

RBAC/Permissions

Version

No response

Additional Information

No response

[daun-gatal]

Could you help point out the part of the code here also?

[RafPe]

No probs - will prepare you that bit later

[RafPe]

Could you help point out the part of the code here also?

Took a moment to generate a boiler plate on the basis of this spec

RafPe#1