posted by mthomas on November 2, 2011 07:27 AM

Every effort is made to have each version of Apache Tomcat to ship with a system of reasonable defaults forsecurity purposes. This means that the standard defaults for the security settings are reasonably secure—it is not as secure as it could be, but not horribly insecure either. The default security level is essentially a compromise between security and usability. It is probably OK for simple use in production, but there are a number of things that all users should consider before deploying business applications on a standard installation of Apache Tomcat.

General precautions:

• Tomcat security configuration should not be your only line of defense. Take a comprehensive look at security and ensure that your OS is secure,there are firewalls in place, and file permissions are set correctly as well.Remember, it won’t matter how secure your application is if your underlying platform is vulnerable. A simple rule of thumb (especially for those firewalls) is to ban everything and only explicitly allow what access you need to run your applications.
• Delete all the stuff you don’t need. Tomcat will by default install a handful of default applications that you don’t need, and having them in production is just more applications to look after and to ensure are secure. Take a look at the documentation, examples, default root web application, Manager App and Host Manager App and if you are not using them, delete them and focus just on your production applications. While these applications are relatively low risk, eliminating risk is always a better strategy. Same would be true if applications are archived or no longer in use – move them off of the production site to eliminate any additional pathways for threats.
• Consider running under a Security Manager. This is always a good idea if you are running applications that you do not trust (e.g. a hosting environment), or if you want an additional layer of protection. A Security Manager will essentially run each deployed web application in a separate sandbox to prevent malicious code from accessing your files or other applications on your network. While it is always a good idea to run under a security manager, it should be noted that this is best done during early stages of development as it can impact how an application behaves and thorough testing is always recommended. For later stage projects you’llneed to evaluate if the benefits of a security managerare worth the extra cost of development and testing to deploy it properly. The TCK tests that are used as part of every Tomcat release are always run under a Security Manager but few users run with a Security Manager in production. There is, therefore, a slightly increased risk that you will hit a Tomcat bug running with a Security Manager. However, it is usually possible to configure around such bugs if they occur.

Read More

posted by mthomas on October 11, 2011 09:10 AM

The Servlet 3 specification - implemented in Apache Tomcat 7 - allows web.xml fragments and annotations to be used to specify configuration information for a web application. This means that, instead of packaging up every configuration centrally in your web.xml file, every JAR can have its own xml fragment containing its own little bit of configuration for whatever classes are in that JAR. This makes it easy to add support for packages with very little effort. For instance, a Spring developer would no longer need to add the Spring application context to the web.xml file, rather they could take advantage of a web fragment in the Spring JAR that would automatically add this configuration information at runtime.

Annotations take this one step further, and allow developers to annotate code that dynamically configures application components such as Servlets and Filters. Java libraries and frameworks have been embracing annotations for some time. In fact, several IDE’s these days use annotations as a default, adding the @WebServlet annotation by default when you create a new Servlet in a dynamic web project.

Performance Impacts

Both annotations and web fragments will impact performance, particularly at application startup. Tomcat has to scan every class in every single jar file to detect if the class has been annotated as a Servlet, a Filter or Listener. This can add substantial time to application start up, which is not so much of a problem for production applications as they should start very infrequently, but it can be pretty problematic during development when you are repetitively restarting.

Tip: If you are not going to be using annotations or web-fragments, you should set your metadata-complete to true in your web.xml file to avoid the longer start up time. (web-app metadata-complete=""true"").

Read More

posted by mthomas on August 24, 2011 11:17 AM

Java 7 has recently been released, and Apache Tomcat 8 project has just opened for development. It begs the question – are they related?

In short, not necessarily. We create a new major version of Tomcat when there are new versions of three specifications—Servlet, JavaServer Pages (JSP) and Expression Language (EL). Minor updates (maintenance releases) do sometimes get produced but major changes to all three specifications are released together as part of the J2EE specification. Once a new version of the J2EE specification is released, this is what governs the update to the next major version of Apache Tomcat, and it will implement the new features defined within these specifications.

