Azure-sdk-for-net: Support for user assigned identity for App Service MSI

[noelbundick]

Per https://docs.microsoft.com/en-us/azure/app-service/overview-managed-identity, the Azure App Service token URL, as accessed by MSI_ENDPOINT supports an optional parameter named clientid to select which User-Assigned Identity to use.

The current call to that endpoint does not pass through the clientid parameter for App Service MSI, only for VM IMDS endpoint calls. See: https://github.com/Azure/azure-sdk-for-net/blob/psSdkJson6/src/SdkCommon/AppAuthentication/Azure.Services.AppAuthentication/TokenProviders/MsiAccessTokenProvider.cs#L56

This means that effectively, Microsoft.Azure.Services.AppAuthentication 1.2.0-preview cannot be used to retrieve tokens for user-assigned MSI on Azure App Service / Azure Functions.

I think this is a relatively simple change to add the clientid parameter to the app service MSI call

Would you be open to a PR (with tests, of course) to add this feature?

[michaelwstark]

@noelbundick
If you are looking for a work around - the following works. Definitely not ideal and could easily break when\if you update the version of the package you are consuming. It works because the parameters being appended to the url are not being properly escaped in the source:

        AzureServiceTokenProvider tokenProvider = new AzureServiceTokenProvider();

        return new KeyVaultClient(
                (authority, resource, scope) =>
                {
                    resource = string.Format(CultureInfo.InvariantCulture, "{0}&clientid={1}", resource, clientId);
                    return tokenProvider.KeyVaultTokenCallback(authority, resource, scope);
                });

[noelbundick]

Thanks @michaelwstark

For me, I don't want to use KeyVault at all - I just want to hit MSI_ENDPOINT, get a token, and then use it against ARM.

I've actually had working code for this for a while now (not-terrible commit w/ changes but no tests here: https://github.com/noelbundick/azure-utilities/commit/debdc8bf1f99a8d60bbf62bb3da774d574d15e6d). It can be used w/ user-assigned MSI on Functions, and then falls back to azure-cli auth for local dev - so you don't have to jump through a lot of hoops just to get an auth token and call Azure.

My intent was more to ask the question "If I make the effort to set up the test suite, write tests, get everything working, write docs, make PRs to Azure docs, etc" is this package even open to accepting a PR?

[michaelwstark]

@noelbundick
The workaround should be pretty similar with or without key vault -- internally the callback just calls the same method you have referenced in your original comment.

Unfortunately, I can't answer the question regarding the contribution PR as I don't own or maintain this repo. I would hope the maintainers would welcome the contribution, but they would have to confirm. I'm just another developer that wanted to use user assigned MSI and ran into this issue.

[noelbundick]

For any adventurous comment readers that want to do what I did to get unblocked

• Blog - Azure Functions w/ User-Assigned MSI
  
  
  
  • Note the AzureServicesAuthConnectionString = RunAs=App;AppId={identity client id}; appsetting on the Function App
  
  
• AppAuthentication - SDK changes to support passing clientid to the Functions MSI_ENDPOINT
• Azure SDK - Glue to wire together AppAuthentication and Azure SDK
• Functions - Sample function that starts a VM using User-Assigned Identity

[nonik0]

FYI this support is added in 1.2.0-preview2.

[varunsh-msft]

@shahabhijeet , can you please close this? Thanks!

[varunsh-msft]

Closing as this is done in 1.2.0-preview2