Discussion :

[arN34]

Hello !

J'ai développé une web application J2EE tournant sur un serveur TOMCAT et je me pose deux questions pour les développements futurs :
1) J'ai lu l'article Couplage Apache HTTP & Tomcat (http://zekey.developpez.com/tutoriel/apache/tomcat/) : une phrase a soulevé une interrogation:

Lors de la mise en production d'une application Internet ou intranet, il est fréquent de vouloir protéger les transferts par une connexion sécurisée (HTTPS). Même si Tomcat le permet (il suffit d'activer une option dans le server.xml de Tomcat), utiliser Apache est un meilleur choix du fait de sa vitesse.

Est-ce que cela veut dire qu'Apache est plus rapide en règle générale pour me servir les pages de mon application web ou qu'Apache est plus rapide lorsqu'on veut utiliser une connexion HTTPS ?

2) J'accède à mon appli en intranet pour le moment (j'ai cependant un mécanisme d'authentification/autorisation basé sur Acegi pour le framework Spring). Cependant, j'aimerais pouvoir travailler de la maison, donc avoir un accès sécurisé par internet. Est-il possible de configurer Apache pour autoriser les utilisateurs du réseau local à accéder à l'appli sans précaution particulière mais de n'autoriser les utilisateurs extérieurs que sur validation d'un certificat électronique (qui me semble une meilleure sécurité qu'un login + password) ? Ceci afin d'avoir à gérer un minimum de certificats (uniquement les quelques personnes qui travailleraient à distance).

Merci d'avance pour vos conseils

--
Arnaud
(PS : message posté ici et sur le forum J2EE)

[xerkos]

1) Avec la version 5 de Tomcat, j'avais pu lire qu'il était plus performant de laisser Tomcat en solo gérer également les fichier statiques.
L'utilisation d'un apache en frontal étant interessant pour utiliser les fonctionnalités de load-balancing.

2) Tu peux toujours utilisé un login/password sur Https, avec un certificat auto-signé (pour éviter de dépenser le prix d'un certificat).
Sinon il y a toujours la possibilité de mettre en place un petit vpn. Ca peut-être pratique si ton intranet ne se limite pas à une interface web. Ainsi de chez toi tu travaillais dans les mêmes conditions que si tu te trouvais sur le réseau local de ton entreprise.