AcquireTokenForManagedIdentity should throw if a user-assigned managed identity clientID or resourceID is supplied when not supported

[christothes]

The following ManagedIdentitySources do not currently support user-assigned managed identities:

AzureArc, CloudShell, ServiceFabric

If a user-assigned clientId or resourceId is specified for these sources, we should throw with a message similar to:

https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/blob/5c7c527b173b5f2a719926fb89ccd68bc55d1b3e/src/client/Microsoft.Identity.Client/MsalErrorMessage.cs#L424

This behavior should be consistent cross-language.

[bgavrilMS]

Thanks @christothes , I opened separate bugs for the 3 other MSALs.

[neha-bhargava]

@christothes In MSAL .Net we throw the exception for Cloud Shell and Azure Arc. But the service fabric does support user assigned managed identity as documented in the public docs. See:

• https://learn.microsoft.com/en-us/azure/service-fabric/how-to-deploy-service-fabric-application-user-assigned-managed-identity
• https://learn.microsoft.com/en-us/azure/service-fabric/concepts-managed-identity#supported-scenarios-for-service-fabric-applications

[rayluo]

Documenting the cross-team discussion outcome here.

We acknowledged that (1) Azure Identity's design interprets the absence of ClientId/ResourceId as either system-assigned managed identity OR default (which could be system-assigned or user-assigned). (2) MSAL's design asks the app developer to explicitly declare upfront that whether they intend to use a SAMI or a UAMI, even though in some cases (Service Fabric) we don't actually have a way to validate their input.

We reached a reasonable compromise that MSAL and Azure Identity both keep their existing behaviors, and Azure Identity can implement this logic, "if the input contains some sort of ID and MSAL's GetManagedIdentitySource() returns ServiceFabric, then throw an exception".

[bgavrilMS]

@rayluo - can we close the Java, Py and Node JS associated issues too? See links to them at the start of this thread.

[christothes]

@rayluo What about the other sources besides SF that do not support user-assigned identities?

[rayluo]

@rayluo What about the other sources besides SF that do not support user-assigned identities?

Providing a full explanation here. Feel free to reopen the respective issue(s) if a discrepancy would be observed.

• MSAL .Net already throws for Cloud Shell and Azure Arc when a user assigned Id is passed and that is fine. For MSAL.Net the ask was to throw for service fabric as well. This was discussed last Friday and we (Azure SDK team and MSAL team) agreed on the solution of Azure Identity throwing exception when user-assigned managed identity (UAMI) is attempted when GetManagedIdentitySource() returns ServiceFabric. (Thanks to Neha Bhargava for confirming.)
• "This functionality already exists in msal-node. We throw an error for Azure Arc and Cloud Shell, and log a warning for Service Fabric. The warning for service Fabric is: ..." (Thanks to Robbie Ginsburg for confirming.)
• "Also, as long as I remember this is the same behavior in MSAL Java as well" (Thanks to Neha Bhargava for confirming.)
• MSAL Python (1) also throws exception on attempting UAMI on Azure Arc, and (2) its pre-existing cloud shell API (implemented before the Managed Identity project) does not accept UAMI in the first place; (3) it currently emits only a debug log for UAMI in Service Fabric, I might change it to a warning before I close the github issue (but that won't matter to Azure Identity because Azure Identity will throw exception here anyway).