Retrieve list of user managed identities

[matt-psaltis]

With the Azure App Service, the user managed identity must be nominated even when there's only one. Is there an MSI endpoint alongside the /token endpoint that we can use to enumerate the list of user managed identities? Ideally the identity name and client id so that the correct user managed identity can be chosen when there's more than one based on naming conventions etc.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: f57d3177-ce9e-ebfa-03a7-45beb8ca3212
• Version Independent ID: a59df23d-f3ac-9809-61d3-5741e31f020a
• Content: Managed identities overview - Azure App Service
• Content Source: articles/app-service/overview-managed-identity.md
• Service: app-service
• GitHub Login: @mattchenderson
• Microsoft Alias: mahender

[BhargaviAnnadevara]

@SaltyDH Thanks for the question! We're investigating this and will get back to you shortly.

[AjayKumar-MSFT]

@SaltyDH, You could try Get-AzUserAssignedIdentity which gets existing user assigned identities.

Get-AzUserAssignedIdentity -ResourceGroupName

Also, you could leverage Get-AzureADServicePrincipal cmdlet, which gets a service principal in Azure Active Directory with managed identity. Get-AzureADServicePrincipal | where-object {$_.serviceprincipaltype -eq "managedidentity" }

Kindly let us know if this works for your requirement.

[matt-psaltis]

If I understand these commands correctly, they require authentication to the azure management apis. I'm looking for a local endpoint similar to the msi/token endpoint which will allow me to programmatically enumerate the user managed identities that have been assigned to the app service. This is so that I can provide the correct managed identity to the AzureServiceTokenProvider.

[matt-psaltis]

To clarify, the http://127.0.0.1:41418/MSI/token endpoint only requires the use of the MSI_SECRET environment variable to successfully request an access token. Is there a way to use this secret to retrieve a list of user managed identities in preparation for calling the MSI/token endpoint?

[AjayKumar-MSFT]

@SaltyDH, Thank you for the clarification and sharing additional details of your requirement. Your feedback has been shared with the content owner (@mattchenderson) for further review.

[mattchenderson]

Hi - can you explain what having a local endpoint would give you over using the management APIs? How would you make use of it?

Most uses I've seen define the desired ID as an environment variable and have the code reference that when setting up AzureServiceTokenProvider. To get that app setting, they rely on the management APIs / portal UI.

[matt-psaltis]

Hi Matt,

Thank you for reaching out to seek further clarification. I asked this question here because I thought that this endpoint might already exist. I can continue to use an environment variable which is the approach already in place.

What I was striving to achieve was a convention based system boot-up process which doesn't rely on environment variables but rather discovers its configuration based on what it (the app service via the User assigned identity) has access to. This works, with the exception of the initial authentication process which requires the user identity to be nominated by Client Id.

"Can you explain what having a local endpoint would give you over using the management APIs?"

During application start-up, the application process has not yet obtained an Access Token for the https://management.azure.com/ resource.

Therefore, using Management APIs to discover the Client Id of the User assigned identity would require authentication, to authenticate, I need the Client Id its a catch-22. Using a system assigned managed identity is a possibility for this part of the process but more moving parts...

In contrast, a local endpoint would not require and Access Token in the same way that the /MSI/token endpoint doesn't require one. It would still require the MSI_Secret to avoid cross site requests.

Sending a GET request to http://127.0.0.1:41418/MSI/tokens/list (or similar) would return a JSON response like this:

[
  {
    "Name": "managed-identity-name",
    "ClientId": "<guid>",
    "ObjectId": "<guid>"
  }
]

This response replaces the need for environment variables and allows the calling application code to select the correct User managed identity based on application logic.

I hope some of that makes sense.

[mattchenderson]

Is the idea that you would rely on the name for your app to distinguish them? If that's the case, would using a name on the token acquisition call make more sense? That keeps it to a one-step process.

Just to be clear, with the management endpoint, I was referring to setting the environment variable at config time. Agreed that we don't want the app making these calls itself in normal operation.

[matt-psaltis]

If names are supported in the AppId component of the call to AzureServiceTokenProvider that could work. The application would get an access denied for the services that do not have their USMI configured and would successfully authenticate for those that do. It would be a little inefficient in that I would have to boot all features of the platform and some would fail to start. They would gracefully shut down again. This is the primary factor for having a list, The application bootstrap process can filter the list of services down to ones that are actually configured and only start the appropriate services.

In terms of the /list endpoint - Correct the name would be the deciding factor for example the app service might be configured with the following managed identities.

• feature-communication
• feature-reporting
• feature-workflow

There might be a dozen other services that would boot and then shutdown because their USMI is not configured.

[jgudka]

Hi, I was wondering if there has been any update with this?

I would also like to on a VM, be able to choose a user-assigned identity without having to first authenticate using the VMs system-assigned identity to resolve the client id of the correct user-assigned identity, and ideally without having to set environment variables.

[rneeft]

Any news on this topic?? I have an Azure function with a user managed Identity but unable to resolve the client id automatically. So I store it as a environment setting, which doesn't feel good.

[AjayKumar-MSFT]

Apologies for the delay! @mattchenderson, Requesting your comments on this. Thank you.

[RobLSDev]

Any updates? It would be really handy to be able to use names rather than GUIDs in our app configs, both for readability and support the scenario where we want to destroy and recreate an AKS environment where all of the names would be the same but the GUIDs would be different.

[cephalin]

needs-sme-input

[cephalin]

Closing this stale issue as you can already specify a user-assigned identity by client ID in app code. #please-close