CCNMTL has started development on an Apache module which provides proxy CAS functionality using mod_python

source

Overview

This effort is not yet a CAS client, since here at Columbia we run on a fork of CAS, called WIND (which supports groups) we wanted a client at the Apache layer, like mod_cas, but we didn't want to implement group support in C, or incur the liability of owning an apache module. mod_python provides an excellent Apache module which supports authnz, so we implemented a WIND client in python.

This module is written in python and does not require any compilation against Apache source (which can be a pain). It only requires that mod_python be installed on the Apache server.

Motivations and Advantages

CAS solves an important problem in the era of Identity 1.0 - secure single sign-on for web applications. It is very easy to write an application that uses CAS for auth if you are writing the application from scratch. However, many existing applications have their own security implementations, and even if they are pluggable, they often presume that the authentication call will happen internally.

In many settings this arrangement is unacceptable, as each individual application may not be trusted with the credentials and users are being trained to only enter their login information on a single form.

Handling the choreography of the redirects from an existing application is often tricky. However, many popular web applications do have plugins for Basic-Auth already written. The CAS project had developed a module for apache, mod_auth, which did the CAS dance, and adapted CAS so it looks like Basic Auth to the application. However, in our setting, we were running on a fork of CAS (Columbia runs WIND which handles group affiliations as well as users).

Solving the CAS client problem at the Apache layer has many advantages, as once you solve it you pick up Auth (and often auto-registration/login) virtually for free on many popular applications, such as Wordpress and MediaWiki. However, since our implementation of CAS was a fork, we were faced with owning an apache module, a responsibility (and liability) our group was not interested in taking on.

We now have secure, stable, integrated single sign-on for all these applications, using their pre-existing basic-auth plugins and don't need to own or maintain our own custom, Columbia specific, auth solutions for each of them.

Additional information

This module was created as a solution to needs we had during our fork of CAS here at Columbia. It is probably less than an hours worth of work to finish this implementation for CAS.

For a diagram of how this module works, you can visit here.