Joe, A couple things of note here: 1. As you discovered, to catch any issues before production, its imperative to have a test environment that closely mirrors production (Rutgers used to try to save money by using self-signed certs in test, and got bit by some issues because they were different types of certs from production).
2. You can define the URL for validation separately from any redirect urls in most CAS clients so the internal HTTPS call for validation should be okay. 3. As for other calls, such as proxy callbacks, or single sign out your only options are (a) to not use those (b) implement local workarounds, or (c) open the firewall. At least where I previously worked, our networking team had no issue with allowing the CAS server to do callbacks. We don't really support changing the Service URLs that we receive. Cheers, Scott On Wed, Jan 12, 2011 at 5:31 PM, Robins, Joe <[email protected] > wrote: > 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* <https://my.domain.org/myapp>, > and cas is deployed at *https://my.domain.org/cas*<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* <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*<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/* <https://localhost/>... > instead of *https://my.domain.org/* <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 > > -- 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
