University of Saskatchewan

Welcome to the U of S

Background - Trusting another CAS Server

Our goal is for people to log into either our campus CAS server or our Luminis portal and then single-sign on to various CAS services. So, I asked this question on the CAS-DEV mailing list:

    Is it possible to setup a CAS 3.0.x server to trust a Luminis CAS server?

and received this reply:

    You can configure one of the CAS servers with the CAS client (to validate
    tickets) and then the CAS server to support "trusted" users (i.e. those
    obtained through request.getRemoteUser(). This works best if a CAS 3.0
    server is the client to the Luminis server because the CAS 3 server can
    support multiple authentication paths.

More Background

The idea is to use web server authentication to protect the login page of one CAS server with a gateway request to the other. Because we use the gateway parameter, you never sees the login screen of the second (trusted) CAS server.

If you already have a session with the second CAS server, you are redirected back to the first with a valid service ticket. The web server sets the REMOTE_USER variable and lets you into CAS.

If you don't have a session with the second CAS server, you are still redirected back, but without a service ticket. The web server lets you into CAS without setting REMOTE_USER.

Trusted Authentication Handler in JA-SIG CAS 3.x

The first step is to configure the "trusted authentication handler" in JA-SIG CAS, so CAS can use web server authentication.

The trusted authentication handler comes with CAS 3.x but is not included in the default CAS.war file. So we edit pom.xml, cas-servlet.xml, deployerConfigContext.xml and login-webflow.xml and then use Maven to build a new CAS.war file.

Please see and for more information.

Make Tomcat trust Apache authentication

We have CAS running in Tomcat behind apache. To tell Tomcat to use Apache authentication, edit the tomcat server.xml file and set tomcatAuthentication="false" in the AJP 1.3 connector as follows:

	<!-- Define an AJP 1.3 Connector on port 8009 -->
	<Connector port="8009"
	    enableLookups="false" protocol="AJP/1.3"
	    address="" tomcatAuthentication="false" />

Apache mod_auth_cas

Now we install Apache mod_auth_cas and setup Apache to protect the JA-SIG CAS login page with gateway authentication to Luminis.

Get the latest mod_auth_cas from

Build and install it:

	apxs -c mod_auth_cas.c
	cd .libs
	cp /etc/httpd/modules

Edit the Apache httpd.conf file to configure mod_auth_cas:

    LoadModule auth_cas_module modules/
    CASVersion 2
    CASAllowWildcardCert On
    CASValidateServer On
    CASCookiePath /var/run/mod_auth_cas/
    CASCertificatePath /etc/certs/CAS_Cert_Chain.pem
    CASTimeout 3600
    CASIdleTimeout 3600
    CASGatewayCookieTimeout 30
    <Location /cas/login>
        AuthType CAS
        CASScope /
        CASGateway /cas/
        Require valid-user

Restart apache:

    service httpd restart


I've submitted a number of patches to mod_auth_cas that have not made it into the official code. Contact me if you wish to use these patches. Do not use Gateway mode in mod_auth_cas without these patches.

The timeouts in the preceeding example make mod_auth_cas remember your Luminis login for an hour so it won't send users back to Luminis during that time. This means that if a user logs in to both Luminis and CAS, and then logs out of both, mod_auth_cas may still let them back into CAS without a password. You can solve this by making these timeouts very short (e.g. 5 seconds) or by removing the mod_auth_cas session cookie on your CAS logout page.

We have also modified the Luminis logout page to include a hidden frame pointing to the CAS logout page. That way, whenever someone logs out of Luminis they also log out of CAS.

Beyond the Basics

One problem with this approach is that it introduces a dependency between the two CAS servers. Because the user is redirected from the first CAS server to the second, people are unable to login to CAS applications when the second (trusted) server is down.

To get around this, we set a special domain cookie whenever someone logs into the trusted CAS server, and remove it when they logout. We then modified the mod_auth_cas client code to check for this cookie. If the cookie is not present, then the user doesn't have a session on the trusted CAS server, and we don't do the redirect.