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.
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 http://www.ja-sig.org/wiki/display/CASUM/Trusted and http://www.ja-sig.org/wiki/display/CASUM/Building+and+Deploying 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="127.0.0.1" tomcatAuthentication="false" />
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 http://www.ja-sig.org/wiki/display/CASC/mod_auth_cas
Build and install it:
apxs -c mod_auth_cas.c cd .libs cp mod_auth_cas.so /etc/httpd/modules
Edit the Apache httpd.conf file to configure mod_auth_cas:
LoadModule auth_cas_module modules/mod_auth_cas.so CASVersion 2 CASAllowWildcardCert On CASValidateServer On CASCookiePath /var/run/mod_auth_cas/ CASCertificatePath /etc/certs/CAS_Cert_Chain.pem CASLoginURL https://portal.usask.ca/cp/cas/login CASValidateURL https://portal.usask.ca/cp/cas/serviceValidate CASTimeout 3600 CASIdleTimeout 3600 CASGatewayCookieTimeout 30 <Location /cas/login> AuthType CAS CASScope / CASGateway /cas/ Require valid-user </Location>
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.