In my previous post on Different JVM settings for different Tomcat instances, I briefly touched on using tomcat-users.xml to allow access to the the Server Status page. This page, along with the Tomcat Manager application (amongst others), are installed by default when you deploy Tomcat. Access to them is controlled via the tomcat-users.xml file.

As we saw in the previous article, we can enable access by defining a role, and subsequently a user who is part of that role.

Why doesn't Tomcat ship with a default account?: Simple. It's a security issue. Instead of providing that default account, Tomcat is locked down completely, and it's up to us to enable access.

Let's try accessing the Tomcat Manager without having any users defined in tomcat-users.xml.

As you can see, access is restricted. However, what it does do is tell us (some of) the types of roles available to us.

Let's look at our tomcat-users.xml file again. Now, based on what you see in the file, and what we added in the previous article, I'm hoping most (if not all) of you are a little concerned by the fact passwords are stored in plain text.

Thankfully this file isn't directly accessible from a web browser, however it can be read by anyone who has access to the server.

Realms

Tomcat Realms are simply a way of "storing" usernames, passwords and roles. The default out of the box realm used is "UserDatabaseRealm". This particular realm reads clear text passwords out of tomcat-users.xml

We're going to look at a couple of alternative realms, namely: MemoryRealm and JDBCRealm. There are other realms available to you, and if your interested, you can read up on them at: http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html

MemoryRealm

What we're going to do is change the realm to "MemoryRealm", which whilst still reading the user details out of tomcat-users.xml, will now do so using a specified encrypted format: SHA, MD2 or MD5.

The algorithm must be supported by the java.security.MessageDigest class

Open up CATALINA_HOME/instance/conf/server.xml

Find "UserDatabaseRealm", as below, and comment it out.

Next, add the following Realm inside the Host block, which is just below the section you commented out.

Save the file, and exit.

We now need to create a SHA encrypted version of the password you want to use. Tomcat is useful here as it provides a script to do just that. Inside CATALINA_HOME/bin, run the following:

As a proper example:

You now want to replace your password (in tomcat-users.xml) with the encrypted version.

Now restart Tomcat and you should be able to login.

JDBCRealm

To configure the JDBCRealm, we need to do a couple of things first:

1. Create tables and columns in your database of choice (we're going to use MySQL in this scenario)
2. Configure a 'tomcat' user to allow Tomcat to talk to MySQL
3. Drop the MySQL connector JAR file into place
4. Set up our Realm

Use the following scripts to create your tables:

(I've created a dedicated database called TomcatAuthentication)

We need to populate our tables with data, so now run the following:

We now need to grant a 'tomcat' user read access to these tables, so run the following from your favourite MySQL client tool:

The next thing we need to do is get a hold of the MySQL JDBC driver, which we can download from: http://dev.mysql.com/downloads/connector/j/

Download the file, extract the contents, and then copy the JAR file (in my case mysql-connector-java-5.1.20-bin.jar) to CATALINA_HOME/lib

Now we want to add a Realm to our servers.xml file to support JDBC.

Add the following to our definition (replacing the MemoryRealm):

I've already replace the appropriate entries above to those we're using in this article.

Now you can restart Tomcat, and when you try to access the Tomcat Manager or Service Status page, authentication will now take place against MySQL.

You can obviously harden your password further by using SSL, and locking down access to internal IPs or even just localhost, and we'll look at this in a future article.

My previous post about Running Multiple Tomcat Instances resulted in both instances using identical JVM settings.

There will be plenty of scenarios where that is fine, but for the times when it's not, it's really straight forward to change your JVM settings, including: the JVM being used, your memory settings, the garbage collector, and so on.

Let's take a simple scenario. Instance1 can use the default Tomcat JVM settings, but instance2 requires the following changes:

• Max Heap size of 1GB
• Permanent Generation to be sized to 192m
• Different JVM

Open up instance2-startup.sh in your favourite text editor, and add the following:

(We created instance2-startup.sh in the previous article, and it can be found in your CATALINA_HOME/bin directory)

The JAVA_HOME path obviously needs changed depending on the alternative JVM you want to use (and you'll need to install it of course).

Your startup file should now look (somewhat) similar to:

Save your file. Job done.

To confirm that your instance is now using the custom JVM configuration, we're going to take a look at the Tomcat Server Status page. Before we can do that, we need to enable access.

Tomcat stores user account data in the tomcat-users.xml file that can be found in your instances conf folder, e.g.

/opt/ApacheTomcat/apache-tomcat-7.0.27/instance2/conf/tomcat-users.xml

Add the following to the file:

The above creates a role called 'manager-gui' which basically allows access to all the Tomcat management pages, as well as a new user who is assigned that role.

Clearly you don't want to use admin/admin for your username and password in production but it will suffice for our current needs.

Save the file, and then stop/start your Tomcat instance.

Fire up your Tomcat dashboard in your favourite browser; http://localhost:8282 (remember and use the port number associated with your instance).

You can now click on the 'Server Status' button that is shown on the right hand side of the page, enter admin/admin for the username/password, and you'll see a bunch of information including; JVM memory settings, the JVM being used and more.

If you fire up your other instance, the one using the default settings (remember to edit it's tomcat-users.xml file to allow access to the Server Status page), and then view its server status, you'll see the contrasting information, which proves your utilising different JVM configurations for your Tomcat instances.