Lite: shared credential profiles — #1038 Phase B

[erikdarlingdata]

What shipped

Phase B of #1038: a named credential profile (a shared SQL login, an Azure service principal, or a managed identity) that many server entries reference, so one identity covers a whole fleet without per-server secret entry. Composing Phase A's SP auth + a shared profile is the #1036 ask ("one identity across all my Azure SQL instances"). Lite only, no new NuGet, additive + backward compatible (profiles are opt-in; CredentialProfileId == null = today's per-server behavior).

New:

• CredentialProfile model (Lite/Models/CredentialProfile.cs) — Id, Name, AuthType (SqlServer/ServicePrincipal/ManagedIdentity only), non-secret fields. No secret property.
• ProfileManager (Lite/Services/ProfileManager.cs) — shared-dir profiles.json mirroring ServerManager (WriteIndented, .bak restore-on-corruption, lock, CRUD), secret via profile_{id}, ImportProfilesFromFile, referential-integrity (in-use) query, implements IProfileLookup.
• IProfileLookup (Lite/Services/IProfileLookup.cs), CredentialResolver (Lite/Services/CredentialResolver.cs).
• ManageCredentialProfilesDialog + EditCredentialProfileDialog (CRUD UI), launched from a "Credential Profiles…" button in ManageServersWindow.

Modified: ServerConnection (resolution refactor + removed overloads + profile-aware HasStoredCredentials); the call-site sweep; ServerManager (IProfileLookup seam); MainWindow (two-phase wiring + import); AddServerDialog (profile picker + M-3 scrub + profile-aware edit-load); the migrated tests.

Fail-closed, atomic-tuple resolution

Resolution produces ONE immutable tuple (authType, username, password, azureClientId, miClientId) sourced entirely from the profile OR entirely from the server — never field-by-field mixed (so a profile secret can never combine with the server's stale AzureClientId to build the wrong SP identity). When CredentialProfileId != null:

• profile found → tuple entirely from the profile (its AuthType, its non-secret fields, secret from GetCredential("profile_{id}"));
• profile missing → throws "credential profile '{id}' not found" in a closed branch with NO fall-through to the server's own AuthenticationType/GetCredential(Id)/this.AzureClientId/this.ManagedIdentityClientId. A dangling profile never silently connects under server-self auth.

This is the real safety net behind the best-effort delete-constraint (the shared %ProgramData% dir is multi-user-writable, so referential integrity is advisory).

The acyclicity seam (IProfileLookup)

ServerManager.CheckConnectionAsync builds its string inside ServerManager and can't depend on the resolver/ProfileManager (that recreates a cycle). Instead ServerManager holds a late-injected IProfileLookup (default null = today's behavior) and resolves through the SAME fail-closed static. Two-phase wiring in MainWindow.xaml.cs: build ServerManager → new ProfileManager(serverManager) → serverManager.ProfileLookup = profileManager. Coupling stays one-way: ServerManager → IProfileLookup ← ProfileManager, and separately ProfileManager → ServerManager (for the in-use query).

Compiler-enforced sweep

The ServerConnection.GetConnectionString(CredentialService) / GetUtilityConnectionString(CredentialService) instance overloads were removed, so every connection-string call site failed to compile until routed through CredentialResolver. All sites across SqlPlanFetcher, McpPlanTools, FinOpsTab, ExcludedDatabasesDialog, ServerTab.* (15), RemoteCollectorService, plus ServerManager.CheckConnectionAsync now resolve through the same profile-or-self/fail-closed path. The downstream new SqlConnectionStringBuilder(connStr){…} re-parsers were left alone (they only override catalog/timeout, not auth). The MCP/SqlPlanFetcher paths route via serverManager.CredentialResolver (the singleton whose ProfileLookup is wired), so they pick up profiles without a static-signature change.

Security note

Profile secrets live only in Windows Credential Manager under profile_{id}; CredentialProfile has no secret property and profiles.json never stores one (verified by a test asserting the password is absent from the on-disk JSON). The profile_ namespace can't collide with bare-GUID server keys or the SMTP/webhook literals. Assigning a profile to a server unconditionally scrubs the per-server identity (DeleteCredential(server.Id) + null Azure/MI fields) regardless of auth type (M-3), so a later "switch back to inline" can't resurrect a stale secret.

Build + test (real results)

dotnet build Lite/PerformanceMonitorLite.csproj -c Debug — Build succeeded, 0 Warning(s), 0 Error(s).

dotnet test Lite.Tests — Passed! Failed: 0, Passed: 349, Skipped: 0, Total: 349. Includes the migrated existing tests (off the removed overload, onto the resolver, keeping the SP-secret / MI-no-secret assertions) and 13 new profile tests, notably:

• Resolution_DanglingProfile_Throws_AndNeverFallsBackToServerSelfAuth (the HARD fail-closed test)
• Resolution_ProfileServicePrincipal_UsesProfileClientId_NotServerStaleAzureClientId (B-3)
• Resolution_ProfileLessServer_IsRegressionIdentical
• HasStoredCredentials_ProfileBacked_ReflectsProfileSecret_NotServerKey / _DanglingProfile_IsFalse
• ProfileManager_Add_Get_Persists_AndStoresSecretUnderProfileKey (asserts secret absent from JSON)
• ProfileManager_Delete_BlockedWhileServerReferences_AllowedAfterReassign
• SwitchToProfile_DeletesOrphanedPerServerSecret
• Import_RoundTrips_AndBuildTolerates_SecretAbsentImportedProfile

Maintainer E2E (real Azure — gate, not run in CI)

• Create one SP profile, attach it to several Azure SQL servers, confirm all connect non-interactively under the single identity (the [QUESTION] Is it possible to onboard all my Azure SQL and MSSQL from my tenant to PerformanceLite using auto discovery? #1036 fleet scenario end-to-end).
• SQL-login profile across several on-prem servers.
• Delete-constraint blocks while a profile is in use; allowed after reassignment.
• Import a profiles.json from a previous install; confirm secrets must be re-entered once via the profile editor.

🤖 Generated with Claude Code