Back | Next | Contents Cams Web Agent Guide

Tomcat 4 Web Agent

Cams web agents are integrated into web and application servers to protect the resources that they provide. When a user's web browser makes a request to a web or application server, the Cams web agent asks a Cams policy server if access is granted or denied. The Cams web agent enforces the response, including prompting for user authentication if required.

This document provides instructions on how to install and configure the Cams Tomcat 4 web agent. The Cams Tomcat 4 web agent is a Tomcat version 4.x valve and realm implementation.

NOTE: For known issues with the Cams Tomcat 4 web agent, see ReleaseNotes.html found in the root directory of the Cams Tomcat 4 web agent distribution.

Installation

These instructions guide you through the installation of Cams Tomcat 4 web agent on a system with Tomcat already installed. If Tomcat is not yet installed, you must first do so. You must also download the Cams Tomcat 4 web agent. If you are not a currently registered customer or evaluator, you will also need to request an evaluation license.

You must unpack the download (cams-webagent-tomcat4-2.0.X.tar.gz or cams-webagent-tomcat4-2.0.X.zip) into a temporary directory, then copy Cams directories and files to your Tomcat installation tree. In the instructions that follow, environment variable CATALINA_HOME corresponds to your Tomcat 4.X installation home directory.

NOTE: The Cams Tomcat 4 web agent distribution extracts into a version-specific directory tree. So, extracting to directory /tmp would result in a tree of files like /tmp/cams-webagent-tomcat4-2.0.X/...

Step 1: Extract the Cams Tomcat 4 web agent Files

Linux/UNIX

cd /tmp
tar xvfz cams-webagent-tomcat4-2.0.X.tar

Windows

cd C:\temp
pkunzip cams-webagent-tomcat4-2.0.X.zip

Change directories to the cams-webagent-tomcat4-2.0.X directory (or whatever directory was created). Files like those shown in Figure 1 should have been extracted.

<!-- Cams Tomcat 4 web agent documentation and license -->
README.txt
LICENSE
ReleaseNotes.html

<!-- Cams Tomcat 4.1 patch files -->
classes/org/apache/catalina/mbean/mbeans-descriptor.xml
<!-- Cams Tomcat 4 web agent configuration file and sample Tomcat server.xml --> conf/cams-webagent.conf conf/cams-tomcat-server.xml <!-- Cams Tomcat 4 web agent Java libraries --> lib/cams-common.jar lib/cams-webagent-tomcat4.jar lib/cams.jar lib/cscore.jar lib/infinitemonkey.dll lib/InfiniteMonkey.jar lib/InfiniteMonkeyLicense.txt lib/log4j.jar <!-- Cams Tomcat 4 web agent denied, error, and login pages --> cams/cams-webagent-test.jsp cams/denied.jsp cams/error.jsp cams/login.jsp cams/secured-by-cams.gif cams/WEB-INF/web.xml
Figure 1 - Directory listing of the Cams Tomcat 4 web agent files after extraction

Step 2: Copy Cams Tomcat 4 web agent Files to CATALINA_HOME

Linux/UNIX

cd cams-webagent-tomcat4-2.0.X
cp -r cams $CATALINA_HOME/webapps
cp -r conf $CATALINA_HOME
cp -r lib $CATALINA_HOME/server

Windows

cd cams-webagent-tomcat4-2.0.X
xcopy cams %CATALINA_HOME%\webapps\cams /S /I
xcopy conf %CATALINA_HOME%\conf
xcopy lib %CATALINA_HOME%\server\lib

WARNING: If using JDK 1.3.x you must configure a cryptography provider for your JRE. The Java Cryptography Extension(JCE) 1.2.x should be installed. To configure a JCE provider open the Java security file JRE_HOME/lib/security/java.security and add the following line:

security.provider.n=com.sun.crypto.provider.SunJCE

Where n is the order in which the providers are looked up (e.g., 1, 2, 3).

Tomcat 4.1.x Issues

Release 4.1.x of Tomcat introduces the use of Java JMX MBeans (MBeans) in the new administrator application. To support the Tomcat 4.1.x administrator application, MBeans support is enabled by default in Tomcat's server.xml configuration file. If you start Tomcat 4.1.x after installing Cams, exceptions will be thrown with the default configuration. You have two options. Option 1 is to disable MBeans support in server.xml (and thereby disable the administrator webapp) by commenting out the corresponding entries as shown in Figure 2.

<!-- Comment out these entries to disable JMX MBeans support 
<Listener className="org.apache.catalina.mbeans.ServerLifecycleListener"
debug="0"/>
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"
debug="0"/> -->
Figure 2 - Use of comments to disable MBeans support in server.xml

Option 2 is to modify Tomcat's mbeans-descriptor.xml file to reference the Cams Tomcat web agent and realm. The original Tomcat 4 mbeans-descriptor.xml file is found in server/lib/catalina.jar. You DO NOT need to remove it. If Tomcat 4 finds server/lib/classes/org/apache/catalina/mbeans/mbeans-destriptor.xml first, it will be used instead. The Cams Tomcat web agent includes a version of mbeans-descriptor.xml with the required modification. To use it, enter:

Linux/UNIX

cd cams-webagent-tomcat4-2.0.X
cp -r classes/ $CATALINA_HOME/server/classes/

Windows

CD cams-webagent-tomcat4-2.0.X
xcopy classes\ %CATALINA_HOME%\server\classes\

The modified version contains the descriptors shown in Figure 3. You can alternatively insert these descriptors yourself into mbeans-descriptor.xml.

...

<mbean    name="CamsRealm"
className="org.apache.catalina.mbeans.ClassNameMBean"
description="Cams implementation of valid users, passwords, and roles"
domain="Catalina"
group="Realm"
type="com.cafesoft.security.webagent.tomcat4.CamsRealm">
  <attribute name="className"
      description="Fully qualified class name of the managed object"
             type="java.lang.String"
        writeable="false"/>
  <attribute name="debug"
      description="The debugging detail level for this component"
             type="int"/>
</mbean>
<mbean   name="CamsTomcatWebAgent"
    className="org.apache.catalina.mbeans.ClassNameMBean"
  description="Valve that performs access control, authentication,  				
               session access, and session control"
       domain="Catalina"
        group="Valve"
         type="com.cafesoft.security.webagent.tomcat4.CamsTomcatWebAgent">
 <attribute name="className"
     description="Fully qualified class name of the managed object"
            type="java.lang.String"
       writeable="false"/>
 <attribute name="debug"
     description="The debugging detail level for this component"
            type="int"/>
</mbean>

...
Figure 3 - MBeans descriptors for Cams Tomcat 4 web agent and realm

Using these descriptors eliminate the exceptions thrown at Tomcat startup, however, they do not enable the Cams Tomcat 4 web agent and realm to be managed by the Tomcat administrator webapp.

NOTE: Cams Tomcat web agent testing has been performed against Tomcat versions 4.1.12, 4.1.18, and 4.1.24.

Web Agent Configuration

The Cams Tomcat 4 web agent is configured in cams-webagent.conf. In addition, you also need to edit the Tomcat server.xml file and integrate the Cams login.jsp, error.jsp, and denied.jsp pages.

NOTE: To secure resources on your Tomcat server, you'll also need to configure a Cams security domain. See the Cams Policy Server Configuration section in this document for more information.

Editing cams-webagent.conf

Open the cams-webagent.conf file in a text editor. The file contains comments to help you understand the property values that you may need to change, as shown in Table 1.

Name Description
cams.cluster.name

The name of the Cams cluster to which this agent will delegate requests. This value is used to identify Cams session cookies originating from a Cams cluster installation. The default value is MyCamsCluster

NOTE: Every Cams policy server is a member of a cluster, even if the cluster contains only a single server.

cams.server.url.<server-name>

The URL of a Cams policy server to be used. The actual name of the configuration property will depend on the Cams policy server name. For example:

  • cams.server.url.MyCamsServer=cams://myCamsServer.mycompany.com:9191

