Tomcat Security

There are four area's to securing Tomcat

• Securing your computers filesystem against Tomcat
• Restricting the operations that Tomcat is allowed to perform
• Securing access to web applications using authenication realms
• Securing tha data channel between Tomcat and the client using SSL

Basic Security

Tomcat should not be installed as the "root" or "admin" user but an account and group created called "tomcat". This account will have less privileges that the superuser "root"/"admin". Permissions should be set that not all the world can read and write to the Tomcat files.

Java Security Manager

You can also impose further security precautions but using the Java Security Manager, but default it is turned off. This will restrict what Java application Tomcat has and has to be given permissions to access class loaders, sockets on servers, etc.

The security manager uses policy files to grant permissions to Tomcat :

// first grant entry
grant {
    permission java.lang.RuntimePermission "stopThread";
}
// second grant entry
grant codeBase "file:${java.home}/lib/ext/*" {
   permission java.security.AllPermissions;
};

The first entry grants all applications the ability to access the deprecated Thread.stop() method. The second entry all code in $JAVA_HOME/lib/ext directory is granted all permissions, which effectively disables the Security Manager for that code.

As of current there are 19 different permission classes offering control over various permissions.

To enable the security manager apon startup you use the parameter -security:

$CATALINA_HOME/bin/catalina.sh start -security

Tomcat uses the $CATALINA_HOME/conf/catalina.policy file to determine its own permissions and those of its web applications.

When palcing shared code with omcat shared loader directories ($CATALINA_HOME/classes and $CATALINA_HOME/lib) makes sure that this code is trusted, you also want to change the policy file to set permission on these classes.

Security Realms

A Realm is a programming interface that is used to authenicate users and implement container-managed security based on roles. Realms can be used more securely using digested passwords or a JBDC connection to a database server.

To change the security policy of a web application edit the web.xml file and change the <security-constraint> parameter and example is below

<security-constraint>
<display-name>Example Security Constraint</display-name>
<web-resource-collection>
<web-resource-name>Protected Area</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>DELETE</http-method>
<http-method>GET</http-method>
<http-method>POST</http-method>
<http-method>PUT</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>tomcat</role-name>
<role-name>role1</role-name>
</auth-constraint>
</security-constraint>

With the example above both the role and the user will have to be created in tomcat-users.xml file. The document can only be access if you login as tomcat and supply the password. As you can see the passwords in this file are in clear text and by using digested password we could encrypt this password entries. Tomcat can encrypt by using MD5 or SHA so you would get the following:

Before digesting the password
<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
<role rolename="role1"/>
<user username="tomcat" password="tomcat" roles="tomcat"/>
</tomcat-users>

After digesting the password
<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
<role rolename="role1"/>
<user username="tomcat" password="1b359d8753858b55befa0441067aaed3" roles="tomcat"/>
</tomcat-users>

JDBC realms basically authenicate against a database (support Mysql, Oracle, etc).

It is also possible for Tomcat to use SSL or TLS and encrypt data over the network. By using Sun's Java Secure Socket implemention (JSSE) you can use both SSL and TLS protocols.