Skip to content

Click on each book below to review & buy on Amazon.

As an Amazon Associate, I earn from qualifying purchases.


Azure Web App Configuration - General Settings

In this guide, we cover the general settings available for an Azure Web App, demonstrating how to navigate to the configuration page, adjust stack and platform settings, and manage security features. You'll learn to tailor your web app's environment, enhancing its performance and security directly within the Azure portal. Through step-by-step instructions and illustrative images, we aim to simplify the configuration process. Whether it's selecting the right runtime stack, securing your app with HTTPS, or enabling remote debugging, this guide covers the essential settings to optimize your Azure Web App.


To start configuring your Azure Web App, first, you need to access it within the Azure portal. Begin by searching for App Services in the top search bar of the Azure portal, then click on App Services listed under Services to proceed.

app-services-search

Once you are on the "App Services" page, look for the specific App Service you wish to configure and select it to open its dashboard.

app-services-nav


Configuration - General Settings

After selecting your App Service, you'll find several options on the left-hand side. Locate and click on Configuration under the Settings group to access the configuration settings for your App Service.

app-services-config

Within the Configuration section, you'll find a tab labeled General settings. This tab houses various sections that allow you to configure the fundamental aspects of your App Service. Click on this tab to proceed to the General settings where we will detail shortly the configuration options available for an Azure Web App.

app-services-general

Stack Settings

The Stack settings section is defines the runtime environment of your App Service. Here, you can select the programming language or framework your application is built on, such as .NET, Node, Python, PHP, Ruby, Java, or Go. For each selected stack, you have the option to specify the version (both major and minor) that your application requires. Additionally, this section allows you to input a custom command that will run during the container startup, providing flexibility in how your application is initialized.

The following is a short overview of each programming language:

  • .NET: A free, cross-platform, open-source developer platform for building many different types of applications, with support for languages such as C#, Visual Basic, and F#.
  • Node: An open-source, cross-platform, JavaScript runtime environment that executes JavaScript code outside a web browser, commonly used for building server-side and networking applications.
  • Python: A high-level, interpreted, general-purpose programming language known for its readability and support for multiple programming paradigms, including procedural, object-oriented, and functional programming.
  • PHP: A popular general-purpose scripting language that is especially suited to web development, fast, flexible, and pragmatic, PHP powers everything from your blog to the most popular websites in the world.
  • Ruby: A dynamic, open source programming language with a focus on simplicity and productivity, it has an elegant syntax that is natural to read and easy to write.
  • Java: A class-based, object-oriented programming language designed to have as few implementation dependencies as possible, allowing application developers to "write once, run anywhere" (WORA).
  • Go: An open-source programming language designed at Google to make it easy to build simple, reliable, and efficient software, it's known for its simplicity, efficiency, and strong support for concurrent programming.

app-services-stack

Platform Settings