One property must exist for each Cams policy server in your cluster. For example, the following properties configure an agent for a two node Cams policy server cluster:

  • cams.server.url.Orville=cams://orville.wrightbrothers.com:9191
  • cams.server.url.Wilbur=cams://wilbur.wrightbrothers.com:9191

Each URL has the form: cams://host:port, where host is a host name or an IP address. For example:

  • cams.server.url.MyCamsServer=cams://myCamsServer.mycompany.com:9191
  • cams.server.url.MyCamsServer=cams://192.168.1.123:9191

WARNING: If the Cams Tomcat 4 web agent and Cams policy server communicate through a firewall, the firewall must be configured to allow general TCP/IP traffic on the configured Cams policy server port.

cams.heartbeat.interval The interval (in seconds) the Cams Web Agent will send heartbeat messages to the Cams Policy Server to ensure it's availability.
cams.cluster.debug

Toggle on/off clustering debug messages.

WARNING: Turning on debug can have an adverse affect on Cams web agent performance.

cams.debug

Toggle on/off debug messages.

WARNING: Turning on debug can have an adverse affect on Cams web agent performance.

cams.error.url

The relative or fully qualified URL to redirect to if an error occurs during authentication or when accessing a protected resource.

WARNING: The access control policy must ensure that access to the error page is granted.

cams.denied.url

The relative or fully qualified URL to redirect to if access to a protected resource is denied by the Cams policy server.

WARNING: The access control policy must ensure that access to the denied page is granted.

cams.login.uri

The Cams Tomcat 4 web agent will interpret POST requests to this exact URI as a login (authentication) request. The login URI can be on a different system from the one making the request.

Posted parameters (usually hidden fields) MUST include:

  • cams_security_domain
  • cams_login_config
  • cams_original_url

and will also usually include callback parameters used by Cams policy server login modules. For example:

  • cams_cb_username
  • cams_cb_password

The actual callback parameters posted must match those expected by the callback handler login module configured with the specified security domain/login config entry.

cams.logout.uri

The Cams Tomcat 4 web agent will interpret any request to this exact URI as a logout request. The logout URI can be on a different system from the one making the request.

Because a given user may be logged into multiple security domains simultaneously, the web page referencing this URI must specify the security domain name associated with the logout request as a query parameter. For example, if a webagent hosted on web server www.mysite.com has:

cams.logout.uri=/cams/logout

then the following request will attempt to logout the user that is logged into security domain system:

http://www.mysite.com/cams/logout?cams_security_domain=system

cams.after.logout.url The URL to which a user is directed AFTER successful logout. This might be a web site or portal home page.
cams.loginconfig.entry The login-config-entry to use to authenticate clients. This value corresponds to a login-config-entry that is defined in the corresponding security domain's login-config.xml file, which defines the login modules, callback handler, and any login parameters. Typically, the type value http is used for web resources.
cams.access.check.cache Enable/disable the access control check cache. Caching improves performance by enabling the web agent to remember a previous access control check Cams policy server response for a specified period of time. The Cams Servlet Filter web agent currently caches ONLY responses associated with unconditionally granted resources. This enables general resources like GIF and JPEG image files, javascript, style sheets, to avoid unnecessary access control checks. Access to a resource protected by a Cams access control policy is unconditionally granted if the permission matching the resource directly referencse a Cams intrinsic access control rule.
cams.access.check.cache.size The maximum number of access control responses that can be cached at a given time. Once the cache is full, newly cached responses will eject the least recently used cached response.
cams.access.check.cache.refreshTime The amount of time, in minutes, that is allowed before an access control request is sent to the Cams policy server to check if the cache should be cleared. This ensures that Cams web agent can detect changes to a Cams access control policy within this period, forcing the cache to be flushed if necessary.
cams.session.cache Enable/disable session caching. Session caching enables the servlet API and cgi-bin applications to access Cams session attributes such as HTTP request header values.
cams.session.hijacking.protection.enable

Enable/disable Cams session hijacking protection. Use true to enable and false to disable hijacking protection. An extra hash value is appended to the base session identifer and validated each time a Cams session id cookie value is received. Unless the request is received from an HTTP browser with the same HTTP request headers (Accept-Language and User-Agent) the session is considered
hijacked and is invalidated by the agent. A WARNING is written to the web agent log. The default value is true.

