administering tomcat
TRANSCRIPT
Administering Tomcat
There are three administration tools bundled with Tomcat 5. They are:
Server Status application Tomcat Administration Tool Tomcat Manager
These web applications are bundled with Tomcat by default and can be accessed from the left sidebar of Tomcat's default page. These tools address the need for simplified administration which other servlet engines, such as Websphere or Weblogic, provide.
The Administration Tool for Web Application
The Administration Tool for web application is GUI tool for administering Tomcat. Before we can use it, or any of the GUI tools, we will first need to create a Tomcat administrator account, a Tomcat manager account and two roles: "admin" and "manager".
For this exercise, we will create one user "TomcatAdmin" who has both manager and admin privileges.
Table 5-1. Administration Users and Roles
Tomcat Administrator Role admin This is a built-in role.
Tomcat Manager Role manager This is a built-in role.
Tomcat Administrator Username TomcatAdmin
Tomcat Administrator Password tcpass
Launch your favorite editor and add the following lines in green to $CATALINA_HOME/conf/tomcat-users.xml.
<?xml version='1.0' encoding='utf-8'?><tomcat-users> <role rolename="tomcat"/> <role rolename="role1"/> <role rolename="manager"/> <role rolename="admin"/> <user username="tomcat" password="tomcat" roles="tomcat"/> <user username="both" password="tomcat" roles="tomcat,role1"/> <user username="role1" password="tomcat" roles="role1"/> <user username="TomcatAdmin" password="tcpass" roles="admin,manager"/></tomcat-users>
Save the file, start Tomcat and open a browser. You should be able to access the Administration Tool web application by clicking on the "Tomcat Administration" link on the left sidebar. You will be presented with a login screen. Just type in your Tomcat Administrator username and password, and you should be able to enter the administration tool GUI. An example of this GUI is shown below. The Administration Tool has collapsible menus on the left. Click on any of the icons in the left pane to display information and settings in the right pane. Depending on the specifications of your server, the display of settings and information in the right pane can be very slow! You have to be patient and restrain your urge to keep clicking if the system seems unresponsive.
Tomcat Administration Tool
The Manager Web Application
You can access the Manager Web Application by clicking the "Tomcat Manager" link in the left sidebar of the default Tomcat page. This will display a GUI that allows you to view the status of your installed web applications and even deploy new web applications. There is also a link to the "HTML Manager Help" which can give you more information on using the Manager Web Application.
Tomcat Manager Web Application
The Manager web application also provides a way to install a new web application, reload it, start and stop it, and many other functions by merely passing a URL. For example, if we wanted to list the applications currently deployed in Tomcat, we could open a browser and key in http://hostname.domain.com:[port]/manager/list, and it will return the list that we require.
Status Web Application
Finally, we have the Status web application, which displays the status of the Tomcat server, such as the memory utilization of the JVM, the version of JVM being run and the number and status of threads, among other parameters. This tool is new in Tomcat 5 and can be used to check if your Tomcat server is running low on system resources.
Status Web Application
Customizing Tomcat
This section explores some of the ways you can control the way Tomcat operates. This is not exhaustive -- Tomcat is extremely sophisticated software and there are a lot of things you can change or tweak.
Disable Directory Listing
For fresh Tomcat installations, directory listing is enabled by default. This can be a very useful debugging tool, and if, like me, you sometimes forget what servlets are deployed in a certain web application, you can get a complete listing by simply keying in the web application's URL.
But for production deployments, you may want to turn it off. If nothing else, it discourages users from poking around where they should not. There are basically 2 methods of "turning off" this option :
Create an index.html file and place it in the web application's directory Edit the global web.xml file to turn off the option.
The first option is fairly simple, so we shall only examine the second option.
Open the file web.xml which is located inside $CATALINA_HOME/conf/. This is the global web.xml file,
which means that any changes here will affect ALL web applications deployed by that Tomcat instance. If you want more granular control, like turning it off for certain applications but not for others, you will need to go with the first option of creating index.html files.
Locate the following section:
<servlet> <servlet-name>default</servlet-name> <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class> <init-param> <param-name>debug</param-name> <param-value>0</param-value> </init-param> <init-param> <param-name>listings</param-name> <param-value>true</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet></sect1>
This is the first section in web.xml. The options that concern us are :
<init-param> <param-name>listings</param-name> <param-value>true</param-value></init-param>
Change <param-value> to false and you turn off directory listing. It is that simple.
Custom Default Pages
Tomcat uses the same convention as the Apache Web Server in that index.html is the default or home page of any directory. Sometimes you may want to change that to page1.html or maybe a JSP page, like now_see_this.jsp.
To do that, simply open the web.xml of your web application, and add the following lines :
<welcome-file-list> <welcome-file>now_see_this.jsp</welcome-file> <welcome-file>page1.html</welcome-file> <welcome-file>index.html</welcome-file></welcome-file-list>
To change it system-wide, edit the global web.xml in $CATALINA_HOME/conf, and change the <welcome-
file> to point to the file of your choice.
Custom Error Pages
Unhappy with the default error pages that come with Tomcat ? You can define your own custom error pages in your web.xml file. In the example shown below, we define 2 web pages -- server_error.html and file_not_found.html -- which will be displayed when the server encounters an error 500 or an error
404 respectively.
<error-page> <error-code>500</error-code> <location>/server_error.html</location> </error-page> <error-page> <error-code>404</error-code> <location>/file_not_found.html</location> </error-page>
You should bear in mind, however, that the order of the tags for the web.xml file is very important. If the order in your web.xml file is incorrect, Tomcat will output errors on startup.
Deploy and Test the Web Application
At this point, we should deploy and test our web application to verify its functionality before we put it in a realm and place a login form in front of it.
If you have been following along, and working through the exercises in this document, you should already have a HelloWorld servlet deployed in MyFirst directory, and it should work fine. We will use the MyFirst web application to "bootstrap" our JDBC realm.
You will recall that we created a "tomcat" role when we created and populated the database tables. We will use this role later to determine if a user has access to the HelloWorld servlet.
7.2.6. Prepare the Necessary Login and Error HTML Files
For this exercise, we will be using FORM-based
We will need 2 HTML files -- one for displaying the login page and one to show the user that he has keyed in the wrong password or username.
Here is the login page for this exercise:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><html><head><title>Login Page</title></head><body><h1>Login to MyFirst</h1><p>
If you have been issued a username and password, key them in here now!</p><form method="POST" action="j_security_check">Username : <input type="text" size="15" maxlength="25" name="j_username"><br><br>Password : <input type="password" size="15" maxlength="25" name="j_password"><br><br><input value="Login" type="submit"> <input value="Clear" type="reset"></form></body></html>
Note the form elements. The form action is "POST" and the action is "j_security_check", the username field's name is "j_username" and the password field's is "j_password". These elements MUST be included for the form to work.
Here is the error page for the exercise:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><html><head><title>Authentication Error!</title></head><body><h1>Authentication Error!</h1><p>Oops! You either keyed in the wrong username or password.</p><a href="javascript:history.back(1)">Try again ?</a></body></html>
There are no mandatory elements here. The link to the previous page is a good idea, to allow the user to return to the login screen.
Edit Tomcat's server.xml To Enable JDBC Realm
By default, the JDBC Realm option is not enabled. You will need to edit the server.xml file to enable it.
Locate the following section,
<Realm className="org.apache.catalina.realm.UserDatabaseRealm" debug="0" resourceName="UserDatabase"/>
And comment it out, like so,
<!-- <Realm className="org.apache.catalina.realm.UserDatabaseRealm" debug="0" resourceName="UserDatabase"/> -->
Now, locate the following lines in the same file
<!-- Replace the above Realm with one of the following to get a Realm stored in a database and accessed via JDBC -->
You will need to uncomment one of the JDBC realm definitions below these lines, taking care to substitute the values for your own database configurations values.
For example database and my JDBC driver and database parameters are as follows:
Firebird database and JDBC driver parameters
Parameter Name
server.xml equivalent
Parameter Value Remarks
Driver Name
driverName org.firebirdsql.jdbc.FBDriver
This value was provided by the JDBC driver documentation. This is typically the JDBC driver name you would use when programming a simple JDBC application.
JDBC Connection URL
connectionURLjdbc:firebirdsql:localhost/3050:/opt/firebird/db/realmdb.fdb
To find out the syntax and values of your connection URL, refer to your JDBC driver documentation
Database login name
connectionName SYSDBA
This is the username you use to login to the database containing the realm users' credentials.
Database login password
connectionPassword
passwordThis is the login user's password
Parameter Name
server.xml equivalent
Parameter Value Remarks
User Table userTable tcusers
Table containing list of authorized users for the realm
Name Column of User Table
userNameCol user_name
The name of the column containing the list of users inside the User Table
User Password Column of User Table
userCredCol user_pwd
The name of the column containing the respective user's password in the User Table
Role Table userRoleTable tcroles
Table containing the list of users and their respective roles
Role Name Column
roleNameCol role_name
The name of the column containing the user's assigned roles
With this information, we can form the following required stanza for the JDBC realm:
<Realm className="org.apache.catalina.realm.JDBCRealm" debug="0" driverName="org.firebirdsql.jdbc.FBDriver" connectionURL="jdbc:firebirdsql:localhost/3050:/opt/firebird/db/realmdb.fdb" connectionName="sysdba" connectionPassword="password" userTable="tcusers" userNameCol="user_name" userCredCol="user_pwd" userRoleTable="tcroles" roleNameCol="role_name" />
Edit the Web Application's web.xml To Require Authentication
We need to configure the web application to require authentication as well. At this stage, we determine which resources to protect, who has access, and how we want to protect these resources. That is, we define the directories and/or the files to protect (html, jsp, image files or all files), which role has access and which type of authentication we want to use (Form-based, Basic, Custom or Digest).
For this exercise, this is what we want to protect:
Everything in the MyFirst application, that is, all HTML files, image files, JSP files, servlets, text files, everything!
Any and all access methods, that is, HTTP GET, PUT, POST, DELETE, will get the login prompt.
Who can access it:
Only users with the 'tomcat' role are allowed to access the MyFirst web application
How we want to protect the resources:
We will use Form-based authentication The login page is login.html The error page, if the user keys in the wrong username or password is autherr.html
We also need to define the roles that will have access. For this exercise, we only want users with the 'tomcat' role to have access.
To express these requirements, we key in the stanza below into the web application's web.xml file, after
the <servlet-mapping> section and before the terminating </web-app> tag.
<security-constraint> <web-resource-collection> <web-resource-name>MyFirst</web-resource-name> <description> accessible by authenticated users of the tomcat role</description> <url-pattern>/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> <http-method>PUT</http-method> <http-method>DELETE</http-method> </web-resource-collection> <auth-constraint> <description>These roles are allowed access</description> <role-name>tomcat</role-name> </auth-constraint></security-constraint>
<login-config> <auth-method>FORM</auth-method> <realm-name>MyFirst Protected Area</realm-name> <form-login-config> <form-login-page>/login.html</form-login-page>
<form-error-page>/autherr.html</form-error-page> </form-login-config></login-config>
<security-role> <description>Only 'tomcat' role is allowed to access this web application</description> <role-name>tomcat</role-name></security-role>
The order of the sections is important! If you get errors on Tomcat startup, it may be due to the ordering of your sections. For example, the <security-constraint> section can ONLY come after the <servlet-mapping> section. For more details on the proper order, read the Servlet Specifications document.
Now, we are finally ready to test our JDBC realm !
Start Tomcat and Test
Verify that the login.html and autherr.html files are in the MyFirst web application directory. Your Tomcat engine should be stopped at this time. Start Tomcat and open a browser. Try to access the HelloWorld servlet. You should get redirected to the login page (see below).
Key in the username and password of a user who does *not* have the tomcat role. You should get the error page.
Next, key in the username and password of a user who has the 'tomcat' role, and click the Login button. You should then see the familiar HelloWorld servlet page.
Configuring Tomcat With A SecurityManager
Policy File Format
The security policies implemented by the Java SecurityManager are configured in the $CATALINA_HOME/conf/catalina.policy file. This file completely replaces the java.policy file present in your JDK system directories. The catalina.policy file can be edited by hand, or you can use
the policytool application that comes with Java 1.2 or later.
Entries in the catalina.policy file use the standard java.policy file format, as follows:
// Example policy file entry
grant [signedBy <signer>,] [codeBase <code source>] { permission <class> [<name> [, <action list>]];};
The signedBy and codeBase entries are optional when granting permissions. Comment lines begin with "//" and end at the end of the current line. The codeBase is in the form of a URL, and for a file URL can use the ${java.home} and ${catalina.home} properties (which are expanded out to the directory paths defined for them by the JAVA_HOME and CATALINA_HOME environment variables).
The Default Policy File
The default $CATALINA_HOME/conf/catalina.policy file looks like this:
// ============================================================================// catalina.corepolicy - Security Policy Permissions for Tomcat 5//// This file contains a default set of security policies to be enforced (by the// JVM) when Catalina is executed with the "-security" option. In addition// to the permissions granted here, the following additional permissions are// granted to the codebase specific to each web application://// * Read access to the document root directory//// $Id: security-manager-howto.xml 941437 2010-05-05 19:23:38Z kkolinko $// ============================================================================
// ========== SYSTEM CODE PERMISSIONS =========================================
// These permissions apply to javacgrant codeBase "file:${java.home}/lib/-" { permission java.security.AllPermission;
};
// These permissions apply to all shared system extensionsgrant codeBase "file:${java.home}/jre/lib/ext/-" { permission java.security.AllPermission;};
// These permissions apply to javac when ${java.home] points at $JAVA_HOME/jregrant codeBase "file:${java.home}/../lib/-" { permission java.security.AllPermission;};
// These permissions apply to all shared system extensions when// ${java.home} points at $JAVA_HOME/jregrant codeBase "file:${java.home}/lib/ext/-" { permission java.security.AllPermission;};
// ========== CATALINA CODE PERMISSIONS =======================================
// These permissions apply to the launcher codegrant codeBase "file:${catalina.home}/bin/commons-launcher.jar" { permission java.security.AllPermission;};
// These permissions apply to the server startup codegrant codeBase "file:${catalina.home}/bin/bootstrap.jar" { permission java.security.AllPermission;};
// These permissions apply to the servlet API classes// and those that are shared across all class loaders// located in the "common" directorygrant codeBase "file:${catalina.home}/common/-" { permission java.security.AllPermission;};
// These permissions apply to the container's core code, plus any additional// libraries installed in the "server" directorygrant codeBase "file:${catalina.home}/server/-" { permission java.security.AllPermission;};
// ========== WEB APPLICATION PERMISSIONS =====================================
// These permissions are granted by default to all web applications// In addition, a web application will be given a read FilePermission// and JndiPermission for all files and directories in its document root.grant { // Required for JNDI lookup of named JDBC DataSource's and
// javamail named MimePart DataSource used to send mail permission java.util.PropertyPermission "java.home", "read"; permission java.util.PropertyPermission "java.naming.*", "read"; permission java.util.PropertyPermission "javax.sql.*", "read";
// OS Specific properties to allow read accesspermission java.util.PropertyPermission "os.name", "read";permission java.util.PropertyPermission "os.version", "read";permission java.util.PropertyPermission "os.arch", "read";permission java.util.PropertyPermission "file.separator", "read";permission java.util.PropertyPermission "path.separator", "read";permission java.util.PropertyPermission "line.separator", "read";
// JVM properties to allow read access permission java.util.PropertyPermission "java.version", "read"; permission java.util.PropertyPermission "java.vendor", "read"; permission java.util.PropertyPermission "java.vendor.url", "read"; permission java.util.PropertyPermission "java.class.version", "read";
permission java.util.PropertyPermission "java.specification.version", "read";
permission java.util.PropertyPermission "java.specification.vendor", "read";
permission java.util.PropertyPermission "java.specification.name", "read";
permission java.util.PropertyPermission "java.vm.specification.version", "read";
permission java.util.PropertyPermission "java.vm.specification.vendor", "read";
permission java.util.PropertyPermission "java.vm.specification.name", "read";
permission java.util.PropertyPermission "java.vm.version", "read";permission java.util.PropertyPermission "java.vm.vendor", "read";permission java.util.PropertyPermission "java.vm.name", "read";
// Required for getting BeanInfo permission java.lang.RuntimePermission "accessClassInPackage.sun.beans.*";
// Required for OpenJMX permission java.lang.RuntimePermission "getAttribute";
// Allow read of JAXP compliant XML parser debugpermission java.util.PropertyPermission "jaxp.debug", "read";
};
// You can assign additional permissions to particular web applications by// adding additional "grant" entries here, based on the code base for that// application, /WEB-INF/classes/, or /WEB-INF/lib/ jar files.//// Different permissions can be granted to JSP pages, classes loaded from// the /WEB-INF/classes/ directory, all jar files in the /WEB-INF/lib/// directory, or even to individual jar files in the /WEB-INF/lib/ directory.
//// For instance, assume that the standard "examples" application// included a JDBC driver that needed to establish a network connection to the// corresponding database and used the scrape taglib to get the weather from// the NOAA web server. You might create a "grant" entries like this://// The permissions granted to the context root directory apply to JSP pages.// grant codeBase "file:${catalina.home}/webapps/examples/-" {// permission java.net.SocketPermission "dbhost.mycompany.com:5432", "connect";// permission java.net.SocketPermission "*.noaa.gov:80", "connect";// };//// The permissions granted to the context WEB-INF/classes directory// grant codeBase "file:${catalina.home}/webapps/examples/WEB-INF/classes/-" {// };//// The permission granted to your JDBC driver// grant codeBase "jar:file:${catalina.home}/webapps/examples/WEB-INF/lib/driver.jar!/-" {// permission java.net.SocketPermission "dbhost.mycompany.com:5432", "connect";// };// The permission granted to the scrape taglib// grant codeBase "jar:file:${catalina.home}/webapps/examples/WEB-INF/lib/scrape.jar!/-" {// permission java.net.SocketPermission "*.noaa.gov:80", "connect";// };
Starting Tomcat With A SecurityManager
Once you have configured the catalina.policy file for use with a SecurityManager, Tomcat can be
started with a SecurityManager in place by using the "-security" option:
$CATALINA_HOME/bin/catalina.sh start -security (Unix)%CATALINA_HOME%\bin\catalina start -security (Windows)
Configuring Package Protection in Tomcat
Starting with Tomcat 5, it is now possible to configure which Tomcat internal package are protected againts package definition and access. See http://java.sun.com/security/seccodeguide.html for more information.
WARNING: Be aware that removing the default package protection could possibly open a security hole
The Default Properties File
The default $CATALINA_HOME/conf/catalina.properties file looks like this:
## List of comma-separated packages that start with or equal this string# will cause a security exception to be thrown when# passed to checkPackageAccess unless the# corresponding RuntimePermission ("accessClassInPackage."+package) has# been granted.package.access=sun.,org.apache.catalina.,org.apache.coyote.,org.apache.tomcat.,org.apache.jasper.## List of comma-separated packages that start with or equal this string# will cause a security exception to be thrown when# passed to checkPackageDefinition unless the# corresponding RuntimePermission ("defineClassInPackage."+package) has# been granted.## by default, no packages are restricted for definition, and none of# the class loaders supplied with the JDK call checkPackageDefinition.#package.definition=sun.,java.,org.apache.catalina.,org.apache.coyote.,org.apache.tomcat.,org.apache.jasper.
Once you have configured the catalina.properties file for use with a SecurityManager, remember to
re-start Tomcat.
Troubleshooting
If your web application attempts to execute an operation that is prohibited by lack of a required Permission, it will throw an AccessControLException or a SecurityException when the SecurityManager
detects the violation. Debugging the permission that is missing can be challenging, and one option is to turn on debug output of all security decisions that are made during execution. This is done by setting a system property before starting Tomcat. The easiest way to do this is via the CATALINA_OPTS environment
variable. Execute this command:
export CATALINA_OPTS=-Djava.security.debug=all (Unix)set CATALINA_OPTS=-Djava.security.debug=all (Windows)
before starting Tomcat
WARNING - This will generate many megabytes of output! However, it can help you track down problems by
searching for the word "FAILED" and determining which permission was being checked for. See the Java security documentation for more options that you can specify here as well.
Another way to remove Default Tomcat Applications
Remove Default Tomcat Applications
Tomcat ships with several default web applications, found in the ${tomcat_home}/webapps directory. These defaults depend on the version of Tomcat and which installer you use.
The ROOT application contains the server's main page. Any file that you add under ${tomcat_home}/webapps/ROOT will be served.
The admin and manager applications are used for remote management. To use these applications, you must add users with roles admin and manager, respectively. The applications are then accessible from the main page, and can be used to add further users, start and stop webapps, etc. You should restrict the IP addresses that are allowed to run these applications by editing the files admin.xml and manager.xml in the ${tomcat_home}/conf/Catalina/localhost/ directory.
The servlets-examples and jsp-examples should probably be removed from a production server, to minimize security exposure. You can do this from the manager application or by deleting those directories from ${tomcat_home}/webapps.
The tomcat-docs, balancer and webdav applications are probably harmless, but can also be removed if you want.
Store Passwords as Digest
The file ${tomcat_home}/conf/tomcat-users.xml stores user names and passwords. By default the passwords are in clear text, e.g.:
<?xml version='1.0' encoding='utf-8'?><tomcat-users> <role rolename="tdsConfig"/> <role rolename="manager"/> <role rolename="admin"/> <user username="sysadmin" password="yrPassword" roles="manager,admin"/> <user username="cataloger" password="myPassword" roles="tdsConfig"/></tomcat-users>
Store them instead in digested form. First generate the digest (do this for each user):
> cd ${tomcat_home}/bin > ./digest.sh -a SHA yrPassword > yrPassword:aa01ea2afaae56c2b7da5e25ec18c505e58f12d7
If you are using DIGEST authentication, (only needed if you arent using SSL), then use {username}:{realm}:{yrPassword} instead of {yrPassword} in calculating the digest, for example sysadmin:THREDDS Data Server:yrPassword. See this for more details.
Then cut and paste the digested passwords into the tomcat-users.xml:
<?xml version='1.0' encoding='utf-8'?><tomcat-users> <role rolename="tdsConfig"/> <role rolename="manager"/> <role rolename="admin"/> <user username="sysadmin" password="aa01ea2afaae56c2b7da5e25ec18c505e58f12d7" roles="manager,admin"/> <user username="cataloger" password="5413ee24723bba2c5a6ba2d0196c78b3ee4628d1" roles="tdsConfig"/></tomcat-users>
Then change the server.xml file to tell it to use digested passwords, by adding this <Realm> element to the <Host> element named localhost:
<Host name="localhost" debug="0" appBase="/opt/tomcat/webapps" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false"> <Realm className="org.apache.catalina.realm.MemoryRealm" digest="SHA" /> ...</Host>
Separate User Roles For Restricted Datasets
The tdsConfig, manager and admin roles allow access to secure parts of Tomcat and TDS. These can only be accessed using HTTPS (TLS), and so are considered secure. If you are restricting access to datasets, you will also add other users who will have the restrictedDatasetUser role. Do not give any of these users (including yourself!) any of the tdsConfig, manager or admin roles - keep them strictly separate. This is because restrictedDatasetUser usage can also use non-HTTPS URLs, and so is vulnerable to session hijacking. By keeping the roles separate, you make sure that the worst that can happen is that someone can download some scientific data they shouldn't have access to.
Restrict Access to Tomcat Manager Applications
The best way to secure the Tomcat manager and administration webapps is to restrict the set of IP addresses that can access them. This can be accomplished by including a RemoteAddrValve (Tomcat docs) in the Context element of these applications. For instance, to only allows connections from the localhost (127.0.0.1), i.e., the machine on which the Tomcat server is running, do the following:
1. Edit ${tomcat_home}/conf/Catalina/localhost/admin.xml. It will probably look something like this:
2. <Context antiResourceLocking="false" privileged="true" />
Change it to include the highlighted line here:
<Context antiResourceLocking="false" privileged="true"> <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.0\.0\.1"/></Context>
3. Edit ${tomcat_home}/conf/Catalina/localhost/manager.xml and add the same line: 4. <Context antiResourceLocking="false" privileged="true">5. <Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="127\.0\.0\.1"/>6. </Context>
NOTE: The value of the allow attribute must be a comma separated list of regular expressions used to match against the remote client's IP address. Here are several examples:
allow="128\.117\.140\.62" allow="128\.117\.140\.62,128\.117\.140\.63,128\.117\.140\.99"
allow="128\.117\.140\..*"
Similarly, you can use the RemoteHostValve to filter by host name. Again, the value of the allow and deny attributes must be a comma separated list of regular expressions which will be used to match against the remote client's host name. For instance:
<Valve className="org.apache.catalina.valves.RemoteHostValve" allow=".*\.ucar\.edu"/>
Java Security Manager
An additional level of security can be provided by running Tomcat with the Java Security Manager turned on. This can provide fine-grained security policies, at the cost of complexity in understanding what rights are needed to do any useful work, and how to grant them. This is needed if you allow untrusted servlets or JSPs to execute on your machine.