1. Implement Azure App Service Web Apps
   1. Authentication and Authorization in App Service
   2. App Service Networking Features
2. Configure Web App Settings
   1. App Settings
   2. General Settings
   3. Path Mappings
   4. Web App Diagnostic Logging
   5. Web App Security Certificate Configuration

Implement Azure App Service Web Apps

• Azure App Service - HTTP-based service for hosting webapps, REST APIs and mobile backends. Features:
  • Built-in auto scale support
  • Container support - Pull from a private Azure Container Registry or Docker Hub. Also supports multi-container apps, Windows containers and Docker Compose for orchestrating container instances
  • Provides CI/CD through Azure DevOps Services, Azure Container Registry, GitHub, Docker Hub, Bitbucket, FTP or a local Git repository.
  • Deployment slots - Instead of deploying in the default 'production slot' you can deploy to a 'deployment slot' which has its own hostname. App content and configuration elements can be swapped between slots
  • App Service on Linux Can host webapps natively on Linux for supported application stacks
  • Provides built-in authentication and authorization support, requiring minimal or no additions to code in your web app, RESTful API, mobile back end or Azure Functions.
• Limitations of Azure App Service:
  • App Service on Linux isn't supported on the shared pricing tier
  • The Azure portal shows only features that currently work for Linux apps
  • When deployed to built-in images, your code and content are allocated a storage volume for web content in Azure Storage with high and variable disk latency. If your app requires heavy read-only access to content files you may benefit from the custom container option, which places files in the container filesystem.
• Plans:
  • Shared Compute - Runs apps on the same Azure VM as other App Service apps, including apps of other customers. Each app is assigned a CPU quota, and resources can't scale out
  • Dedicated Compute - Runs apps on dedicated Azure VMs. Only apps in the same App Service plan share the same compute resources
  • Isolated - Run dedicated Azure VMs on dedicated Azure Virtual Networks. Provides network isolation on top of compute isolation to your apps and provides maximum scale-out capabilities.

Authentication and Authorization in App Service

• Built-in Auth
  • Built directly into the platform and doesn't require any particular language, SDK, security expertise or code
  • Can integrate with multiple login providers, eg. Entra ID, Facebook, Google, Twitter, GitHub or any OpenID Connect provider

Authentication Flow without provider SDK

1. User sign-in - Redirects client to /.auth/login/<provider>
2. Post-authentication - Provider redirects client to /.auth/login/<provider>/callback
3. Establish authenticated session - App service adds authenticated cookie to response
4. Server authenticated content - Client's browser automatically includes authentication cookie in subsequent requests
   
   

Authentication Flow with provider SDK:

1. User sign-in - Client code signs user in directly with SDK and receives an authentication token
2. Post-authentication - Client code posts token from provider to /.auth/login/<provider> for validation
3. Establish authenticated session - App Service returns its own authentication token to client code
4. Serve authenticated content - Client code presents authentication token in X-ZUMO-AUTH header

• You can configure App Service to always require authentication when users try to access an app (if enabled, users wouldn't even be able to see a home page without logging in)
• Token Store - A repository of tokens associated with your users built into App Service. Automatically enabled
• If you enable application logging, auth traces are collected directly in your log files

App Service Networking Features

• There are two main deployment types for Azure App Service:
  • Multi-tenant (Free and Shared SKU plans)
  • Single-tenant (Basic and higher plans)
• Azure App Service is a distributed system
  • Front Ends - The roles that handle incoming HTTP/S requests
  • Workers - The roles that host the customer workload
• If you're running your app in a multi-tenant environment you can't connect the App Service directly to your network. Instead you need to use features:
  • Inbound features:
    • App-assigned address
    • Access restrictions
    • Service endpoints
    • Private endpoints
  • Outbound features:
    • Hybrid connections
    • Gateway-required virtual network integration
    • Virtual network integration
• You can view the outbound IP addresses (and possible outbound IP addresses) of the worker VM families hosting your apps with the following Azure CLI commands:

az webapp show \ 
  --resource-group <group-name> \
  --name <app-name> \
  --query outboundIpAddresses \
az webapp show \ 
  --resource-group <group-name> \
  --name <app-name> \
  --query possibleOutboundIpAddresses \

Configure Web App Settings

App Settings

• In App Service, app settings are passed as environment variables to application code.
  • For Linux apps and custom containers, settings are passed using the --env flag
  • App settings are encrypted-at-rest and are suitable places to store production secrets (e.g. Azure database passwords)
• App settings can be added/edited through Azure Portal via a GUI form or JSON (click the Advanced edit button)
• App settings can also be supplied as arguments to Cloud Shell commands:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings key1=value1 key2=value2

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"DB_HOST"="myownserver.mysql.database.azure.com"}