cams.session.hijacking.protection.algorithm

The message digest algorithm used to compute a unique hash value for hijacking protection. The following algorithms are supported:

  • sha1 (recommended)
  • md5
cams.session.hijacking.protection.salt

A unique site value combined as an ingredient with all other session and HTTP request header parameters to ensure that the message digest hash value is unique for a given deployment environment. The default value is epsom.

NOTE: Choose a value unique to your site for maximum protection.

cams.http.headers Enable/disable setting of Cams HTTP request headers. If enabled web pages, servlets, JSPs, and cgi-bin scripts will have access to HTTP request headers. See the Cams Programmer's Guide - Webapp Programming for a full list of the HTTP request header names and site-specific user attribute values that can be made available to web applications. Disabling Cams request headers when not used improves performance.
cams.http.headers.accept.proxied Enable the agent to accept CAMS HTTP Headers that have been proxied to this web agent via another Cams web agent. The default value is false.
cams.client.authentication.type

The type of authentication the Cams Tomcat 4 web agent will use to authenticate connections that it establishes with the Cams policy server. Currently supported types include:

  • EncryptedParameters - Used in conjunction with cams.skey.* values to encrypt the agent username, password, Cams cluster name, and Cams policy server name sent to the Cams policy server. Authentication is performed on parameters, including the username, password, and agent-configured cluster name and policy server name.
  • EncryptedUsernamePassword - Used in conjunction with cams.skey.* values to encrypt the agent username and password sent to the Cams policy server
  • UsernamePassword - A clear text username and password are supplied for authentication (not recommended, but useful for debugging

NOTE: This is NOT the authentication type used to authenticate users, it is the type used to authenticate the Cams web agent.

cams.client.authentication.principal The principal (or username) the Cams Tomcat 4 web agent will use to authenticate connections it establishes with the Cams policy server.
cams.client.authentication.credential The credential (or password) the Cams Tomcat 4 web agent will use to authenticate connections it establishes with the Cams policy server.
cams.client.authentication.timeout The maximum time (in seconds) that the Cams Tomcat 4 web agent will wait for a response from the Cams policy server. If a response has not been returned by the Cams policy erver within the allotted timeout period authentication fails.
connection.pool.lazyConnect The lazyConnect value is a boolean flag. If the value of the property is true the Cams web agent will not attempt to connect to the Cams policy server until a request has been made. If the value of the property is false the Cams web agent will connect to the Cams policy server immediately.
connection.pool.maximum The maximum is the maximum number of Connections the Cams web agent is allowed to have with a Cams policy server.
connection.pool.socket.maximum The maximum number sockets allowed on a particular Connection. This value can be increased to allow for more data to be sent across a single connection. However, it is not recommended that this value exceed 20.
cams.skey.algorithm

The algorithm to be used when encrypting and decrypting selected values sent to/received from the Cams server. Valid values include: None, Blowfish, DES, and DESede (triple DES). If None, then selective encryption is disabled. Blowfish uses a 16 byte encryption key, DES uses an 8 byte key, and DESede uses a 24 byte key.

For more information, see: Cams Administrator's Guide - Securing Cams Communications using Secret Keys.

cams.skey.key The secret encryption/decryption key in hexidecimal format. The actual number of bytes used depends on the algorithm, although it is legal to supply more key bytes than needed.

cams.skey.iv

The encryption/decryption initialization vector in hexidecimal format. This should be an 8 byte (16 hex digit) value.

logger.class (REQUIRED) The fully qualified Java classname of the Logger to use.
logger.file.path

(REQUIRED) The fully qualified log file path.

NOTE: You should use a fully qualified path. If the directory(s) specified is missing, it will be created.

logger.file.append (OPTIONAL) If true new log messages will be appended to the current log file. If false the current log file will be deleted and a new log file will be created. The default is true.
logger.file.bufferedIO (OPTIONAL) If true the logger will buffer log messages before writing them to the log file. This can significantly improve logging performance. The default is true.
logger.file.bufferSize (OPTIONAL) Indicates the size of the buffer to fill before writing to the log file. The default is "4096".
logger.file.maxSize

(OPTIONAL) The maximum size the logfile is allowed to grow before creating a new logfile. Suffixes KB, MB, and GB are recognized. When log files are rolled over, the file name is appended with an numeric digit like 1, 2, 3, etc. The default is "4MB".

logger.file.maxBackupIndex (OPTIONAL)The maximum rollover file index. When log files are rolled over, a numeric index is appended to the name, starting with 1 and proceeding to this value. The default is 100.
logger.enableConsole (OPTIONAL) If true all log statements that are sent to the log file are also sent to the console. The default is false.
logger.enableDebugFilter (OPTIONAL) If true all log statements that have the level "DEBUG" will not be logged. The default is false.
logger.verbose (OPTIONAL) If true all DEBUG, INFO, WARN, ERROR, and FATAL messages logged will contain the following format:

[INFO ] Sample log message
Class Name: com.cafesoft.cams.log.CamsTraceLogger
Method Name: info()
Line Number: 121
Timestamp: 25 Jul 2002 11:02:36,339

If false ONLY WARNING, ERROR, and FATAL message level will use the verbose format, while DEBUG and INFO level messages will use the following format:

[INFO ] Sample Log Message

The default is false.

logger.debug (OPTIONAL) If true the logger will output diagnostic debug statements to the System.err stream. The default is false.

Table 1 - Values you may need to edit in cams-webagent.conf

The other properties in this file configure debug and the Cams message protocol. You should not change the message protocol values unless instructed to do so by Cafésoft support.

Editing server.xml

You are now ready to edit Tomcat's server.xml. Before making changes, you should backup your existing server.xml.

You can copy conf/cams-tomcat-server.xml to conf/server.xml. In this case, you should not have to edit server.xml and can skip to the next section.

To use an existing server.xml file you must insert the tags that invoke the Cams Tomcat 4 web agent and remove or comment-out any potential conflicts. First, the following text should be inserted within the <engine> block of the service to be protected (typically the Tomcat-Standalone service):

<Valve className="com.cafesoft.security.webagent.tomcat4.CamsTomcatWebAgent"
configPath="${catalina.home}/conf/cams-webagent.conf"
contextClass="com.cafesoft.security.common.agent.StandardCamsAgentContext"/>

If you plan to use J2EE Servlet security API's (see the Cams Programmer's Guide - Webapp Programming) then you will additionally need to insert the Cams Tomcat realm. The following text should be inserted directly below the Cams Tomcat 4 web agent.