Platform settings in Azure App Services provide a suite of options that allow you to fine-tune the behavior, security, and performance of your web applications. Here's an expanded explanation of each setting, including the implications of enabling or disabling them and the options available for settings like TLS versions.

  • SCM Basic Auth Publishing Credentials: Controls the authentication method for deployments via Source Control Management (SCM) systems.

    • On: Activating this setting enables basic authentication, requiring a username and password for SCM deployments. This is essential for environments where deployments are managed through source control and need to be secured with simple credentials. It ensures that only authorized users can push updates or changes through the SCM system.
    • Off: Turning this off disables basic authentication for SCM deployments. This is useful when alternative, more secure deployment methods are preferred or when SCM deployments are not used. It can help to prevent unauthorized access if the SCM system is configured but not actively used for deployment.
  • FTP Basic Auth Publishing Credentials: Manages the authentication for FTP (File Transfer Protocol) deployments.

    • On: Enabling this setting allows basic authentication, requiring a username and password for FTP deployments. This option is for scenarios where FTP is used for uploading files to the web app. It secures the FTP access by ensuring that only users with the correct credentials can upload or modify files via FTP.
    • Off: Disabling basic authentication for FTP deployments means that users cannot deploy or modify files through FTP using basic authentication. This setting is chosen when FTP is either not used, or when deployments are secured through other means, such as FTPS with SSL/TLS or when access is restricted to certain IP addresses.
  • FTP state: This controls the level of access provided via FTP.

    • All allowed: Enables both unsecured FTP and secure FTPS for deployments.
    • FTPS only: Only secure FTPS connections are permitted, enhancing security by encrypting the file transfer session.
    • Disabled: No FTP access is permitted, increasing security by preventing FTP-based deployments.
  • HTTP version: Determines the version of the HTTP protocol your App Service uses.

    • Options typically include HTTP/1.1 and HTTP/2. HTTP/2 offers improvements over HTTP/1.1, including reduced latency through header compression and multiplexing.
  • HTTP 2.0 Proxy: This setting enables or disables a proxy for HTTP 2.0 connections.

    • On: Allows HTTP 2.0 connections to be proxied, facilitating compatibility with certain network configurations.
    • Off: Disables proxying for HTTP 2.0 connections, which may be necessary if the proxy interferes with HTTP 2.0 traffic.
  • SSH: Configures SSH (Secure Shell) access to your web app.

    • On: Enables SSH access, allowing secure command-line access to your app.
    • Off: Disables SSH access, preventing command-line access to your app for added security.
  • Always on: Determines whether your app is always loaded or unloaded after being idle.

    • On: Keeps the app always loaded, eliminating cold start latencies which is beneficial for production apps.
    • Off: Allows the app to be unloaded after being idle, saving resources but introducing a delay for the first request after being unloaded.
  • Session affinity: Also known as "ARR affinity", it manages whether the Azure Load Balancer sticks a user's sessions to a specific instance of your web app.

    • On: Enables session affinity, ensuring that requests from a particular user are routed to the same instance, useful for stateful applications.
    • Off: Disables session affinity, allowing requests to be handled by any available instance, suitable for stateless applications.
  • HTTPS Only: Forces connections to use HTTPS, redirecting all HTTP requests to HTTPS.

    • On: All incoming requests are redirected to HTTPS, ensuring data is encrypted in transit.
    • Off: Allows both HTTP and HTTPS connections, offering flexibility but reducing security.
  • Minimum TLS Version: Specifies the minimum version of TLS (Transport Layer Security) for secure communications.

    • Options include TLS 1.0, TLS 1.1 and TLS 1.2.
      • TLS 1.0 and TLS 1.1: Older versions, less secure, and not recommended.
      • TLS 1.2: Offers a good balance of compatibility and security, widely supported.

Each of these settings plays a role in the security, performance, and reliability of your Azure Web App. Adjusting these settings should be done with an understanding of your application requirements and the potential impacts on functionality and security.

app-services-platform

Debugging

For certain runtime stacks, you have the option to enable Remote debugging. This feature is useful for diagnosing and troubleshooting application issues directly on the live environment.

app-services-debug

Incoming Client Certificates

This section allows you to configure how your App Service handles incoming client certificates:

  • Client certificate mode: This crucial setting determines the level of enforcement for client certificates when they attempt to establish a connection with your App Service. It offers several options, each catering to different security and accessibility needs:

    • Require: This option mandates that all incoming requests to your App Service must include a valid client certificate. This setting is used when you want to enforce the highest level of security, ensuring that every request is authenticated using a client certificate. It's ideal for applications where sensitive data is handled, and strict access control is needed.
    • Allow: When set to "Allow," Azure App Service will prompt clients for a certificate. If a client certificate is provided, it will be validated. If no certificate is provided, the service falls back to SSO (Single Sign-On) or other means of authentication. Unauthenticated requests without a certificate will be blocked. This setting is useful for applications that require client certificates for certain users or transactions but can allow access through alternative authentication methods for others
    • Optional: This setting is similar to "Allow" but with a slight distinction in how the application handles the presence or absence of a client certificate. It allows the application to decide on an action when a client certificate is presented or not, providing flexibility in handling authenticated and unauthenticated access.
    • Ignore: When set to "Ignore," the App Service does not process or validate any client certificates. This option essentially disables client certificate authentication, making it suitable for public-facing applications where client certificate management is not needed or desired.
  • Certificate exclusion paths: This setting provides a way to specify particular paths within your application that are exempt from the client certificate requirements defined in the "Client certificate mode" setting. This is particularly useful for applications that need to expose certain endpoints or services without requiring client certificate authentication, such as public APIs or health check endpoints. By specifying paths here, you can ensure that these areas of your application remain accessible without compromising the overall security posture enforced through client certificates.

Each of these settings is designed to provide you with the control necessary to optimize and secure your Azure App Service according to your specific application requirements and security policies.

app-services-certs


Conclusion

This guide aimed to highlight the general settings available for configuration an Azure Web App. It showed how to navigate to the configuration screen and covered the stack, platform, debugging & incoming client certificate settings, detailing the different options available for each setting.


Support DTV Linux

Click on each book below to review & buy on Amazon. As an Amazon Associate, I earn from qualifying purchases.

NordVPN ®: Elevate your online privacy and security. Grab our Special Offer to safeguard your data on public Wi-Fi and secure your devices. I may earn a commission on purchases made through this link.