| Back | Next | Contents | Cams Web Agent Guide |
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, possibly prompting the user for authentication if required.
This document provides instructions on how to install and configure the Cams Apache 1.3 web agent, which is an Apache version 1.3 module available for the following operating systems and hardware architectures:
If you need support for another operating system or hardware architecture, please contact Cafésoft support.
NOTE: For known issues with the Cams Apache 1.3 web agent, see ReleaseNotes.html found in the root directory of the Cams Apache web agent distribution.
These instructions guide you through the installation of Cams Apache 1.3 web agent on a system with Apache 1.3.x already installed. If Apache is not yet installed, you must first do so. You must also download the Cams Apache web agent. You can choose between the EAPI and non-EAPI versions. EAPI is the Apache's Extended API required by mod_ssl. If your Apache web server was compiled with EAPI, you need to use cams-webagent-apache13-linux-i386-eapi-2.0.X.tar.gz. If not, use cams-webagent-apache13-linux-i386-2.0.X.tar.gz. To see the options used when your Apache server was compiled, enter:
httpd -V
The Cams Apache web agent requires the installation of OpenSSL libraries on your system to encrypt sensitive values sent to the Cams policy server. If you are using the EAPI version of Apache, OpenSSL is already installed on your system. However, if you are NOT using the EAPI version of Apache and OpenSSL is not installed, you will need to do so before proceeding. Please consult the documentation that came with your operating system distribution for installation instructions.
The following command can be used from a Unix command shell to look for existing OpenSSL libraries:
ls -laF /usr/lib/libssl*
If OpenSSL is installed, you should see a listing that looks something like this:
lrwxrwxrwx 1 root other 15 Jan 28 16:40 /usr/lib/libssl.so -> libssl.so.0.9.7*If OpenSSL is not installed in directory /usr/lib, it may be installed in directory /lib. In that case, try the following command:
ls -laF /lib/libssl*
NOTE: On some Unix/Linux installations, /lib is a symbolic link to /usr/lib, so they essentially represent the same directory.
Although OpenSSL version 0.9.7 is recommended, patched copies of 0.9.6 may also be used. Appropriate symbolic links will be setup by the Cams Apache 1.3 installation script if required.
OpenSSL also includes a cryptography library that is needed by the Cams Apache 1.3 web agent. The cryptography library version must be the same as the SSL library version. The following command can be used to confirm its availability:
ls -laF /usr/lib/libcrypto*
or
ls -laF /lib/libcrypto*
If the OpenSSL cryptography library is installed, you should see a listing that looks something like this:
lrwxrwxrwx 1 root other 18 Jan
28 16:40 /usr/lib/libcrypto.so -> libcrypto.so.0.9.7*
-rwxr-xr-x 1 root other 1311816 Feb 10 13:59 /usr/lib/libcrypto.so.0.9.7*
These instructions assume you are using the Linux/EAPI version. Substitute the appropriate file name for your operarting system and hardware architecture. You'll need to copy cams-webagent-apache13-linux-i386-eapi-2.0.X.tar.gz to a temporary directory on the target host. You must login as root and navigate to the directory where you copied the cams-webagent-apache13-linux-i386-eapi-2.0.X.tar.gz file and unpack it into the temporary directory.
cd /tmp
gunzip cams-webagent-apache13-linux-i386-eapi-2.0.X.tar.gz
tar xvf cams-webagent-apache13-linux-i386-eapi-2.0.X.tar
Change directories to the directory cams-webagent-apache13-linux-i386-eapi-2.0.X. The files shown in Figure 1 should have been extracted from the distribution.
<!-- Cams Apache web agent documentation and license --> README.txt LICENSE ReleaseNotes.html install-webagent.sh <!-- Cams Apache web agent cgi-bin files --> cgi-bin/cams-denied.sh cgi-bin/cams-error.sh cgi-bin/cams-login.sh cgi-bin/cams-webagent-test.sh <!-- Cams Apache 1.3 web agent configuration files --> conf/cams-webagent.conf conf/webagent.properties conf/access-control.properties <!-- Cams Apache 1.3 web agent libraries (NOTE: Some file names may differ) --> lib/mod_cams_apache13.so lib/libcams.so.0 lib/libcamsclient_mt_cams_1_0.so.0 lib/libcams-common.so.0 lib/libcscore.so.0 lib/libcscrypto.so.0.9.6 lib/libcscrypto.so.0.9.7 lib/libapr-0.so.0.9.4 |
| Figure 1 - Directory listing of the Cams Apache web agent files after unpacking |
The target directories into which these files are copied may be a function of both the versions of Unix/Linux and Apache you are using. For example, the RedHat Linux 7.x RPM installs:
/etc/httpd/conf - the Apache configuration files
/etc/httpd/modules - the Apache modules
/var/www/cgi-bin - the Apache cgi-bin scripts
/var/www/html - the web pages
However, the standard Apache installation uses directories:
/usr/local/apache/conf - the Apache configuration files
/usr/local/apache/libexec - the Apache modules
/usr/local/apache/cgi-bin - the cgi-bin scripts
/usr/local/apache/htdocs - the web pages
The installation script attempts to find the directories listed above, sometimes with your help. It then removes or backs up any previous Cams Apache web agent files it finds and copies the new files to the target locations you specify. If you want to run the installation script, do it now and skip to the Web Agent Configuration section:
cd /tmp/cams-webagent-apache13-linux-i386-eapi-2.0.X/
./install-webagent.sh
Follow the prompts to provide required information.
The Cams Apache web agent is configured in the cams-webagent.conf file. However, you'll also need to edit Apache's httpd.conf file and integrate Cams login, error, and denied shell pages.
NOTE: To secure resources on your Apache web server, you'll also need to configure a Cams security domain. See the Cams Policy Server Configuration section in this document for more information.
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 Cams web 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 Cams policy 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:
One property must exist for each Cams policy server in your cluster. For example, the following properties configure a Cams web agent for a two node Cams policy server cluster:
Each URL has the form cams://host:port, where host is a host name or an IP address. For example:
WARNING: If the Cams Apache web agent and Cams policy server communicate via 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 a Cams policy server. WARNING: The access control policy must ensure that access to the denied page is granted. |
| cams.login.uri |
The Cams Apache 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:
and will also usually include callback parameters used by Cams policy server login modules. For example:
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 Apache 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 Apache 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.max_record_size | The maximum number of bytes that can be used to cache an access cotnrol response. Currently, the only variable length value returned from an AccessControlResponse and cached is the security domain name. Consequently, 20 bytes plus the maximum security domain name length is large enough for a record, which is stored in shared memory for access by all Apache child processes. A value of 50 (bytes) should be sufficient for most installations. |
| 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 policy server session attributes as HTTP Request header values. |
| cams.session.cache.max_sessions | The maximum number of sessions to cache. After this number is exceded the oldest sessions will be deleted first. |
| cams.session.cache.max_record_size | The maximum number of bytes used for storing a session. If the maximum is exceeded, a warning message is displayed and data is truncated (e.g., some attributes may be lost). |
| 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 |
| cams.session.hijacking.protection.algorithm |
The message digest algorithm used to compute a unique hash value for hijacking protection. The following algorithms are supported:
|
| 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. |
| connection.authentication.type |
The type of authentication the Cams Apache web agent will use to authenticate connections that it establishes with the Cams policy server. Currently supported types include:
NOTE: this is NOT the authentication type used to authenticate users, it is the type used to authenticate the agent. |
| connection.authentication.principal | The principal (or username) a Cams Apache web agent will use to authenticate connections it establishes with a Cams policy server. |
| connection.authentication.credential | The credential (or password) a Cams Apache web agent will use to authenticate connections it establishes with a Cams policy server. |
| connection.start.timeout |
The number of seconds a Cams Apache web agent will wait for a connection to a Cams policy server to start before aborting the attempt. |
| connection.authentication.timeout | The maximum time (in seconds) that a Cams Apache web agent will wait for a response from a Cams policy server. |
| connection.checkAccess.timeout |
The number of seconds a Cams Apache web agent will wait for a response from a Cams policy server when attempting to authenticate itself before timing out. |
| 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.file.path | The fully qualified log file path. |
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.
You are now ready to edit Apache's httpd.conf file. Before proceeding, make sure that Apache is correctly working on the installation system by starting the Apache server and browsing to a test page. If not, see the Apache documentation for troubleshooting. Before making changes to httpd.conf, you should backup your existing file.
The integration of the Cams Apache web agent module requires the addition of commands to load the module. Open the /etc/httpd/conf/httpd.conf file in a text editor and navigate to the Dynamic Shared Object (DSO) Support section where the modules are loaded. Then, add the following lines at the end of the module loading section:
#
# Load Cams Apache web agent module
#
LoadModule cams_apache13_module modules/mod_cams_apache13.so
The next secition is typically where you add the modules. At the end of this section, add the following lines:
#
# Add Cams Apache web agent module and configuration file
#
AddModule CamsApache13WebAgent.c
CamsWebAgentConfigFile /etc/httpd/conf/cams-webagent.conf
Example 1 shows and typical configuration from httpd.conf included with RedHat 7.3. The inserted lines are in red.
#
|
| Example 1 - Cams Apache web agent httpd.conf model loading |
Provided you have already configured a Cams security domain, you should now be ready to test this Cams Apache 1.3 web agent installation. A self-documented test page is provided in the cgi-bin directory that you can use for testing.
NOTE: Due to the large number of Apache modules, testing all combinations of module loading is impossible. If you experience difficulty loading the Cams Apache web agent module, try changing the module loading order.
WARNING: To avoid security policy conflicts, you should disable Apache security specified in httpd.conf for all resources that are protected by Cams.
If you have not done so already, you should secure important Apache configuration and log directories and files which may contain Apache SSL certificates, configuration files containing passwords or secret keys, and log files containing sensitive information.
In most cases, the Apache 1.3.x web server process is started under root ownership and creates child processes that run as another user, like apache or nobody. Generally, the original process opens and reads configuration files and sockets, then forks a child process to handle requests. Each child process inherits the open file descriptors created by the parent process, so they are able to write to logs files, sockets, etc. The configuration file APACHE_HOME/conf/cams-webagent.conf file is read by mod_cams_apache13 within the parent process and the log file APACHE_HOME/logs/cams-webagent.log is also created by the Apache parent process and inherited by children.
In the instructions that follow, it is assumed that the Apache server is executed by root on your Linux/UNIX system. This example assumes that:
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 /, /etc, and /etc/httpd are only modifiable by root. When you install the Apache server, you should ensure that it is similarly protected.
The following steps secure the directories and files relevant to Cams in the Apache environment:
cd /etc/httpd
chown root conf
chgrp root conf chown root conf/cams-webagent.conf chgrp root conf/cams-webagent.conf chown root logs chgrp root logs
This command sets user and group ownership to root.
NOTE: You may consider setting the ownership of all files within the Apache installation tree to root using the following command:
chown -R root .
chgrp -R root .
chmod 700 conf chmod 700 logs
This command gives read/write/execute permissions only for the owner (root). No other users or groups are given permissions on these directories, so they will unable to view or modify their contents.
chmod 600 conf/cams-webagent.conf chmod 600 logs/cams-webagent.log (Use only if this file exists)
These commands gives them read/write permissions for the owner (root). No other users or groups are given permission to read or write these files.
To further secure your Apache server/Cams web agent installation, you may consider setting file creation permissions so that only root may read/write log files. This is desireable if log files (like the cams-webagent.log file) contain sensitive DEBUG-level information or to avoid hackers from replacing log files or setting up symbolic links that can redirect the contents of log files.
Under Unix, newly created files (e.g., Apache log files) are given default permissions which are a combination of: 666 (read/write permission for everybody) and the currently-set file creation mask (called the umask). The umask is combined with permission 666 to take away permissions that might otherwise be granted. By setting the umask value for the shell that executes Apache, log files that are created can be given a default permission 600, which enables the owner (root) to read/write to them, but denies permissions to all other users.
Generally, Unix user accounts setup a default umask of 022, which results in newly created file permissions of 644. This permission value still enable group and world users to read a file, which is not desireable with sensitive log files. Using umask value 077 will cause newly created files to be given the desired permissions 600.
If the Apache web server is started using the shell script at:
/etc/init.d/httpd
You can set the umask for the associated shell by inserting a command at the top of the script as shown in Example 2.
#!/bin/sh # # Startup script for the Apache Web Server # # chkconfig: - 85 15 # description: Apache is a World Wide Web server. It is used to serve \ # HTML files and CGI. # processname: httpd # pidfile: /var/run/httpd.pid # config: /etc/httpd/conf/access.conf # config: /etc/httpd/conf/httpd.conf # config: /etc/httpd/conf/srm.conf # Source function library. . /etc/rc.d/init.d/functions # This will prevent initlog from swallowing up a pass-phrase prompt if # mod_ssl needs a pass-phrase from the user. INITLOG_ARGS="" # Path to the apachectl script, server binary, and short-form for messages. apachectl=/usr/sbin/apachectl httpd=/usr/sbin/httpd prog=httpd RETVAL=0 umask 077 ... |
| Example 2 - Setting the Apache server's file creation mask |
To test these file and directory permissions:
The distribution cgi-bin directory includes four sample Bourne/Bash shell scripts:
You should browse to cams-webagent-test.sh 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 Apache 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 server 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.sh.
When you request a protected resource that requires authentication and Cams doesn't know your user identity, the Cams Apache 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 cams-index.sh, except that the hidden values are dynamically populated as shown in Example 3.
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=\"securityDomain\" value=\"${QS_SECURITY_DOMAIN}\">
|
| Example 3 - cams-login.sh example login page |
The difference between cams-webagent-test.sh and cams-login.sh 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).
If you are denied access to a resource protected by Cams, the page specified by the cams.denied.url property in cams-webagent.conf is displayed. Example 4 shows a script that displays dynamic messages.
# #--- Decode + to space, Hex values into character values
#--- Assign expected query parameters to global variables
tmp=`echo ${name} | sed -e 's/+/ /g' | sed -e 's/%/\\\x/g'`
decodedName=`printf "${tmp}"`
if [ "${decodedName}" = "message" ] ; then
tmp=`echo ${value} | sed -e 's/+/ /g' | sed -e 's/%/\\\x/g'`
QS_MESSAGE=`printf "${tmp}"`
fi
done
}
|
| Example 4 - cams-denied.sh displays any dynamic access denied messages |
If an error occurs, Cams displays the page specified by the cams.error.url property in cams-webagent.conf. Example 5 shows a script that displays dynamic messages.
# #--- Decode + to space, Hex values into character values
#--- Assign expected query parameters to global variables
tmp=`echo ${name} | sed -e 's/+/ /g' | sed -e 's/%/\\\x/g'`
decodedName=`printf "${tmp}"`
if [ "${decodedName}" = "message" ] ; then
tmp=`echo ${value} | sed -e 's/+/ /g' | sed -e 's/%/\\\x/g'`
QS_ERROR_MESSAGE=`printf "${tmp}"`
fi
done
}
|
| Example 5 - cams-error.sh 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">
The Cams Apache 1.3 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 Apache 1.3 web agent optimizations.
Before you start the Apache server with a Cams Apache 1.3 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.
That's it, you should now be able to start Apache to test your Cams Apache web agent configuration. After you've started both Apache with the Cams Apache web agent and the Cams policy server, test the configuration using:
http://[hostname:port]/cgi-bin/cams-webagent-test.sh
Login to an account in the security domain that you've established. See the test page for more configuration and testing information.
© Copyright 1996-2004 Cafésoft LLC. All rights reserved.