<Realm className="com.cafesoft.security.webagent.tomcat4.CamsRealm"/>

See CATALINA_HOME/conf/cams-tomcat-server.xml for an example. Any conflicting Tomcat container security should be removed or commented out. For example, by default, the Tomcat-Standalone service ships with the MemoryRealm enabled. Comment-out the MemoryRealm by placing the XML closing comment tag after the Realm tag:

<!-- Because this Realm is here, an instance will be shared globally
<Realm className="org.apache.catalina.realm.MemoryRealm" />
-->

The Cams Tomcat 4 web agent is implemented as a Tomcat valve that must be inserted into the engine request pipeline for each service it protects. You may need multiple insertions if your Tomcat installation uses multiple services and engines. For example, Tomcat by default includes with the Tomcat-Standalone and Tomcat-Apache services. To use both, you would remove or comment-out the MemoryRealm in both services and add the Cams Tomcat 4 web agent valve and realm to each.

Provided you have already configured a Cams security domain, you should now be ready to test this Cams Tomcat 4 web agent installation. An self-documented test page is provided with the cams webapp that you can use for testing.

WARNING: You may have enabled other Tomcat security realms such as a JDBCRealm or LDAPRealm. To avoid security policy conflict, you should remove native Tomcat security from resources protected by Cams. Also, you should remove all Tomcat security tags from each webapp's web.xml descriptor file.

Securing Directories and Files

If you have not done so already, you should secure important Tomcat configuration and log directories. They may contain Tomcat SSL certificates, configuration files containing passwords or secret keys, and log files containing sensitive information.