For Tomcat 6, the defining specifications are the Servlet 2.5; JSP 2.1 and EL 2.1 specifications and for Tomcat 7 they are Servlet 3.0; JSP 2.2 and EL 2.2. Work on the Servlet 3.1 and EL 3.0 specifications is underway, and it is expected that there will be a new version of the JSP specification although I haven't seen any indication of work in that area yet. If the changes in JSP 2.2 are anything to go by, any changes in the JSP specification are likely to be minimal and will probably happen closer to the J2EE release. In terms of Java 7 support, Tomcat 8 will require the minimum Java version specified by the Servlet 3.1 specification. At the moment, I expect that that will be Java 7 but we won't know for sure until the specification is finalized.

Will Tomcat 8 Development Wait Until Specs Are Published?

As the work on the specifications proceeds (I am on the expert group for both Servlet 3.1 and EL 3.0) and the changes firm up then those changes will be implemented in the Tomcat 8 branch. So far, Tomcat 8 specific changes have been limited to re-factorings that change some of the internal APIs and therefore have not been back-ported to Tomcat 7 since we don't want to change APIs there unless we have to. Current ideas for what features (other than the specification changes) might be included in Tomcat 8 can be found in svn along with the Tomcat 8 specific changes so far.

When Will Tomcat 8 Be Available?

Read More

posted by mthomas on August 17, 2011 07:46 AM

Apache Tomcat 7 contains a number of new features around database connection pooling, which help administrators keep their application available and serving content, collecting customer information, and supporting their applications. The main one that has garnered a lot of attention is the new JDBC Connection Pool feature introduced by Filip Hanik last year. Another connection pool attribute not yet discussed here on TomcatExpert.com is the new closeMethod for speeding up the closing of JNDI resources that would otherwise be closed during garbage collection.

A Specific Requirement

This feature stemmed from a common challenge for applications that make use of database connection pools attached to databases with limited connections allowed. For instance, if a database allows 50 connections, and an application uses a connection pool of 50 connections, in theory everything should work. However, if the application is reloaded, the existing open connections in the old pool would not close until they have been garbage collected. So the new application connection pool while configured for 50 connections, could run out at 37 if the old connection pool had 13 connections open.

Read More

posted by mthomas on August 3, 2011 06:50 AM

As a VMware engineer dedicated to building Apache Tomcat and vFabric tc Server , I get the opportunity to see a lot of issues across the official Apache Tomcat public mailing lists, as well as VMware’s private professional support queue for both Apache Tomcat and tc Server. Typical of any software issue tracker, many of the issues logged could be avoided with a little better understanding of the Tomcat applications. Here are a few tips that may be useful to keep in mind:

Understanding Global vs Application Context.xml Files

There are two different types of context.xml files: one is global, and the other is specific to each web application. The problem with editing the global context.xml file is, as its name implies, that it affects every web application running on that Tomcat instance. So for instance, if you have 10 web applications, and create a new JNDI datasource with 50 connections to the database in the global context.xml file, you have essentially created 10 JNDI datasources with a total of 500 connections to your database and have likely completely overwhelmed your database. If you want to add a datasource to a single application, by remembering to create the datasource in the application level context.xml file, you can avoid serious performance problems.

Creating a Single Global Datasource for Application Sharing

Occasionally companies will deploy 3 or 4 related applications on a Tomcat server that are designed to share a single datasource. As described above, placing the datasource definition either once in the global context.xml file or in 3 or 4 application specific context.xml files will always create multiple instances of that datasource. To truly share a single datasource, it is necessary to put the definition of the datasource into the server.xml file, and then place a single resource link into the global context.xml file. This link ensures only one instance of the datasource is ever created and when any application goes to use it, it always uses the same single instance.

Read More

posted by mthomas on July 20, 2011 07:18 AM

Apache Tomcat 7 includes several security updates that further harden the application server that came directly from the Bugzilla queue. One new feature, the Security Lifecycle Listener, helps ensure that Tomcat is started in a reasonably secure way.

