Hi,

I've looked through the archives of this mailing list, and spent hours in 
documentation, Google, and even digging through the source code, and couldn't 
find the answer to this question.  We've actually already implemented a 
workaround, but I'm not happy with it, so I hope that someone might be able to 
help me.

The problem we have is that while CAS works properly in our development 
environment, I realized (before we deployed, luckily) that it was going to fail 
when it hit our production environment.  The reason is that when validating 
tickets, and when sending messages for single sign-out, CAS uses the URL from 
the service definition.  So, for example, if I have a webapp deployed at 
https://my.domain.org/myapp, and cas is deployed at https://my.domain.org/cas, 
then when I go to /myapp, it redirects me to /cas.  I log in, and then /cas 
redirects back to /myapp, which sends a ticket validation request to CAS, via 
https://my.domain.org/cas.  And similarly, when I log out, the logout action on 
/cas will send a single sign-out request to https://my.domain.org/myapp, with 
the XML packet that says to invalidate the session.  However, our firewall 
configuration does not allow us to loop calls back to the public domain names 
for these servers from behind the firewall.  I.E. if I'm on server1.domain.org 
(either logged in on the command line, or some application running on that 
server, or whatever), which is behind the firewall at our hosting provider and 
receives requests that go to my.domain.org, then I can't send an http(s) 
request to my.domain.org.  This seems to be a not-uncommon firewall 
configuration, I've seen it at many places before.  So both ticket validation 
and single sign-out fail.

We've come up with a workaround for this, which I'm not happy with, which is 
why I'm writing to this list.  Our workaround was to create wrappers around a 
couple of CAS classes, and judiciously rewrite the service URLs in the 
appropriate places to go to https://localhost/... instead of 
https://my.domain.org/...   This works, and allows us to log in, validate 
tickets, and log out, but it involves a level of kludginess that makes me very 
uncomfortable.

Has anyone else had to deal with this problem?  Is there an accepted way of 
doing it?  Is our solution actually the best approach, or is there something 
else we should be doing instead?

Thank you,

Joe Robins
Managing Director, Application Development
Teach For America
Email: [email protected]
Phone: 212-279-2080, x11326

One day, all children in this nation will have the opportunity to attain an 
excellent education.
http://www.teachforamerica.org/




____________________________________________
This communication and any file transmitted with it may contain information 
that is confidential, privileged and exempt from disclosure under applicable 
law. It is intended solely for the use of the individual or entity to which it 
is addressed. If you are not the intended recipient, you are hereby notified 
that any use, dissemination or copying of this communication is strictly 
prohibited. If you have received this communication in error, please notify the 
sender. Thank you for your cooperation.
-- 
You are currently subscribed to [email protected] as: 
[email protected]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Reply via email to