In a typical production environment, the Tomcat server is started and executed by the administrative root user (Unix) or Administrator user (Windows NT/2000/2003). The general strategy for securing Cams-related configuration files and directories is to:

  1. Ensure that the Tomcat server is executed as the appropriate administrative user (root or Administrator), hereafter referred to as the owner. This enables the Cams Tomcat 4 web agent to run within the secured file and directory environment described below.
  2. Enable owner read/write/execute permissions on all directoris containing Cams files, but no permissions for all other users and groups. This enables owner processes to scan and modify the contents of directories, while prohibiting all other users and groups from seeing or modifying the contents of these directories.
  3. Enable owner read/write permissions on configuration files and log files, but no permissions for all other users and groups. This ensures that an arbitrary user cannot replace, overwrite, or redirect log files to obscure security violations or obtain sensitive information via trace logs.

The following sections provide operating system-specific instructions for securing Cams Tomcat 4 web agent files and directories in the Tomcat environment.

Linux/UNIX Directories and Files

In the instructions that follow, it is assumed that the Tomcat server is executed by root on your Linux/UNIX system. For the sake of this example, assume that:

  1. Tomcat is installed at /usr/local/jakarta-tomcat, hereafter referred to as CATALINA_HOME
  2. The Tomcat configuration directory is at CATALINA_HOME/conf
  3. The Tomcat logs directory is at CATALINA_HOME/logs
  4. That you are logged in as root

As is the case with any command that root executes, you must take care that it is protected from modification by non-root users. Not only must the files themselves be writable only by root, but so must the directories, and parents of all directories. It is assumed that /, /usr, and /usr/local are only modifiable by root. When you install the Tomcat server, you should ensure that it is similarly protected.

The following steps can help you protect sensitive information stored in Cams Tomcat 4 web agent configuration and/or log files.