• You can verify container environment variables with the url https://<app-name>.scm.azurewebsites.net/Env

General Settings

• In the Configuration > General settings section of the Azure portal page you can configure common settings for your app
• Some of these settings require higher pricing tiers
• Currently available settings:
  • Stack settings - Define the software stack required to run the app, including the language and SDK versions.
  • Platform settings
    • Platform bitness (32- or 64-bit. For Windows apps only)
    • FTP state - Allow only FTPS or disable FTP altogether
    • HTTP Version
    • Web sockets (eg. ASP.NET SignalR or socket.io)
    • Always On - Keeps the app loaded even there's no traffic.
      • If this option isn't enabled, the app will be unloaded after 20 minutes without incoming requests. This unloading can cause high latency for new requests due to the warm-up time.
      • If this option is enabled, the load balancer sends a GET request to the application root every five minutes to prevent the app from being unloaded.
    • ARR affinity - For multi-instance deployment, ensure that the client is routed to the same instance for the lifetime of the session. Disable this option for stateless applications
    • HTTPS Only
    • Minimum TLS Version
  • Debugging - Enable remote debugging for ASP.NET, ASP.NET Core or Node.js apps (this option disables automatically after 48 hours)
  • Incoming client certificates - Enable to require client certificates in TLS mutual authentication

Path Mappings

• In the Configuration > Path mappings section you can configure handler mappings, virtual application and directory mappings. For Windows apps (uncontainerized):
• Extensions - The file extension you want to handle (eg. php or handler.fcgi)
• Script Processor - The absolute path of the script processor. Use the path D:\home\site\wwwroot to refer to your app's root directory
• Arguments - Optional command-line arguments for the script processor For Linux and containerized apps:
• Name - The display name
• Configuration options - Basic or Advanced. Select Advanced if the storage account uses service endpoints, private endpoints or the Azure Key Vault
• Storage accounts
• Storage type - Azure Blobs or Azure Files (Windows container apps only support Azure Files; Azure Blobs only support read-only access)
• Storage container
• Share name
• Access Key
• Mount Path
• Deployment slot setting

Web App Diagnostic Logging

Below are the types of logging, the platforms supported and where the logs can be stored and accessed.

• To enable application logging for Windows in the Azure Portal, select App Service logs and then enable Application Logging (Filesystem) (for temporary debugging purposes) and/or Application Logging (Blob) (for long-term logging. Requires a blob storage container to write logs to).
  • You can also set the level of details included in the log:

• To enable application logging for Linux/container apps, set the Application logging setting to Filesystem and specify the (disk) Quota in MB and Retention Period in days.
• To enable web server logging, select Storage for blob storage or File system to store logs on the App Service file system, then set the Retention Period in days
• Any information written to .txt, .log or .htm files in the D:\home\logfiles//home/LogFiles directory can be streamed by app service
  • To stream in the Azure Portal, navigate to your app and select Log stream
  • To stream in the Azure CLI use the command az webapp log tail --name appname --resource-group myresourcegroup
• If using Azure Storage blobs for logging, you need a client tool that works with Azure Storage to access log files
• If using the file system to store logs, the easiest way to access your logs is to download the .zip file at:
  • https://<app-name>.scm.azurewebsites.net/api/logs/docker/zip (Linux/container; contains console output logs for both the docker host and the docker container)
  • https://<app-name>.scm.azurewebsites.net/api/dump (Windows)
• For scaled-out apps, the .zip file will contain a set of logs for each instance

Web App Security Certificate Configuration

Below are the options you have for adding certificates in App Service:

• Requirements of private certificates:
  • Must be exported as a password-protected PFX file, encrypted using triple DES
  • Contains private key at least 2048 bits long
  • Contains all intermediate certificates and the root certificate in the certificate chain
  • If you want to secure a custom domain in a TLS binding, it must also:
    • Contain an Extended Key Usage for server authentication
    • Be signed by a trusted certificate authority
• If you're above Free tier you can create free managed certificates. They are renewed continuously and automatically in 6 month increments 45 days before expiration. You can crete the certificate and bind it to a custom domain. However, they come with the following limitations:
  • Doesn't support wildcard certificates
  • Doesn't support usage as a client certificate by using certificate thumbprint
  • Doesn't support private DNS
  • Isn't exportable
  • Isn't supported in an App Service Environment
  • Only supports alphanumeric characters, dashes and periods
  • Only custom domains of length up to 64 characters are supported