Preventing Tomcat Running as Root

One user cited that while all administrators worth their salt should know that it is irresponsible and incredibly insecure to run Tomcat as the root user to the system, Tomcat still allows the server to start under root. Although this problem is largely contained to Linux systems, the fix had to be applicable to all operating systems. Therefore, the fix that was implemented was to create a list of users that are not allowed to start Tomcat. Tomcat checks to see if it is running as one of those users, and if it is, it shuts itself down.

Securing Tomcat Files

A secondary check after the user is validated as a secure user, is to check that any files written by Tomcat (such the contents of an expanded WAR) are created securely. As a minimum, these files must not be world writeable. In some environments it may be desirable to restrict this even further such as read/write for owner, no access for anyone else. The permissions for created files are controlled by the current user's umask. If the umask is not restrictive enough on the running user, this too will prevent Tomcat from starting.

Read More

posted by mthomas on June 30, 2011 08:39 AM

The release of Apache Tomcat 7(out in beta last June) has made great strides in improving the overall security and general robustness of the world's most popular application server. In fact, over 450 improvements and issues have been resolved in this latest stable release. While these changes range from small to significant, what is notable is the mature architecture of Apache Tomcat has remained intact as we have seen little problems thus far in the backportability of the application. (See a special note at the end of the Crawler Session Manager Valve post where we note that the Apache Software Foundation (ASF) has upgraded its own bug tracker system , JIRA, which runs on Tomcat to version 7, and it just works--even though JIRA has not yet announced support for it). This consistency across versions of course means many bug fixes, as well as new features, are good candidates to be added to Tomcat 6. As of Tomcat 6.0.30 - these are the three that you should know about:

Memory Leak Detection/Prevention

Announced in a post here on Tomcat Expert last year, the new memory leak detection and prevention feature has been a widely anticipated new feature that addresses how Tomcat can cause memory leaks in the permanent generation (PermGen) that lead to OutOfMemoryErrors when re-loading web applications.

This feature exists in two parts. First, it prevents memory leaks through a new life-cycle listener, the JreMemoryLeakPreventionListener that calls various parts of the Java API. Its common that if the web application is the first code to call the Java APIs, the web application class loader will be pinned in memory, causing leaks. The listener ensures that Tomcat is the first to make a call, and therefore prevents the class loader from being pinned in memory. For more details on what this listener actually does, the source code is pretty well commented.

Second, it handles detection by executing code when a web application is stopped, undeployed or reloaded. It scans the code for standard causes of memory leaks, and where it can, fixes the leaks. Implemented in the WebappClassLoader, there are a series of expandable, standard API calls and some reflection tricks that help this detection feature do its job. For more on what these checks do, check out the explanation by Sylvain Laurent on the Tomcat Wiki, or of course, you can look at the source code. Start with the clearReferences() method.

Updates to these features are spread over several 6.0 versions, with 6.0.30 having the latest version of the feature.

Read More

posted by mthomas on June 22, 2011 09:31 AM

Most companies of any significant size have lots of applications designed to support their employees across many departments. The bane of any system administrator in these environments, is user access to these applications. Provisioning a new employee, decommissioning an exiting employee, controlling access to contractors, and of course, the ubiquitous password resets for every employee who forgets which cat or kid they used to name their latest password.

For companies using Microsoft Windows, it is possible to do user authentication within the domain. Each user is created with one username and password, and assigned roles which designate access to various applications. Until now, in order to integrate Apache Tomcat based applications with Windows Authentication, administrators would need to use a third party library like WAFFLE, or employ a reverse proxy, such as IIS or httpd, to perform the authentication step. Many of these libraries are heavy-weight, and some solutions, such as IIS, are limited to only working on Windows hosts.

Built-in Tomcat Support for Windows Authentication

With Tomcat 7, there is now the option to use built in support for Windows Authentication. Tomcat’s Windows Authentication relies solely on Java 6 and therefore works when Tomcat is running on Linux or other non-Windows platforms. Users can also use a range of platforms and still take advantage of Windows Authentication. Users on Windows platforms, such as Windows XP, Vista or Windows 7, and who are logged on to the Windows domain, can use Windows Authentication to access applications any platforms without having to re-enter their password.

