Use IIdentityLogger for MSAL logging in TokenAcquisition and ManagedIdentityClientAssertion (#3820)

[neha-bhargava]

Summary

Fixes #3820.

TokenAcquisition and ManagedIdentityClientAssertion configured MSAL's internal logging via the legacy WithLogging(LogCallback, …) overload. That callback hands back a single pre-formatted string, so the entire MSAL log line (MSAL version, runtime, OS, correlation id, message) was flattened into one unstructured ILogger message, and the log-level threshold was computed up front by a hand-rolled ConvertMicrosoftExtensionsLogLevelToMsal helper.

This PR switches all MSAL logging configuration to the IIdentityLogger overload, passing IdentityLoggerAdapter from Microsoft.IdentityModel.LoggingExtensions — the same adapter IdentityWeb already uses for Wilson logging in MicrosoftIdentityBaseAuthenticationBuilder. MSAL now emits each log entry at its proper level and ILogger owns the filtering.

Changes

• TokenAcquisition.cs (confidential client build) — use new IdentityLoggerAdapter(_logger).
• TokenAcquisition.ManagedIdentity.cs (managed identity build) — use new IdentityLoggerAdapter(_logger).
• ManagedIdentityClientAssertion.cs (Certificateless) — use new IdentityLoggerAdapter(_logger); added the Microsoft.IdentityModel.LoggingExtensions package reference to the project.
• Removed the now-unused Log callbacks and ConvertMicrosoftExtensionsLogLevelToMsal helpers from both types.
• Changelog entry under Behavior changes.

Notes / out of scope

• The issue also observes that ManagedIdentityClientAssertion's log entries carry the source context Microsoft.Identity.Web.DefaultCertificateLoader. That comes from the ILogger category supplied by the caller that constructs the assertion, not from the logging API used here, so it is intentionally left out of this change. Happy to follow up separately if a dedicated category is desired.

Testing

• Microsoft.Identity.Web.TokenAcquisition and Microsoft.Identity.Web.Certificateless build clean (0 warnings) across all target frameworks.
• Microsoft.Identity.Web.Test builds clean; no existing tests referenced the removed private helpers.

[trwalke]

The log level we use in MSAL is slightly different from the one used in IdWeb since IdWeb used the standard .Net log levels. will this translation still happen correctly?

https://learn.microsoft.com/en-us/aspnet/core/fundamentals/logging/?view=aspnetcore-10.0#log-level

[neha-bhargava]

Good question — there are two hops now (MSAL LogLevel → EventLogLevel → ILogger level). Traced both upstream (MSAL LoggerHelper.GetEventLogLevel + Wilson IdentityLoggerAdapter):

MSAL LogLevel	new	old callback
Error	LogError	LogError
Warning	LogWarning	LogWarning
Info	LogInformation	LogInformation
Verbose	LogDebug	LogDebug
Always	LogTrace	LogInformation

4/5 are identical. Only Always shifts (Info → Trace), and that's just MSAL's "health metric" lines — not the Info/Error/Warning logs this PR is about. It's the standard MSAL → IIdentityLogger → IdentityLoggerAdapter behavior, i.e. the same adapter we already use for Wilson logging. Filtering is also now per-entry via ILogger.IsEnabled instead of a one-time threshold computed at construction. I can drop in a small custom IIdentityLogger if we want Always to stay at Information, but I'd lean toward matching the rest of the stack.