AuthCAS

Warning Please upgrade to version 0.5 of this module, which has a fix for an SQL Injection Vulnerability.  The new version also has a fix for specifying a non-Pg DBI module to use. Currently, this release can be downloaded here until it is indexed on CPAN.

David Castro distributes a mod_perl Apache module which provides proxy CAS functionality. Also see the Apache2::AuthCAS module.

David Castro posted some documentation to the CAS discussion list about his excellent Apache::AuthCAS mod_perl module. Slightly edited for this venue, it is reproduced below. See also the CPAN documentation.

Overview

Apache::AuthCAS is a mod_perl module for Apache that can be declaratively configured and does support proxy tickets. This module is written in perl and does not require any compilation against Apache source (which can be a pain). It only requires that mod_perl be installed on the Apache server. As for its usefulness, I will give a couple examples below.

Webmail example

Example scenario:
One has an application that runs under Apache (CGI scripts, PHP, mod_perl, etc.). Let's say this application is a webmail client (say IMP or SquirrelMail) that needs access to proxy tickets (which it can pass on to an IMAP server using pam_cas).

Solution:
Configure Apache::AuthCAS, with proxy mode enabled and the number of proxy tickets you wish to be made available during each request. The
user and proxy tickets will be passed to the underlying application in the form of HTTP headers that can easily be accessed in most programming languages and then used appropriately.

COTS example

One has an application that cannot be modified itself (due to inability, preference, or the desire for sanity), but wants to make this application available only to centrally authenticated users. We did this for an online faculty/staff directory running on FileMaker Pro (sigh).

Solution:
One can easily proxy this application behind Apache and protect the context with Apache::AuthCAS. Apache configuration is required, however
no application changes are needed in most cases. Still, the user is available to the resource via an HTTP header, should it be needed.

Additional information

This module was created as a solution to needs we had during our CAS implementation at APU. We have many applications that are not written in Java and didn't want to integrate any of the custom CAS client bindings into them. This mechanism is much simpler for maintenance and also gives us some unique options.

For instance, we want to allow departments the ability to restrict some of their web content to others in the university. We simply configure
Apache::AuthCAS on the web machine and allow them to use .htaccess files to specify which contexts are restricted or make a default protected directory for each site. No user sees an ounce of CAS client code, but still takes advantage of a central authentication service.

Currently, a database to store session data and pgt/pgtiou mappings is required, as getting data shared between Apache processes is a little tricky and you never know which process/thread is going to serve your request. This configuration was also desirable, because we can restart Apache without destroying existing sessions.

I hope this helps to explain Apache::AuthCAS a bit more. Please send me any questions and I will clarify or explain anything I didn't cover.
For a diagram of how this module works, you can visit here.

I am sure this diagram is similar to others that exist, however, this helped me wrap my head around CAS and proxy tickets for this implementation. Feedback is greatly appreciated, and I am willing to make adjustments to the module for anyone needing them (so long as they are generally useful to the community).