Understanding and Configuring Azure Web App Permissions

Azure Web App permissions can be overwhelming, especially if you're new to Azure. There are over 30 built-in permissions available, each with its own set of capabilities.

To simplify this, let's break down the permissions into three categories: management, deployment, and runtime. This will help you understand which permissions are necessary for your specific use case.

Management permissions control who can manage your Azure Web App, including creating, updating, or deleting it. For example, the "Microsoft.Web/sites/write" permission allows users to create new web apps, while the "Microsoft.Web/sites/delete" permission allows them to delete existing ones.

Deployment permissions control who can deploy code to your Azure Web App. The "Microsoft.Web/sites/deployments/write" permission, for instance, allows users to create new deployments, while the "Microsoft.Web/sites/deployments/delete" permission allows them to delete existing ones.

To configure access restrictions through the Azure portal, CLI, or when setting the site config properties directly, you need specific Role-based access control permissions.

The required permissions include Microsoft.Web/sites/config/read, which allows you to get Web App configuration settings, and Microsoft.Web/sites/config/write, which enables you to update Web App's configuration settings.

You also need Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action, which joins resources such as storage accounts or SQL databases to a subnet, and Microsoft.Web/sites/write, which updates Web App settings.

If you're adding a service endpoint-based rule and the virtual network is in a different subscription than the app, you must ensure that the subscription with the virtual network is registered for the Microsoft.Web resource provider.

There is a limit of 512 access restriction rules. If you require more than 512 access restriction rules, we suggest that you consider installing a standalone security product, such as Azure Front Door, Azure App Gateway, or an alternative WAF.

Here's a summary of the required permissions:

Every Azure Web App has a home directory stored in Azure Storage, which is available for the sandbox with read/write access. This directory is accessible using the path d:\home.

The sandbox implements a dynamic symbolic link in kernel mode, mapping d:\home to the customer's home directory, making it easier to access the site's content. This eliminates the need to reference the network share path.

Every Azure Web App also has a local directory, which is temporary and deleted when the app is no longer running on the VM. This directory is a place to store temporary data for the application, and the application has read/write access to it via the path d:\local.

The sandbox for Windows is a crucial concept to understand when it comes to Azure Web Apps. Each app is viewed by the sandbox as a tree of processes, rooted by the app's main IIS (w3wp.exe) process.

This process may spawn other child processes, such as php-cgi.exe or node.exe, which are grouped together and subject to a single set of limits. These limits are enforced within the underlying Windows kernel.

A single app can have multiple processes involved in processing an incoming request, as shown in the following table:

The memory allocated by these processes counts towards the same memory quota, so spawning additional processes won't allow you to consume more memory.

The home directory, referred to as d:\home, is where Azure Web App applications store their content. This directory is stored and backed by Azure Storage.

Every Azure Web App has a home directory, which is a network share available for the sandbox with read/write access.

The sandbox implements a dynamic symbolic link in kernel mode that maps d:\home to the customer home directory. This is done to simplify access to the site's content.

No matter where the site runs or how many sites run on a VM, each can access their home directory using d:\home.

The local directory, d:\local, is a temporary storage space for your application's temporary data.

It's a good place to store files that don't need to persist between app restarts. Every Azure Web App has its own local directory.

The application has read/write access to this directory, making it a convenient spot to stash temporary files. This access is thanks to a dynamic symbolic link that maps d:\local to the temporary directory.

Note that the d:\local folder in the scm site is not the same as the one in the main site, so they can't see each other's files. This is something to keep in mind when working with your Azure Web App.

Networking and Security is a crucial aspect of Azure Web App permissions. Azure Web Apps have manifold restrictions in terms of network access, including limitations specific to Azure App Service.

You can set up virtual networks, or VNets, to facilitate connectivity between Azure and on-premise intranets. This allows Azure Web Apps to ignore private and local address restrictions if the target network interface belongs to the app.

To manage access restriction rules, sign in to the Azure portal and select the app you want to add restrictions to. Then, select Networking and go to the Access Restrictions page.

There are several options for adding access restrictions rules programmatically, including Azure CLI, PowerShell, Azure Resource Manager, and Bicep. You can also modify ARM templates or Bicep snippets to add rules.

Access restrictions are enforced in priority order, starting from the lowest number in the Priority column. If you don't configure an unmatched rule, an implicit deny all is in effect after you add even a single rule.

Here are the possible actions you can take when creating a rule:

By following these steps, you can effectively manage access restrictions for your Azure Web App and ensure the security and integrity of your application.

