Skip to content

Mod_CAS

December 11, 2008

mod_cas is a module that allows Apache V2 filter access http with guidelines’ require user ‘or’ require valid-user ‘using the mechanism SSO CAS.

The overall functioning of the module is as follows:

At the time of an access HTTP towards a URL protected by mod_cas,
* If the browser does not have yet valid a “session” HTTP established with the waiter:
o mod_cas redirects the browser towards the URL of login CAS for authentification
o The browser returns from the waiter CAS carrying the Service Ticket (ST), in parameter of GET
o mod_cas directly validates ST near the waiter CAS in https; he thus knows the “login” of the user.
o mod_cas creates a session then:
+ creation of a local identifier of session +
writing in a file “hides” this id of session, timestamp and login corresponding
+ writing of this identifier of session in a cookie near the browser

* If not, the browser already established a session, and this one is valid (the time of end of session is not expired):
o reading of the cookie of session
o Validation of this one (thus, local recovery of the login). There is then no specific traffic related to the authentification CAS.

Mod_cas introduction

Mod_cas is an Apache module that uses CAS to protect static and dynamic web content. The version of Mod_cas is only available for Apache 2.x.

Building

Mod_cas requires OpenSSL libraries to be installed in a path known to the loader (and OpenSSL header files in a path known to the compiler). To build this version of mod_cas for Apache 2.x, perform the following steps:

  1. Obtain a copy of the   mod cas module
  2. Install the contents of the   mod_cas module beneath the “modules” directory in Apache’s source tree.
  3. Change to the root directory of Apache’s source distribution and run

    ./buildconf
    ./configure --enable-mods-shared=ALL --enable-cas --enable-cas=shared --disable-auth
    make

  4. mod_cas.so will be located in modules/cas/.libs beneath Apache’s server
  5. At this point, doing:

    make install

    should place everything where it is needed.

Installation

To use the CAS module (mod_cas), mod_cas.so should be installed in an appropriate path (typically the ‘libexec’ directory under the Apache server root) and loaded with the following in httpd.conf:

LoadModule cas_module modules/mod_cas.so

Install the verisignserverca.pem file in /usr/local/etc/verisignserverca.pem. This file allows CAS ticket validation to proceed securely; right now, the location is not configurable at runtime.

For the CAS module to be triggered, the AuthType must be set to “CAS” or “Basic” with a line like

AuthType CAS

in the server configuration (httpd.conf) file or a local .htaccess file.

Because the version of mod_cas does basic authentication as well as authentication of   accounts, Basic is allowed as well as CAS. To avoid conflict with the built in Basic authentication module, --disable-auth was specified on the ./configure line above.

Various Require directives are supported, and are described in detail in the document on using .htaccess files with 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 by the server administrator and, with the exception of CASLocalCacheInsecure, only once per server:

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.

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.

For example, the following could be placed in httpd.conf:

CASLocalCacheFile /usr/local/apache2/logs/CasCache

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 not large (less than 150 bytes).

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

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).

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.)

ALSO NOTE: 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.

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.

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

The use of the session is optional. It is in fact practically essential for reasons of performances.

==================

Clover : measures  the coverage of your unit tests.

Maven:

Advertisements
No comments yet

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: