Configure security for a Tomcat, JBoss, or Java SE app in Azure App Service

  • Article

This article shows how to configure Java-specific security settings in App Service. Java applications running in App Service have the same set of security best practices as other applications.

Azure App Service runs Java web applications on a fully managed service in three variants:

  • Java SE - Can run an app deployed as a JAR package that contains an embedded server (such as Spring Boot, Dropwizard, Quarkus, or one with an embedded Tomcat or Jetty server).
  • Tomcat - The built-in Tomcat server can run an app deployed as a WAR package.

Note

For Spring applications, we recommend using Azure Spring Apps. However, you can still use Azure App Service as a destination.

Authenticate users (Easy Auth)

Set up app authentication in the Azure portal with the Authentication and Authorization option. From there, you can enable authentication using Microsoft Entra ID or social sign-ins like GitHub. Azure portal configuration only works when configuring a single authentication provider. For more information, see Configure your App Service app to use Microsoft Entra sign-in and the related articles for other identity providers.

Spring Boot developers can use the Microsoft Entra Spring Boot starter to secure applications using familiar Spring Security annotations and APIs. Be sure to increase the maximum header size in your application.properties file. We suggest a value of 16384.

Your Tomcat application can access the user's claims directly from the servlet by casting the Principal object to a Map object. The Map object maps each claim type to a collection of the claims for that type. In the following code example, request is an instance of HttpServletRequest.

Map<String, Collection<String>> map = (Map<String, Collection<String>>) request.getUserPrincipal();

Now you can inspect the Map object for any specific claim. For example, the following code snippet iterates through all the claim types and prints the contents of each collection.

for (Object key : map.keySet()) {
        Object value = map.get(key);
        if (value != null && value instanceof Collection {
            Collection claims = (Collection) value;
            for (Object claim : claims) {
                System.out.println(claims);
            }
        }
    }

To sign out users, use the /.auth/ext/logout path. There's also official documentation on the Tomcat HttpServletRequest interface and its methods. The following servlet methods are also hydrated based on your App Service configuration:

public boolean isSecure()
public String getRemoteAddr()
public String getRemoteHost()
public String getScheme()
public int getServerPort()

To disable this feature, create an Application Setting named WEBSITE_AUTH_SKIP_PRINCIPAL with a value of 1. To disable all servlet filters added by App Service, create a setting named WEBSITE_SKIP_FILTERS with a value of 1.

Configure TLS/SSL

To upload an existing TLS/SSL certificate and bind it to your application's domain name, follow the instructions in Secure a custom DNS name with an TLS/SSL binding in Azure App Service. You can also configure the app to enforce TLS/SSL.

Use KeyVault References

Azure KeyVault provides centralized secret management with access policies and audit history. You can store secrets (such as passwords or connection strings) in KeyVault and access these secrets in your application through environment variables.

First, follow the instructions for granting your app access to a key vault and making a KeyVault reference to your secret in an Application Setting. You can validate that the reference resolves to the secret by printing the environment variable while remotely accessing the App Service terminal.

For Spring configuration files, see this documentation on externalized configurations.

To inject these secrets in your Spring configuration file, use environment variable injection syntax (${MY_ENV_VAR}).

To inject these secrets in your Tomcat configuration file, use environment variable injection syntax (${MY_ENV_VAR}).

Use the Java key store in Linux

By default, any public or private certificates uploaded to App Service Linux are loaded into the respective Java key stores as the container starts. After uploading your certificate, you'll need to restart your App Service for it to be loaded into the Java key store. Public certificates are loaded into the key store at $JRE_HOME/lib/security/cacerts, and private certificates are stored in $JRE_HOME/lib/security/client.jks.

More configuration might be necessary for encrypting your JDBC connection with certificates in the Java key store. Refer to the documentation for your chosen JDBC driver.

Initialize the Java key store in Linux

To initialize the import java.security.KeyStore object, load the keystore file with the password. The default password for both key stores is changeit.

KeyStore keyStore = KeyStore.getInstance("jks");
keyStore.load(
    new FileInputStream(System.getenv("JRE_HOME")+"/lib/security/cacerts"),
    "changeit".toCharArray());

KeyStore keyStore = KeyStore.getInstance("pkcs12");
keyStore.load(
    new FileInputStream(System.getenv("JRE_HOME")+"/lib/security/client.jks"),
    "changeit".toCharArray());

Manually load the key store in Linux

You can load certificates manually to the key store. Create an app setting, SKIP_JAVA_KEYSTORE_LOAD, with a value of 1 to disable App Service from loading the certificates into the key store automatically. All public certificates uploaded to App Service via the Azure portal are stored under /var/ssl/certs/. Private certificates are stored under /var/ssl/private/.

You can interact or debug the Java Key Tool by opening an SSH connection to your App Service and running the command keytool. See the Key Tool documentation for a list of commands. For more information on the KeyStore API, see the official documentation.

Next steps

Visit the Azure for Java Developers center to find Azure quickstarts, tutorials, and Java reference documentation.