To set up permissions for your Azure Web App, you need to identify the needed scope, which can be at four levels: management group, subscription, resource group, or resource. You can specify the scope by searching for it in the Azure portal.

To determine the required permissions, you need to consider the Role-based access control permissions on the subnet or at a higher level. The following permissions are required to configure access restrictions through the Azure portal, CLI, or when setting the site config properties directly:

Note that there is a limit of 512 access restriction rules, so if you require more, you may need to consider using a standalone security product.

To set up permissions, you need to identify the scope where you want to grant access. The scope is the set of resources the access applies to, and it can be specified at four levels from broad to narrow: management group, subscription, resource group, and resource.

In Azure, you can specify a scope by searching for it in the Azure portal. For example, you can search for Management groups, Subscriptions, Resource groups, or a specific resource.

To narrow down the scope, you can also use the following options:

This is important because the scope determines the resources that the access applies to, and it's essential to get it right to avoid any confusion or security issues.

You can update the main site rule action programmatically by running a command in the Cloud Shell. For more information about az resource command, visit this page.

Accepted values for ipSecurityRestrictionsDefaultAction are Allow or Deny. You can change Unmatched rule action for Main site by modifying the property ipSecurityRestrictionsDefaultAction in an ARM template. A sample ARM template snippet is provided for you.

To make the change, you'll need to modify the ARM template to update the property ipSecurityRestrictionsDefaultAction to Allow or Deny. The new value will then be applied to the main site rule action.

Configuring authentication and authorization for your Azure web app is a straightforward process that can be completed without making any changes to your application code. To start, you'll need to turn on the authentication service from the app service menu. Simply navigate to your App Service resource and click "Authentication/Authorization", then toggle the Authentication switch to "ON" and select "Azure Active Directory" as the authentication provider.

You'll need to choose a management mode, and for this example, we'll use the "Express" setting, which allows you to create a new app registration if it doesn't exist already. This will enable the Azure AD authentication provider to create a new app for authentication.

Once you've set up the authentication provider, you'll need to update the "Action to take when the request is not authenticated" to use Azure Active Directory and click "Save." This will require authentication for the entire website.

App Service provides built-in authentication and authorization support, so you can sign in users with no code in your web app. This means you can easily turn on and configure authentication through the Azure portal and app settings without requiring any SDKs, specific languages, or changes to application code.

Here are the steps to configure authentication and authorization for your Azure web app:

By following these steps, you'll be able to configure authentication and authorization for your Azure web app and start signing in users without any code changes.

To manage access restrictions in Azure, you need to sign in to the Azure portal and select the app you want to add restrictions to. You can then select the Networking option from the left menu and configure the Public network access setting.

To add an access restriction rule, you can follow these steps: Under Action, select either Allow or Deny, optionally enter a name and description of the rule, and in the Priority box, enter a priority value. You can then select the type of rule and add it to the list.

You can have a maximum of 512 access restriction rules. If you need more, consider using a standalone security product, such as Azure Front Door or Azure App Gateway.

To manage access restrictions programmatically, you can use Azure CLI, PowerShell, Azure Resource Manager, or Bicep. The command to run in Cloud Shell is az webapp config access-restriction, and for ARM templates, you need to modify the ipSecurityRestrictions block.

To change the Unmatched rule action for Advanced tool site, you can run the command az resource, or modify the property scmIpSecurityRestrictionsDefaultAction in ARM templates or Bicep.

To manage permissions to the application, navigate to the Azure Portal and search for "App Registration". Click on the app registration that you created during authentication provider setup, and then click on the "Managed Application in local directory" to manage users and groups.

Here is a list of the permissions required to configure access restrictions:

To manage permissions for your Azure web app, you'll need to navigate to the Azure Portal and search for "App Registration". Click on the app registration that you created during authentication provider setup.

You can resolve permission issues for non-authenticated users by adding new users or a security group with member users to the "Users and Groups" section under the enterprise application.

To configure access restrictions, you'll need specific Role-based access control permissions, including "Microsoft.Web/sites/config/read" and "Microsoft.Web/sites/config/write" to get and update Web App configuration settings.

There's a limit of 512 access restriction rules, so if you require more than that, consider installing a standalone security product like Azure Front Door or Azure App Gateway.

You can manage access restriction programmatically, but you'll need to use the correct Azure CLI command, such as Set-AzResource, and choose the right default action, either Allow or Deny.

Here's a summary of the required permissions for managing access restrictions: