Main Page   Modules   Alphabetical List   Data Structures   File List   Data Fields   Globals   Related Pages  

mod_cas configuration

For mod_cas, the following parameters are additionally supported in the central configuration file but are not allowed in .htaccess; they are intended to be set only be the server administrator and, with the exception of CASLocalCacheInsecure, only once per server:

Ticket cache

CASLocalCacheFile

A full pathname to a file that stores the local ticket cache. The directory containing this file should be writable by the web server. Note that this requirement suggests that unrestricted CGI access given to end users may not be appropriate for a server that uses this module; the file should be kept private from all unprivileged users since it provides for the ability to impersonate users to the web server.

Note:
There is no default value; if this parameter is not present, no ticket cache is used, and the other cache-related parameters are ignored. A ticket cache is not necessary for mod_cas to function successfully; however, without a cache, the user needs to be redirected to CAS for every HTTP request.

CASLocalCacheSize

The number of tickets that are kept simultaneously in the cache, which is used to store session state to avoid excessive redirections back to CAS. This value can be quite large, as the size of each entry is small (considerably less than 100 bytes).

Note:
The default value is 1000, which yields a cache file (and extra memory-usage by the web server) of about 40k.

CASLocalCacheTimeout

The extent in time (in seconds) of each cached ticket. After this time runs out, the user's authenticated status is no longer cached, and the user must be redirected to CAS to establish "secondary" authentication again (where "primary" authentication is what CAS performs and "tertiary" authentication is based on the "tickets" we cache in the web server).

Note:
The default value is 3600 (one hour).

CASLocalCacheInsecure

The cache works with both "secure" and "insecure" cookies. "Secure," in this context, has only browser-dependent meaning (see RFC 2109), but most browsers refuse to send "secure" cookies for requests that aren't for HTTPS URLs.

This option is intended to be used to differentiate a secure virtual server from an insecure one. Setting it "Off," which is the default, implies two things: (a) the cookies that we send if preauthentication is handled in the current virtual server are marked "Secure," and (b) the ticket this cookie stores is internally recorded as a secure cookie. Setting it "On" implies that cookies are NOT marked secure and that the tickets are marked "insecure" internally.

The reason for this is to allow the same ticket cache to be used by a server that vends both SSL-protected and SSL-unprotected pages. This option effectively segments the ticket cache, requiring one CAS authentication in "secure" space and one CAS authentication in "insecure" space. That may seem pointless, for a user with CAS credentials can clearly authenticate in both contexts, but the rationale for this design is that a cookie used by mod_cas that proves preauthenticated status in a secure context should never be sent in the clear. Likewise, a cookie generated by preauthentication to an insecure service should not be used by a secure service, lest the user be given a false sense of security (or an attacker be given a "back door" into a secure session). If used correctly, the end result of this option is that an attacker with access to the plaintext data stream of a user's HTTP session can never spoof the user's HTTPS session.

Note:
When this option is set to "On," then individual users' sessions can be spoofed by someone with access to the plaintext stream that connects the two servers. This is worth keeping in mind since it introduces a new vulnerability which may be acceptable in some cases but should be understood in ALL cases. (This vulnerability is no different from the one affecting the session-maintenance mechanism of a typical Java servlet container or other application environment.)

This option is used to determine whether to use "http" or "https" as our callback scheme. Automatic detection of SSL isn't present since multiple modules can provide SSL but are implemented differently. Therefore you must specify this option when not using SSL, irrespective of whether or not CASLocalCacheFile is specified.

Ticket randomness

CASEGDFile

If unspecified, mod_cas will use /dev/urandom as a source of entropy. If this value is specified, it will use the EGD, accessed at the socket given by full file path (e.g., /etc/egd-pool) specified by CASEGDFile.

Note:
This feature has not yet been thoroughly tested, so we cannot yet guarantee its security; using /dev/urandom on systems that provide it (and installing it via kernel patches on systems that don't) is probably still a cleaner solution than using the EGD.

CAS server

CASServerVersion

This directive is only provided for future compatibility between versions. At this time, the only accepted value is `2'.

CASServerHostname

The FQDN of the CAS server. This option is used when redirecting not authenticated users and when validating Service Tickets.

CASServerPort

The port the CAS server is running on.

CASServerBaseUri

The base URI the CAS server should be requested with. This optio is used to build real URLs used for redirection and ticket validation.

CASServerCACertFile

The name of the file containing the cetificate of the CAS server's CA. This certificate is used to ensure safe SSL connections to the CAS server when validating tickets.
Generated on Thu Jun 26 14:33:06 2003 for mod_cas by doxygen1.3