Using CAS on an Apache 2.x host

Mike Patterson
mpatters@ist.uwaterloo.ca
v1.2.2

1  Introduction

This document is intended to be used by system administrators running Apache who need to authenticate against the campus CAS server. Original documentation may be found at
https://strobe.uwaterloo.ca/ twiki/bin/view/ISTCSS/CasAuthServer. Sysadmins are assumed to be familiar with the basics of installing modules for Apache and with editing their webserver’s configuration file. If that is not the case, this document is not for you. Please first read the Apache documentation available at http://httpd.apache.org/. The documentation here applies only to Apache 2.0/2.2. It may work for Apache 1.3, but University of Waterloo sysadmins are encouraged to upgrade to a more modern webserver.

The steps are summarized as follows:

  1. Install mod_auth_cas
  2. Install CA root certificate
  3. Configure Apache
  4. Set up .htaccess
  5. Test it all out

This document was largely cribbed from Shawn Winnington-Ball’s documentation on setting up a CAS server. Also thanks to Keith McGowan of Arts Computing and Sayed Khader, IST IT Security co-op.

2  Install mod_auth_cas

Your Unix distribution may already have a package for mod_auth_cas. If you prefer or if packages are unavailable, you can build your own module. A rough recipe looks like: 

cd /usr/local/src
svn co https://www.ja-sig.org/svn/cas-clients/mod_auth_cas/trunk mod_auth_cas
cd mod_auth_cas/src
apxs -i -c mod_auth_cas.c

It’s possible that you would instead require 

apxs2 -i -c mod_auth_cas.c

as some distributions use that name to differentiate between Apache 1.3 and 2.

In any case, this should compile the module for your operating system and Apache distribution. You may need to update your source and/or recompile if your Apache major version changes, or to fix bugs in the module.

3  Install CA root certificate

You will need the Globalsign intermediate root certificate available to your webserver. You can download it from http://www.globalsign.com/support/intermediate/domainssl_intermediate.php. Place this file somewhere your webserver can find it (hint: /etc/pki/tls/certs on most RHEL-like systems).

4  Configure Apache

You need to tell Apache about your new module, and you will need to configure it. Insert the following lines alongside the rest of your module loading calls: 

LoadModule auth_cas_module modules/mod_auth_cas.so
LoadModule authz_user_module modules/mod_authz_user.so

And create a mod_auth_cas.conf (RHalike systems, this will live in /etc/httpd/conf.d, and the file paths may vary depending on your distribution): 

<IfModule mod_auth_cas.c>
     CASVersion 2
     CASDebug On
     CASCertificatePath /etc/pki/tls/certs/ist-ca.pem
     CASLoginURL https://cas.uwaterloo.ca/cas/login
     CASValidateURL https://cas.uwaterloo.ca/cas/serviceValidate
     CASCookiePath /var/tmp/cas/
</IfModule>

By default, CAS will keep cookies on the local webserver in /var/tmp/cas, so make a directory and ensure that the webserver user can write to it: 

mkdir -m 700 /var/tmp/cas
chown apache:apache /var/tmp/cas

This directory should be kept protected from untrusted users on the system, and from untrusted web applications as much as possible.

At this point you will need to restart (probably not just reload) your Apache server in order to pick up on these changes.

5  Set up .htaccess

You may need to configure Apache to allow .htaccess files. The simplest way is to allow it right from the DocumentRoot, but your mileage may vary: 

<Directory "/var/www/html">
 ...
 AllowOverride AuthConfig
 ...
</Directory>

An access file that might require CAS authentication for a directory would look like this: 

AuthType CAS
require user mpatters

6  Test it all out

The easiest way to see if things are working is to create a dummy index.html file, put it in a separate directory under your DocumentRoot, and then create a .htaccess file as described above and place it in the same directory. Point your web browser at the appropriate URL, and you should find yourself redirected to the campus CAS server to type in your credentials, then re-redirected back to your own webserver. After this, any other application which uses CAS will automatically recognize you and (assuming you pass authz as well as authn) grant you access.

7  TO DO

Things I need to fix here:

  1. Fold in IIS documentation from http://ist.uwaterloo.ca/ kscully/Xfiles/unix:casandiis
  2. Add documentation relating to using CAS for AD groups + other individual users

One sample: 

AuthType CAS
AuthGroupFile /var/www/html/test/.htgroups
require group swb

Another possibility: 

AuthType CAS
require ldap-atribute "memberOf=CN=insertsomeADgroupnamehere, ...."
AuthGroupFile /www/.htgroups
require group additional_admins

Note that everybody needs to be in ADS, or all bets are off. If you need to mix people in ADS and not in ADS, unfortunately you can’t use CAS.

Also: 

SSLRequireSSL
AuthType CAS
require ldap-attribute memberOf="CN=ist-noc-slb-win,OU=Security 
            Groups,OU=Info Systems & Technology, OU=Academic 
            Support,DC=ads,DC=uwaterloo,DC=ca"
AuthGroupFile /var/www/html/test/.htgroups
require group swb

with a .htgroups file as such: 

swb: mpatters swball

In this case, neither mpatters nor swball are in that ADS group, yet can still authn/authz by virtue of being in the groups file.

This document was translated from LATEX by HEVEA.