Refresh Customer Permissions of Azure Managed Applications

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.

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

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.

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.

# 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": {
    0.00
    to
    100.00
  },
  "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.

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.