[cas-dev] fixing Gateway mode in mod_auth_cas

[Earl Fogel]

On Sun, 4 May 2008, Matt Smith wrote:

> Real quick -- could you confirm that the "mod_auth_cas.c.diffs" listed
> as the #2 attachment to MAS-12, dated 3/10/08, is the one to be
> deleted.  I'm assuming so ... but just want to check first before I
> delete it.

Yes, that's the one.

> I'm intrigued by the GatewayNeccesary domain cookie -- it does seem to
> offer an optimization, but we'll have to think through it to make sure
> there are no security implications.  First glance, though, it appears
> safe.  I'm curious -- what domain does your Luminis server set for
> this cookie? "usask.ca" ?  Or does it set the domain to the location
> of your gateway'd CAS server (hmm - is that possible?) ?

I suspected this one would require more explanation, and I don't know
if it is of general enough application to warrant including it in the
official mod_auth_cas distribution.  I also don't know if that's the
best name for it, maybe GatewayCheck cookie would be better.

The idea for this actually came out of our Computer Science department, 
who run their own CAS server and applications.  That's in addition to 
the central CAS server that I run and the one that's bundled with our 
Luminis Portal.  Their goal is to have single sign-on between their 
applications and all three CAS servers.

When we first looked into this, the only way we could see to do it was 
to set up a trust relationship between their CAS server and our central 
CAS server, and to set up another trust relationship between central CAS 
and luminis CAS.  Then, when someone tried to access a CS CAS application, 
they'd be redirected to the CS CAS server.  If they didn't have a session 
there, we'd do a gateway redirect to central CAS, and if they didn't have 
a session there, then there'd be another gateway redirect to Luminis CAS.
That's a lot of bouncing around, and a lot of potential points of failure.

To get around this, we came up with the idea of having each CAS server 
set a domain cookie when a user logs in.  CAS applications can check 
this cookie to see which server(s) they need to contact to determine if 
the user has an existing CAS session.

This only works if the CAS application and servers are in the same domain 
("usask.ca" in our case) and if they have been modified to use such a 
cookie.  As it happens, our Luminis portal already has a cookie we can use 
for this purpose.  The JA-SIG CAS server doesn't.  We briefly considered 
using the ticket-granting ticket for this, but discarded that idea for 
security reasons.

We'd like to modify the JA-SIG CAS server code so there was an option to 
set a domain cookie at login and remove it at logout, but haven't done 
this work yet.

Earl Fogel
Information Technology Services  phone: (306) 966-4861
University of Saskatchewan       email: earl.fogel at usask.ca