Refresh Customer Permissions of Azure Managed Applications

Rawson WadeAzure & Entra Software Engineer

Azure Managed Applications serve as a valuable tool for both publishers and customers, allowing them to collaboratively manage application responsibilities within the customer’s Azure environment. These applications come with remarkable features that are worth exploring (you can find more information in the guide on how managed applications work in Azure).

However, some of the lesser-known capabilities revolve around how publishers can update their offerings after deployment. While this post won’t delve into the specifics of updating resources (which must be handled on your end), it will focus on the process of adjusting permissions for Azure Managed Applications. This includes managing roles such as Owner, Contributor, and Customer Allowed Actions.

Azure Managed Applications are a useful tool for both publisher and customers to share the responsibilities of an application in the customer's azure environment. They have some amazing features which you should explore but some of the more undocumented capabilities lies around how publishers can update their offering after deployment.

This post won't go into the details for updating resources (which needs to be updated on your side) but will focus on the process of updating permissions for Azure Managed Applications, such as Owner and Contributor roles, along with Customer Allowed Actions.

If you are early in your Azure Managed Application journey I recommend you check out this blog which explores Azure Managed Application Offering Basics.

Update Azure Managed Application Permissions After Deployment

Imagine you’ve rolled out your new Azure Managed Application to a customer, and now they require additional access to a certain resource, or perhaps you need the Owner role to assign new RBAC permissions to identities within their or your tenant.

Microsoft provides APIs to manage resources for deployed Managed Applications, but before utilizing these, it’s necessary to update your product offering in the Partner Center. Essentially, the strategy involves releasing an updated version of the application on the Azure Marketplace with modified permissions (even if it's just in preview). Following this, the customer or publisher will execute a specific command to refresh their permissions on the existing deployment. As a final step, you can republish the application with the initial permissions restored.

Update Partner Center Offering Permissions

Add the customer allowed actions or change your permissions between owner / contributor.

Update Partner Center Offering Permissions

Update the version number on the same page and make a note of it for later.

Finally, save the offering draft and publish your offering. It only needs to reach the "Publisher signoff" stage before you can proceed.

Once it has reached the "Publisher signoff" stage, you can provide your customer with the following command to run.

az login
az rest --method POST --uri '/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Solutions/applications/{applicationName}/refreshPermissions?api-version=2019-07-01"&"targetVersion=0.0.1' --verbose

Quick note. If you go to your customer's Azure Managed Application object and then go to it's properties. You will find that the ID if 90% of that command's URL. So just copy that, and you will have the SubscriptionId, ResourceGroupName and the ApplicationName all in a single click.

Check Status Of Refresh Permissions

Then wait 15 minutes, and you will see that your customer now has all the permissions you have given them. However, instead of just waiting and hoping for the best you should query the async operation to be sure it didn't fail.

Refresh Permissions Not Updating on Azure Managed Application

As you have likely seen I made sure to include the --verbose flag to the az cli commands. This was no mistake. This flag shows the response headers to your queries which means we can query the Async Operation result from the azure command.

Azure Async Operation Result Header in Az CLI

Here is an example response which shows on the header we care about Azure-AsyncOperation. This header provides a status URL to monitor the progress of an asynchronous operation, such as one that might take 15 minutes to fully propagate. Generally, async operations return a 202 (accepted) response, indicating that the operation has started and all general checks on your request have succeeded. However, the 202 status code alone does not guarantee that the operation is asynchronous. To confirm, you need to check the provisioningState header.

For async requests, the response includes an Azure-AsyncOperation header and a Retry-After header. This simply means you should wait for the number of seconds specified in the Retry-After header, and then make a GET request to the Azure-AsyncOperation URL.

We can take the URL of the Azure-AsyncOperation URL and run the command using the Azure CLI.

Be really careful running this in powershell as they use & in the URL causes issues. If you are running in powershell make sure to wrap all the & in double quotes like "&". To save you eyes, there is a c, s and h query parameter in the URL. OR save it to a variable first 🙂

# REPLACE {Azure-AsyncOperationURL} with your URL from the header
az rest --method GET --uri "{Azure-AsyncOperationURL} --verbose"

Now you should know how your new permissions operations went.

Azure Async Operation Result

Your async operation should return an object with similar properties. This object can provide information such as the percentage complete, status, and importantly, any errors.

  "id": "{resource path from GET operation}",
  "name": "{operation-id}",
  "status": "Succeeded | Failed | Canceled | {resource provider values}",
  "startTime": "2017-01-06T20:56:36.002812+00:00",
  "endTime": "2017-01-06T20:56:56.002812+00:00",
  "percentComplete": {
  "properties": {
    /* Specific resource provider values for successful operations */
  "error": {
    "code": "{error code}",
    "message": "{error description}"

As a real world example you can see the following error from using the wrong permission from the Azure Marketplace.

Azure Manged App Refresh Permissions Response to Azure Async Operation

You can see that it shows you what was the error and the time it occurred.

Here is the Error:

"Refresh permissions for application App failed with exception 'Microsoft. KeyVauIt/vauIts/secrets/getSecret/action' does not match any of the actions supported by the providers."

Helpful tip 1

A helpful tip is to remember the version that you deployed that has the updated permissions. You can use their again later down the track to fix customer permissions if they ever get stuck. Just remember, any customer can change their permissions to a published version! A bit of a security hole if you ask me.

Helpful tip 2

This is also applicable for changing the publisher's access type which could be either contributer or owner. If you change that setting in the offering you will see that reflected on the managed application.

Wrapping Up

You have seen how to refresh permissions of your already deployed Azure Managed Application from the Azure Marketplace. Hopefully this article helps you in your Managed Application Journey. As always if you need assistance in deploying your Managed Application you can reach out to us and we will set up a time to chat. Our team has experience in configuring and deploying applications like Apporetum to the Azure Marketplace and have seen it flourish on the Azure Marketplace.

Rawson WadeAzure & Entra Software Engineer

© Posts are provided 'as is' under the AGPL 3.0 license unless otherwise stated

Want to be kept in the loop

Sign up to hear about the latest from the team at Entraneer. We talk anything Entra, IAM and Azure Enterprise Apps.

Azure Azure Marketplace Partner Center Managed Application How Managed Applications Work Azure managed Application Customer View of Managed Applications Publisher View of Managed Applications azure managed services azure portal azure cloud managed services azure license just-in-time-access jit jit failed refresh permissions contributor owner customer allowed actions partner center

Expansive Knowledge, Best in class Security, best Value in the Cyber Security and Microsoft Entra Partner Class, Highly Skilled. Preference number one. Microsoft Entra Excellence. We are your consultants for entra engineering and development. Microsoft entra engineering. Identity and Access Management Experts in Microsoft Azure, Microsoft Entra, Microsoft Entra ID and Microsoft Entra External ID. experts for microsoft entra Our team offers expansive knowledge and best-in-class security, ensuring the best value in the cyber security industry. As a top Microsoft Entra Partner, we provide highly skilled services, making us your number one preference. We excel in Microsoft Entra excellence and serve as your dedicated consultants for Entra engineering and development. Our expertise in Microsoft Entra engineering encompasses all aspects of identity and access management. We are identity and access management experts in Microsoft Azure, Microsoft Entra, Microsoft Entra ID, and Microsoft Entra External ID. Trust us as your experts for Microsoft Entra. Need help with azuread / Microsoft Entra. Talk to the trusted experts from Australia

We use cookies

We use cookies to ensure you get the best experience on our website. By clicking Accept, you agree to our use of cookies.
Learn more.