Step 1 - Change directories to the Tomcat installation directory
cd /user/local/jakarta-tomcat
Step 2 - Set user and group ownership for the conf and logs directories
chown root.root conf conf/cams-webagent.conf
chown root.root logs logs/*

This command sets user and group ownership to root for the specified directories and files.

Step 3 - Set file and directory permissions
chmod 700 conf logs
chmod 600 conf/cams-webagent.conf logs/*

The first command sets read/write/execute permissions that enable only owner access to the conf and logs directories. The second command sets read/write permission for the owner of the cams-webagent.conf file and log files. No other users or groups are given any permissions.

Windows Directories and Files

In the instructions that follow, it is assumed that the Tomcat server is executed by Administrator on your Windows NT/2000/2003 system. For the sake of this example, assume that:

  1. Tomcat is installed at C:\jakarta-tomcat, hereafter referred to as CATALINA_HOME
  2. The Tomcat configuration directory is at CATALINA_HOME\conf
  3. The Tomcat logs directory is at CATALINA_HOME\logs
  4. You are logged in as Admininistrator to your Windows NT/2000/2003 server or domain controller

As is the case with any command that Admin executes, you must take care that it is protected from modification by non-Admin users. Use the following steps to secure Cams Tomcat webagent-related directories and files:

Step 1 - Set user and group ownership of all files and directories

This is done using the Windows NT/2000/2003 graphical user interface.

  1. Using the Windows Explorer file browser, select the top-level Tomcat installation directory: C:\jakarta-tomcat
  2. Right click on the folder and select Properties from the pop-up menu
  3. In the dialog box that appears, select the Security tab
  4. Click on the Ownership button
  5. In the dialog box that appear, confirm that Administrators is the intended owner, then click Take Ownership
Step 2 - Set all directory and file permissions

From the same Security tab in the context-sensitive dialog box for directory C:\jakarta-tomcat used in Step 1:

  1. Click on the Permissions button
  2. In the Directory Permissions dialog box that appears, confirm that the directory Owner is Administrators
  3. Select check box Replace Permissions on Subdirectories (e.g., make sure it is checked)
  4. Select check box Replace Permissions on Existing Files (e.g., make sure it is checked)
  5. In the list of all User\Group items listed, Remove all items except Administrator
  6. Select the list item Administrator, then select Type of Access = Full Control

Java Server Pages

The distribution cams directory includes four sample Java Server Pages (JSP):

cams-webapp-test.jsp

You should browse to cams-webagent-test.jsp to understand how to configure and use it for testing. The page is posted to the URI specified by the cams.login.uri property in cams-webagent.conf along with the following form name/value pairs:

When you click the submit button, the Cams Tomcat 4 web agent intercepts the POST to the cams.login.uri and sends the request to a Cams policy server. The request includes the security domain and a login-config-entry, which a Cams policy servers will use to attempt login. If you successfully authenticate and are authorized (depending upon how you configure the security domain), the browser is redirected to the cams_orginal_url and user specific information is displayed by cams-webagent-test.jsp.

login.jsp

When you request a protected resource that requires authentication and Cams doesn't know your user identity, the Cams Tomcat 4 web agent displays a login page as specified by the login-parameters in a security domain's login-config.xml file. The login page is identical to index.jsp, except that the hidden values are dynamically populated as shown in Example 1.

WARNING: You must correctly configure the login-parameters in the security domain's login-config.xml file or the login page will not be displayed. See the Cams Administrator's Guide - Login Configuration for more information on configuring login-parameters in login-config.xml.

<!-- Populate hidden fields from their request parameters -->
<input type="hidden" name="cams_security_domain" 
                    value="<%= request.getParameter("securityDomain") %>">
<input type="hidden" name="cams_login_config"    
                    value="<%= request.getParameter("loginConfig") %>">
<input type="hidden" name="cams_original_url"
                    value="<%= request.getParameter("originalUrl") %>">
Example 1 - login.jsp example login page

The difference between cams-webagent-test.jsp and login.jsp are that you arrive at the former lazy authentication login page after requesting a resource for which your identity is unknown to the Cams policy server. Because of the resource request, Cams knows the security domain and login-config-entry to which the resource belongs (and, of course, the original URL).

denied.jsp

If you are denied access to a resource by Cams, the page specified by the cams.denied.url property in cams-webagent.conf is displayed. Example 2 shows a script that displays dynamic messages.

<!-- Display any dynamic access denied messages -->
<%
			
	String message = null;
			
	message = request.getParameter("message");
	if(message != null)
	{
%>

 <p class=error><%= message %></p>
<%
	} 
%>
Example 2 - denied.jsp displays any dynamic access denied messages

error.jsp

If an error occurs, Cams displays the page specified by the cams.error.url property in cams-webagent.conf. Example 3 shows a script that displays dynamic messages.

<!-- Display any dynamic error messages -->
<%
			
	String message = null;	
	message = request.getParameter("message");
	if (message != null)
	{
%>

 <p class="error"><%= message %></p>
<%
	} 
%>
Example 3 - error.jsp example displays any dynamic error messages

NOTE: In order to ensure that the browser does not cache these pages, it is important that you use the following HTML Meta tags in the HEAD section of each page:

<meta http-equiv="Pragma"        content="no-cache">
<meta http-equiv="Cache-Control" content="no-cache">   		
<meta http-equiv="Expires"       content="-1">

Optimizations

The Cams Tomcat 4 web agent installs with default configuration properties. However, you may find it beneficial to configure your installation to more adequately meet the requirements of your environment. See Cams Web Agent Optimizations to learn more about Cams Tomcat 4 web agent optimizations.

Cams Policy Server Configuration

Before you start the Tomcat server with a Cams Tomcat 4 web agent, you'll need to ensure that the Cams policy server knows about it. See Web Agent-specific Cams Policy Server Configuration to learn more about Cams policy server configuration requirements.

Testing

That's it, you should now be able to start Tomcat to test your Cams Tomcat 4 web agent configuration. After you've started both Tomcat with the Cams Tomcat 4 web agent and the Cams policy server, test the configuration using:

http://[hostname:port]/cams/cams-webagent-test.jsp

Login to an account in the security domain that you've established. See the test page for more configuration and testing information.

Back | Next | Contents