IFC-2664 lock password changes for externally authenticated accounts

[gmazoyer]

Why

Any account provisioned through an external identity provider (LDAP, OIDC, OAuth2) could overwrite its local password through the self-update mutation, then sign in via the local-auth endpoint with the chosen password. The bypass survived directory-side revocation. This PR closes that gap on both the security side (backend) and the UX side (the frontend never lets the user reach the form).

Found while exercising LDAP against a live Active Directory; the bug applies to every account linked to an external identity, not just LDAP ones.

What changed

The self-update mutation now refuses to write the password when the account is linked to an external identity, while continuing to accept description-only updates. The current account profile gains a boolean flag so the frontend can act before any submission. The synthesized field is added on the account interface.

Three alternative shapes for the signal can be considered (whitelisting the relationship in the schema-gen filter, moving the underlying type out of the Internal namespace, encoding the source in JWT claims).

The profile page reads the new flag, hides the Password tab for externally managed accounts, and shows an "externally managed" panel on the password page for direct navigation. The earlier reactive error-string workaround is gone.

Checklist

• Tests added/updated
• Changelog entry added (uv run towncrier create ...)
• I have reviewed AI generated content

---

Summary by cubic

Blocks local password changes for accounts linked to external identity providers and hides the password UI for those users. Fixes the bypass letting LDAP/OIDC/OAuth2 users set a local password and log in via local auth (IFC-2664).

• Bug Fixes
  • Backend: InfrahubAccountSelfUpdate rejects password updates when an ExternalIdentity exists; description-only updates still allowed.
  • GraphQL: added is_externally_managed (Boolean!) to CoreGenericAccount/CoreAccount and AccountProfile; resolver returns true if a linked external identity exists.
  • Frontend: reads is_externally_managed; hides the Password tab unless it’s false (also while loading); shows a loading state on the Password tab while the profile resolves; shows a “Password managed externally” panel; toasts mutation errors.
  • Tests: coverage for password rejection, allowed description updates, tab visibility (including loading), password-tab loading state, externally managed panel, and form submit.
  • Changelog: security entry added.

^{Written for commit c57ff6f. Summary will update on new commits.}

[cubic-dev-ai]

2 issues found across 11 files

Confidence score: 3/5

• There is some merge risk: backend/infrahub/graphql/resolvers/resolver.py may return inconsistent external-identity data if GraphQL branch/timestamp context is not passed through, which can surface incorrect results across branch/time views.
• frontend/app/src/entities/user-profile/ui/tab-update-password.tsx currently renders the password form before profile state is resolved, so users can briefly see the wrong UI state instead of a proper loading/unknown guard (as noted in IFC-2664).
• Pay close attention to backend/infrahub/graphql/resolvers/resolver.py and frontend/app/src/entities/user-profile/ui/tab-update-password.tsx - context propagation and loading-state handling are the main user-facing risk areas.

<sub>Shadow auto-approve: would not auto-approve because issues were found.

Re-trigger cubic</sub>

[codspeed-hq]

Merging this PR will not alter performance

✅ 12 untouched benchmarks

---

_{Comparing gma-20260529-ifc2664 (c57ff6f) with develop (db56c32)}

[cubic-dev-ai]

0 issues found across 2 files (changes from recent commits).

<sub>Shadow auto-approve: would require human review. This security fix modifies core backend mutation logic, adds a dynamic GraphQL field, and alters frontend account behavior, which carries risk of unintended side effects in account management and requires human review.

Re-trigger cubic</sub>