Page History

...

• Use properties replacement so that in the xml config you have ${db.password} and in conf/catalina.properties you put the password there. You are not safer, but the auditors may be happy.
• Since server.xml is an XML file — you can use XML entities. For example: "woot" becomes "woot" which is a way to obscure the password.
• XML entities can be read from an external file. That is, add the following lines at the top of server.xml just above the <Server> element:

<!DOCTYPE server-xml [
  <!ENTITY resources SYSTEM "resources.txt">
]>

Now, whenever you write &resources; in the text below, it will be replaced by the content of the file "resources.txt". The file path is relative to the conf directory.

• Write your own datasource implementation which wraps your datasource and obscure your brains out. See the docs on how to do this.
• Write your own javax.naming.spi.ObjectFactory implementation that creates and configures your datasource.
• (Tomcat 7) Write your own org.apache.tomcat.util.IntrospectionUtils.PropertySource implementation to 'decrypt' passwords that are 'encrypted' in catalina.properties and referenced via ${...} in server.xml. You'll need to set the system property org.apache.tomcat.util.digester.PROPERTY_SOURCE to point to your PropertySource implmentationimplementation. This won't provide any real security, it just adds another level of indirection - i.e. 'security by obscurity'.