Configurer la sécurité pour une application Tomcat, JBoss ou Java SE dans Azure App Service

Article
07/24/2024

Cet article explique comment configurer des paramètres de sécurité propres à Java dans App Service. Les applications Java exécutées dans App Service exigent les mêmes bonnes pratiques de sécurité que les autres applications.

Azure App Service exécute des applications web Java sur un service complètement managé en trois variantes :

Java SE : peut exécuter une application déployée en tant que package JAR qui contient un serveur incorporé (par exemple Spring Boot, Dropwizard, Quarkus ou avec un serveur Tomcat ou Jetty incorporé).
Tomcat : le serveur Tomcat intégré peut exécuter une application déployée en tant que package WAR.
JBoss EAP – Pris en charge pour les applications Linux seulement dans les niveaux de tarification Gratuit, Premium v3 et Isolé v2. Le serveur JBoss EAP intégré peut exécuter une application déployée en tant que package WAR ou EAR.

Remarque

Pour les applications Spring, nous vous recommandons d’utiliser Azure Spring Apps. Toutefois, vous pouvez toujours utiliser Azure App Service comme destination. Pour obtenir des conseils, consultez l’Aide de destination de la charge de travail Java.

Authentifier les utilisateurs (authentification facile)

Configurez l’authentification de l’application dans le portail Azure avec l’option Authentification et autorisation. À partir de là, vous pouvez activer l’authentification en utilisant Microsoft Entra ID ou des infos d’identification des réseaux sociaux tels que Facebook, Google ou GitHub. La configuration du portail Azure fonctionne seulement si vous configurez un seul fournisseur d’authentification. Si vous souhaitez obtenir plus d’informations, consultez Configurer votre application App Service pour utiliser une connexion Microsoft Entra et les articles connexes pour d’autres fournisseurs d’identités. Si vous devez activer plusieurs fournisseurs de connexion, suivez les instructions de l’article Personnaliser les connexions et les déconnexions.

Les développeurs Spring Boot peuvent utiliser le démarreur Spring Boot Microsoft Entra pour sécuriser des applications en tirant parti d’API et d’annotations Spring Security connues. Veillez à augmenter la taille d’en-tête maximale dans votre fichier application.properties. Nous vous suggérons une valeur de 16384.

Votre application Tomcat peut accéder directement aux revendications de l’utilisateur à partir du servlet en forçant le type de l’objet Principal en objet Map. L’objet Map mappe chaque type de revendication avec une collection des revendications de ce type. Dans l’exemple de code suivant, request est une instance de HttpServletRequest.

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

Vous pouvez maintenant inspecter l’objet Map pour une revendication spécifique. Par exemple, l’extrait de code suivant effectue une itération dans tous les types de revendications et imprime le contenu de chaque 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);
            }
        }
    }

Pour déconnecter les utilisateurs, utilisez le chemin /.auth/ext/logout. Pour effectuer d’autres actions, consultez la documentation relative à la Personnalisation des connexions et des déconnexions. Il existe également une documentation officielle sur l’interface HttpServletRequest de Tomcat et ses méthodes. Les méthodes servlet suivantes sont également alimentées en fonction de la configuration de votre App Service :

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

Pour désactiver cette fonctionnalité, créez un paramètre d’application nommé WEBSITE_AUTH_SKIP_PRINCIPAL avec la valeur 1. Pour désactiver tous les filtres de servlet ajoutés par App Service, créez un paramètre nommé WEBSITE_SKIP_FILTERS avec la valeur 1.

Pour JBoss EAP, consultez l’onglet Tomcat.

Configurer TLS/SSL

Pour charger un certificat TLS/SSL existant et le lier au nom de domaine de votre application, suivez les instructions de l’article Sécuriser un nom DNS personnalisé avec une liaison TLS/SSL dans Azure App Service. Vous pouvez également configurer l’application pour appliquer TLS/SSL.

Utiliser des références KeyVault

Azure Key Vault fournit une gestion des secrets centralisée avec des stratégies d’accès et un historique d’audit. Vous pouvez stocker des secrets (tels que des mots de passe ou chaînes de connexion) dans KeyVault et accéder à ces secrets dans votre application via des variables d’environnement.

Tout d’abord, suivez les instructions pour autoriser votre application à accéder au coffre de clés et pour créer une référence du Coffre de clés à votre secret dans un Paramètre d’application. Vous pouvez vérifier la résolution de la référence en secret en imprimant la variable d’environnement tout en accédant à distance au terminal App Service.

Pour les fichiers de configuration Spring, consultez cette documentation sur les configurations externalisées.

Pour injecter ces secrets dans votre fichier de configuration Spring, utilisez la syntaxe d’injection de variable d’environnement (${MY_ENV_VAR}).

Utiliser le magasin de clés Java dans Linux

Par défaut, tous les certificats publics ou privés chargés sur App Service Linux sont chargés dans les magasins de clés Java respectifs au démarrage du conteneur. Après le chargement de votre certificat, vous devrez redémarrer votre App Service afin de le charger dans le magasin de clés Java. Les certificats publics sont chargés dans le magasin de clés dans $JRE_HOME/lib/security/cacerts, et les certificats privés sont stockés dans $JRE_HOME/lib/security/client.jks.

Une configuration supplémentaire peut être nécessaire pour chiffrer votre connexion JDBC avec des certificats dans le magasin de clés Java. Reportez-vous à la documentation du pilote JDBC que vous avez choisi.

Initialiser le magasin de clés Java dans Linux

Pour initialiser l’objet import java.security.KeyStore, chargez le fichier de magasin de clés avec le mot de passe. Le mot de passe par défaut pour les deux magasins de clés est 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());

Charger manuellement le magasin de clés dans Linux

Vous pouvez charger les certificats manuellement dans le magasin de clés. Créez un paramètre d'application, SKIP_JAVA_KEYSTORE_LOAD, avec une valeur de 1 pour désactiver le chargement automatique des certificats dans le magasin de clés. Tous les certificats publics chargés sur App Service via le portail Azure sont stockés sous /var/ssl/certs/. Les certificats privés sont stockés sous /var/ssl/private/.

Vous pouvez interagir ou déboguer l'outil Java Key Tool en ouvrant une connexion SSH sur votre App Service et en exécutant la commande keytool. Consultez la documentation de Key Tool pour obtenir une liste des commandes. Pour plus d’informations sur l’API KeyStore, consultez la documentation officielle.

Étapes suivantes

Visitez le centre Azure pour les développeurs Java pour trouver des guides de démarrage rapide Azure, des tutoriels et la documentation de référence Java.

Partager via