fixing Gateway mode in mod_auth_cas

[Earl Fogel]

Hi,

I've been having some problems with the Gatway mode in mod_auth_cas.
It worked fine the first time, but not if you connected a second
time after your first CAS session had expired.

After a few tries :-), I've come up with a patch for mod_auth_cas
1.0.7.

This patch does several things:

- It does not send the user on a Gateway trip if the request has POST
content (because the POST content would get lost in the redirect).

- It creates a CASGatewayCookieTimeout parameter which sets the maximum
time a CASGatewayCookie is valid.  Default is 60 seconds.

- It creates a CASGatewayNecessaryCookie parameter. If your CAS server
sets a domain cookie when people login, then the user only needs to make a
Gateway trip when this cookie is present.  The value of this parameter is
the name of the cookie to check.

I should explain this last parameter a bit more.  We've set up a trust
relationship between a JA-SIG CAS server and a Luminis CAS server.  To do
this, we use mod_auth_cas to protect the login page of the JA-SIG CAS
server with a gateway request to the Luminis CAS server.  Our Luminis
server sets a domain cookie when users connect.  By checking this cookie
in mod_auth_cas, we can bypass unneccessary gateway trips to the Luminis
CAS server, which speeds things up for the user.  It also eliminates a
dependency on Luminis.  That is, people can still access JA-SIG CAS when
Luminis is down.

I've attached the patch to the MAS-12 JIRA issue:

   http://www.ja-sig.org/issues/browse/MAS-12

(Matt and Phil, please note that there are two copies of
mod_auth_cas.c.diffs attached to MAS-12.  I tried to remove
the earlier version, but didn't have permission to do so).

Earl Fogel
Information Technology Services  phone: [phone]
University of Saskatchewan       email: earl.fogel@...
_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

[Matt Smith-21]

Thanks for the patch Earl, and sorry for the delayed response - we've
both been tied up of late.  We'll take a look at your patch as soon as
we can.

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.

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?) ?

Thanks again Earl,
-Matt

On Wed, Apr 30, 2008 at 5:06 PM, Earl Fogel <earl.fogel@...> wrote:

> Hi,
>
> I've been having some problems with the Gatway mode in mod_auth_cas.
> It worked fine the first time, but not if you connected a second
> time after your first CAS session had expired.
>
> After a few tries :-), I've come up with a patch for mod_auth_cas
> 1.0.7.
>
> This patch does several things:
>
> - It does not send the user on a Gateway trip if the request has POST
> content (because the POST content would get lost in the redirect).
>
> - It creates a CASGatewayCookieTimeout parameter which sets the maximum
> time a CASGatewayCookie is valid.  Default is 60 seconds.
>
> - It creates a CASGatewayNecessaryCookie parameter. If your CAS server
> sets a domain cookie when people login, then the user only needs to make a
> Gateway trip when this cookie is present.  The value of this parameter is
> the name of the cookie to check.
>
> I should explain this last parameter a bit more.  We've set up a trust
> relationship between a JA-SIG CAS server and a Luminis CAS server.  To do
> this, we use mod_auth_cas to protect the login page of the JA-SIG CAS
> server with a gateway request to the Luminis CAS server.  Our Luminis
> server sets a domain cookie when users connect.  By checking this cookie
> in mod_auth_cas, we can bypass unneccessary gateway trips to the Luminis
> CAS server, which speeds things up for the user.  It also eliminates a
> dependency on Luminis.  That is, people can still access JA-SIG CAS when
> Luminis is down.
>
> I've attached the patch to the MAS-12 JIRA issue:
>
>   http://www.ja-sig.org/issues/browse/MAS-12
>
> (Matt and Phil, please note that there are two copies of
> mod_auth_cas.c.diffs attached to MAS-12.  I tried to remove
> the earlier version, but didn't have permission to do so).
>
> Earl Fogel
> Information Technology Services  phone: [phone]
> University of Saskatchewan       email: earl.fogel@...
> _______________________________________________
> cas-dev mailing list
> cas-dev@...
> http://tp.its.yale.edu/mailman/listinfo/cas-dev
>

--
matt@...
Key ID:D6EEC5B5
_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

[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: [phone]
University of Saskatchewan       email: earl.fogel@...
_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

[Smith, Matt]

Thanks for the details Earl.  One more question:

> 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.

Does the cookie tell the app *which* CAS server to contact, or, does it
simply flag *whether* the config-specified CAS server already deemed
this session "gateway'd"?

-Matt

--
Matthew J. Smith
University of Connecticut ITS
matt.smith@...
PGP KeyID: 0xE9C5244E


_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

[Earl Fogel]

On Tue, 6 May 2008, Matt Smith wrote:

> Does the cookie tell the app *which* CAS server to contact, or, does it
> simply flag *whether* the config-specified CAS server already deemed
> this session "gateway'd"?

It's the latter.  The name of the CAS server is already in the CASLoginURL
parameter to mod_auth_cas.  The contents of the "NecessaryCookie" don't
matter.  If the cookie is present then the user *may* have a CAS session.
If the cookie is not present, then the user *can't* have a CAS session.

The code that I gave you only deals with gateway authentication to a
single CAS server.  We use this to set up a trust relationship between
our central JA-SIG CAS server and our Luminis Portal.

There is a more complicated problem that our Computer Science department
wants to solve, where CAS applications trust multiple CAS servers.

To do this, we'd make each server set a different cookie. The client would
then check to see if any of these cookies is present, and redirect to the
appropriate CAS server. With this approach, the client needs to know the
names of all the cookies that might be used, and which CAS server to use
for each.  They're not planning to do this with mod_auth_cas though, so
I don't think we need to worry about it.

Earl
Thanks for the details Earl.  One more question:

> 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.

Does the cookie tell the app *which* CAS server to contact, or, does it
simply flag *whether* the config-specified CAS server already deemed
this session "gateway'd"?

-Matt

--
Matthew J. Smith
University of Connecticut ITS
matt.smith@...
PGP KeyID: 0xE9C5244E


_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev