Dans notre article sur l’utilisation de HTTPS avec Tomcat en production, nous avons étudié les solutions reposant sur la mise en place d’un reverse proxy HTTP. Nous n’avons pas oublié pour autant le protocole AJP. Ce protocole est né pour faciliter et accélérer les communications entre un serveur web frontal et le serveur d’application JServ en back-end d’Apache. Avec le temps, Tomcat a remplacé Apache JServ mais AJP est resté. Jusqu’en 2003, AJP était la seule solution viable permettant de placer le serveur d’application derrière un serveur Apache. Avec la maturation de la fonctionnalité Proxy dans Apache est née la solution tout HTTP. Nous avons donc décidé d’organiser un match opposant la solution AJP à la solution HTTP.
Lire la suite de cet article »
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
Agilité
RIA
Lire la suite de cet article »
Amazon Elastic Compute Cloud (aka EC2), et de manière générale les Amazon Web Services, ont attiré l’attention de nombreuses personnes pour la flexibilité de déploiement qu’ils permettent.
Cette plate-forme de Cloud Computing a recourt à la virtualisation pour créer à la demande des instances de serveurs directement utilisables. Il s’agit donc d’une approche totalement différente des hébergements traditionnels.
Lorsque l’on parle d’EC2, il est souvent question du déploiement de sites Web de type réseaux sociaux pouvant connaître de grands pics de trafic imprévisibles. On met alors en avant l’élasticité de configuration qu’apporte EC2, par définition. En revanche, il est rarement question des problématiques de haute disponibilité ou des bonnes pratiques à suivre pour les déploiements d’architectures multi-tiers classiques.
De même, au-delà de l’élasticité, les justifications du déploiement sur EC2 sont en général peu abordées.
Chris Richardson, créateur de CloudFoundry (récemment racheté par SpringSource), nous a offert une présentation très complète sur l’ensemble de ces sujets rarement abordés autour des Web Services d’Amazon.
Lire la suite de cet article »
Suite à vos retours nombreux, aux différents articles touchant à la sécurisation par SSL de Tomcat en production (Tomcat : Adresse IP de l’internaute, load balancer, reverse proxy et header HTTP X-Forwarded-For, Sécuriser Tomcat 5 derrière un proxy Apache 2 HTTPS), nous commençons une série sur Tomcat en production.
Dans ce premier article, nous abordons l’utilisation de SSL pour sécuriser les communications. Pourquoi utiliser SSL ? Comment SSL est-il intégré avec le moteur de Servlet ? Et surtout quelle configuration correspond à votre application, qu’elle soit hébergée sur un serveur Tomcat seul, avec un serveur Apache Httpd en frontal, avec un accélérateur SSL ou avec un load-balancer hardware.
Lire la suite de cet article »
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
RIA
Le coin de la technique
Evènements de notre communauté en France et à l’étranger
Lire la suite de cet article »
Configurer Tomcat 5 derrière un proxy Apache avec HTTPS, dit comme ça, le novice éclairé pourrait croire que c’est facile. Cependant les problèmes dus à de mauvaises configurations sont nombreux et parfois difficiles à diagnostiquer comme les boucles infinies de redirection par exemple. Donc facile oui (maintenant), mais il m’a fallu plusieurs heures de sueur avant de trouver, non pas une, mais deux solutions. L’avantage de ces deux techniques est de n’utiliser que le driver SSL d’Apache pour fournir le protocole HTTPS. Notez bien cette distinction, car il est facile d’avoir la configuration Apache HTTPS en proxy de Tomcat 5 HTTPS. Toute la difficulté est d’avoir une configuration pleinement fonctionnelle dans laquelle Apache HTTPS est proxy de Tomcat 5 HTTP. Cela permet de sniffer les paquets entre le frontal Web et l’application métier, tout en évitant de doubler les ressources utilisées pour encrypter et décrypter les données.
Un détail pour ceux qui utilisent le mod_jk, le projet Apache Httpd propose depuis Apache 2.0, le module mod_proxy qui permet notamment d’assurer la liaison Apache-Tomcat. Ce module, complété en version 2.2 de mod_proxy_balancer pour le load balancing, supporte les protocole HTTP (mod_proxy_http) et AJP 1.3 (mod_proxy_ajp). Si AJP a longtemps été le protocole utilisé par Tomcat en production, il est aujourd’hui possible, plus simple et plus fiable d’utiliser HTTP. HTTP est notamment recommandé par Mark Thomas et Philip Hanik, SpringSource, qui sont les plus gros contributeurs du projet Tomcat en ce moment.
Si vous êtes habitués à mod_jk, vous apprécierez notamment la simplicité d’un module embarqué par la distribution standard de Tomcat, la fin des interrogations sur la fermeture des connexions en présence d’un firewall entre Apache et Tomcat ou encore le débuggage avec un sniffeur réseau comme wireshark pour voir passer en clair les requêtes HTTP.
Lire la suite de cet article »
Après Tomcat qui rentrait cet été de plain-pied dans l’univers du Java Platform as a Service avec le mariage de SpringSource à VMWare et à CloudFoundry, c’est au tour de l’autre moteur léger de servlets, Jetty/Webtide, de s’adosser à un acteur du Cloud Computing, Intalio, pour développer son offre.
Une reconnaissance méritée
C’est une très belle opportunité pour Jetty qui était jusqu’à présent beaucoup plus embarqué que Tomcat par des grands projets de Cloud Computing (Google App Engine, Hadoop, Gigaspace XAP, etc) mais n’avait pas constitué sa propre offre.
Sur les pas d’Amazon ?
Le mariage d’Intalio avec Webtide est assez différent de celui de SpringSource avec VMWare et Cloud Foundry. Alors que la deuxième union concerne des spécialistes de l’infrastructure, Intalio est lui issu de l’univers des applications CRM et s’étend vers les infrastructures de Cloud Computing comme l’a fait Amazon auparavant.
Des serveurs J2EE lourds absents
Nous remarquerons à l’occasion que les serveurs J2EE heavyweight se font très discrets dans cette période d’avalanche d’annonces sur Java Platform as a Service, on peut s’attendre à ce qu’ils répondent sur cette tendance qui va bouleverser les modes de fonctionnement dans les data centers et menacer leurs parts de marché.
Ils en parlent
Le projet JRuby fournit aux développeurs une implémentation native Java du langage Ruby. Le but est d’interfacer sans douleur des classes Java et des scripts Ruby. La star du monde Ruby est bien entendu Ruby On Rails, le fameux framework réputé tellement productif qu’il suffit de penser le projet pour voir les lignes de code apparaître … Depuis quelques temps, on entend parler dans la blogosphère de JRuby on Rails. Nous allons tenter de voir si cette solution est mûre ou non pour les développements d’applications web.
Lire la suite de cet article »
Depuis le rachat de Covalent en Janvier 2008, SpringSource est le premier contributeur au projet Apache Tomcat avec plus de 80% des commits ; Mark Thomas et Philip Thomas en sont les principaux acteurs.
Tomcat est la pierre angulaire de l’offre middleware de SpringSource aujourd’hui composée de tc Server, une version professionnelle Open Source de Tomcat et dm Server, un serveur OSGi (le format d’assemblage que SpringSource préfère aux classiques .war).
Mark Thomas a présenté lors de SpringOne 2009 : Securing Apache Tomcat For Your Environment les points essentiels sur ce sujet qui se décompose en trois thèmes : la confidentialité, l’intégrité et la disponibilité.
Lire la suite de cet article »
Une conférence est l’occasion de discuter avec les ingénieurs des difficultés que nous rencontrons à utiliser leurs produits. J’ai profité de ma participation à SpringOne 2009 pour échanger avec Mark Thomas sur le suivi de l’adresse IP des internautes dans les logs d’audit d’applications web. Mark Thomas est des principaux committer du projet Tomcat et de SpringSource tc Server.
Le problème se présente lorsqu’un serveur Tomcat est précédé d’un reverse proxy (e.g. mod_proxy, Squid Cache, etc) ou d’un load balancer (Nortel Alteon, F5 Big-IP, etc) : La méthode HttpServletRequest.getRemoteAddr() ne retourne plus l’adresse IP de l’internaute mais celle du composant réseau qui précède le serveur Tomcat.
Cette perte d’information a été compensée par les reverse-proxy en ajoutant un header http X-Forwarded-For à toutes les requêtes qu’ils font transiter. Bien que ce header ne soit pas standard (son nom commence d’ailleurs par « X- »), il est devenu un standard de facto utilisé par la très grande majorité des reverse proxy et load balancers (paramètre xforward=enable pour les Alteon d’après Command Reference ; propriété Insert XForwarded For de la GUI du profile http ou règle when HTTP_REQUEST { HTTP::header insert "X-Forwarded-For" [IP::client_addr] } pour les Big-IP d’après F5 Dev Central : Using « X-Forwarded-For » in Apache or PHP ).
Cependant, les implémentations de l’API Servlet ne sont pas tenues de prendre en compte ce paramètre dans la méthode request.getRemoteAddr() dont la javadoc stipule bien Returns the Internet Protocol (IP) address of the client or last proxy that sent the request. . Tomcat est d’ailleurs autant concerné que ses concurrents Websphere ou Weblogic, pour ne citer qu’eux.
Toutes les couches sont impactées : l’Access Log Tomcat dont les patterns common et combined utilisent le remote host name (%h) et les frameworks de sécurité et d’audit comme Spring Security (cf WebAuthenticationDetails.getRemoteAddress()) ou CAS Inskektr ClientInfo).
Lire la suite de cet article »
Complet
Twitter