How It Works

Once windows native authentication is enabled, when a user logs onto the domain and connects to the Tomcat Server, rather than Tomcat prompting the user for a username and password, Tomcat will send a particular header to the browser. The browser recognizes this and knows that it wants it to try Windows Authentication. Since the user is already logged onto the domain, the browser can get the information from the domain. The browser constructs a response and sends it back to the Tomcat server. The server then authenticates it. Assuming response is authenticated, the user is granted access to whatever role they are assigned within the application. For users on non-Windows platforms and/or users who are not logged on to a Windows domain, the browser will prompt the user to provide their user name and password.

Read More

posted by mthomas on June 17, 2011 10:20 AM

The Apache JServ Protocol (AJP) , is a binary protocol that can proxy inbound requests from a webserver, such as Apache HTTPD, to an application server like Apache Tomcat. Typically used in load balanced web applications where the web server has to pass requests to multiple application servers, using modules like mod_proxy_ajp help improve the speed of transactions and add support for SSL. This week’s update of Apache Tomcat 7.0.16, introduces a NIO implementation of the built-in AJP connector.

What is NIO?

New I/O, usually shortened to NIO, is a set of Java APIs that allow for more scaleable I/O operations. Among other things, NIO provides support for non-blocking of data connections which ensures a response from the application server. Without NIO, admins must configure their web servers and application servers to match the number of threads between the web server and application server. Depending on configuration, application behavior and the number of concurrent sessions, there is a constant risk of running out of threads and having users get a HTTP 500 Internal Server error. NIO eliminates this risk by providing a more efficient usage of these threads.

A Simple Example

In simple deployments, users will have one HTTPD instance and one Tomcat server to host their web application. Configure both to use 1000 threads, and the web server instance and the application server instance should run fine. Where it gets complicated is when you employ multiple HTTPDs and multiple instances of Tomcat, and those instances are not using a 1 to 1 mapping— i.e. situations where any HTTPD instance can talk to any Tomcat instance.

Let’s say that you have 2 HTTPD instances and 2 Tomcat instances. Each HTTPD is configured for 1000 threads. Each Tomcat will need to be available to process a connection from each of the threads from all of the instances of HTTPD. So each Tomcat will need 2000 threads. As we add more, this quickly does not scale. As the number of HTTPD instances go up, you need more and more threads on the Tomcat side and eventually this becomes unsustainable.

Read More

posted by mthomas on May 31, 2011 07:44 AM

Upgrading web applications can be very expensive if your storefront is the web. Weekend maintenance windows, or downtime in general can give an entire company heartburn. Survey data shows that web application downtime can cost some companies up to $72,000 per minute. Yet the cost of not constantly rolling out new features and bug fixes can equally penalize a company in the competitive online markets today.

Previously, to upgrade an application on Tomcat and avoid downtime, system administrators would have to set up multiple instances of Tomcat and do some very clever stuff with load balancers. This equals extra hardware costs as a permanent part of the company’s infrastructure.

Now with the advent of parallel deployment in Tomcat 7, you can have multiple versions of the same application installed at the same time on a single server. Users with active sessions can continue to use the old application and new users will be routed to the new version. This way, no user sessions will be interrupted, and the old application can gracefully phase out.

Setting Up Parallel Deployment

Parallel deployment is a function of the Context Container. The Context element represents a web application, which in turn specifies the context path to a particular Web Application Archive (WAR) file that is the application logic. Parallel deployment allows you to deploy multiple versions of a web application with the same context path concurrently. When choosing what version of the application for any given request, Tomcat will:

1. Route new requests to the latest version, so new sessions go to the new application.
2. If session information is in the request, check the session manager for a matching version, so existing sessions will go to the original application for the request.
3. If session information is in the request, but the corresponding application is no longer present, it will route to the latest version.

Read More