Using ManagedIdentityCredential locally

Alistair Young 31 Reputation points
2022-06-21T10:01:05.48+00:00

Local development cannot use:

var azureServiceTokenProvider = new ManagedIdentityCredential(clientIdOfuserAssignedManagedIdentity);  

and most solutions make use of Microsoft.Azure.Services.AppAuthentication which is now deprecated in favour of Azure.Identity.

Is there a way to use ManagedIdentityCredential locally when developing? Visual Studio can use DefaultAzureCredential and there is ClientSecretCredential but none of them work for accessing the Roles in an AccessToken. The Roles are always empty.

The managed identity gets an AccessToken from api://GUID and its Roles are working. There doesn't appear to be a way to do this locally though, even though a separate Role is set up in the App Registration for User/Groups with a Role value.

Not Monitored
Not Monitored
Tag not monitored by Microsoft.
35,882 questions
0 comments No comments
{count} votes

2 answers

Sort by: Most helpful
  1. Alistair Young 31 Reputation points
    2022-06-21T14:02:34.34+00:00

    I managed to get it working by adding a Users/Groups App Role 'LocalDevelopment' to the App Registration with the value 'API.Use.Local', then added the user I'm running as, which is in Azure AD to the App Registration via Enterprise Applications:

    Enterprise applications -> TheApp -> Users and groups -> +Add
    add the user I'm using with Azure CLI with role 'LocalDevelopment'

    I could then login with az using the scope:

    az login --scope api://APPLICATION_ID/.default  
    

    using the user I added in the Enterprise application part and then verifying obtaining an access token worked from the commandline:

    az account get-access-token --output json --scope api://APPLICATION_ID/.default  
    

    The code then worked for running locally:

       DefaultAzureCredentialOptions defaultAzureCredentialOptions = new()  
               {  
                   ManagedIdentityClientId = clientIdOfuserAssignedManagedIdentity,  
                   ExcludeInteractiveBrowserCredential = true,  
                   ExcludeVisualStudioCodeCredential = true,  
                   ExcludeVisualStudioCredential = true,  
                   ExcludeAzureCliCredential = false,  
                   ExcludeSharedTokenCacheCredential = true,  
                   ExcludeAzurePowerShellCredential = true  
               };  
               DefaultAzureCredential tokenCredential = new(defaultAzureCredentialOptions);  
               string accessToken = tokenCredential.GetToken(new TokenRequestContext(new[] { "api://APPLICATION_ID/.default" })).Token.ToString();  
    
    0 comments No comments

  2. 2022-06-23T00:00:27.053+00:00

    Hello @Alistair Young , the easiest and possibly most faithful approach (since you may want to mimic the capabilities and limits of a real service principal) here should be to set the values for EnvironmentCredential and, as you already pointed, assign app roles to the resource service principal.

    You would use a test service principal or might try using the actual managed identity service principal with custom keys o passwords (besides the managed ones) that you add for authentication.

    Let us know if this answer was helpful to you or if you need additional assistance. If it was helpful, please remember to accept it and complete the quality survey so that others in the community with similar questions can more easily find a rated solution.

    0 comments No comments