At my company we’re currently moving away from developing large desktop applications to developing smaller web applications. Changing our build-test-deploy processes is also part of that transition. After using Jenkins for a long time merely for continuous integration, I wanted to see what it takes to set up a continuous deployment pipeline. In this short post I’ll describe the steps to extend a Jenkins job to automatically deploy a built war file to a Tomcat instance. In future posts I intend to also elaborate on adding automated tests using Cucumber and or Selenium to the Jenkins build.
Apache Tomcat is by far the most popular (open source) web server and Java servlet container. It has been around for a long time and – at the time of writing this post – has reached version 7.0.29. As Apache rightfully claims on its web site, Tomcat powers numerous large-scale, mission-critical web applications across a diverse range of industries and organizations. Therefore, one might imagine that such a widely used server would out-of-the-box already prove to be very secure .
However, alot of weaknesses in Apache Tomcat stem from incorrect or inappropriate configuration – as is the case not only for Tomcat but for the majority of software products, I would imagine. The OWASP organization has written up a nice document with a lot of best practices and recommendations on how to make Tomcat more secure than the default out-of-the-box installation.
The OWASP document rightfully states that best practices advice us never to store clear text passwords, but that in the case of the server.xml it is very difficult to avoid. In this post, I will try to look into ways to avoid storing clear text password in Tomcat’s files that hopefully will make it less difficult to avoid.
Continue reading “Encrypting passwords in Tomcat”