Actually they are. Apache is a "reverse proxy" for both apps but one is served by a tomcat on port 8080 through apache listening omn port 80. And the other one is served by a jetty connector on port 9090 on a different port through apache listening on port 81. This is really a side point, but you don't need to have apache http server listen on two different ports to act as a reverse proxy for two different backend servers if your URL's are such that you can distinguish which calls should go where based on the URL pattern. You can just use multiple ProxyPass directives.
That said if you have one apache acting as reverse proxy for both and you configure mod_auth_cas to use the same cookie directory for both (CASCookiePath), then you should be in good shape to have the same mod_auth_cas cookie work for both sets of URI's, although I have never tested such a configuration. Users authenticate to the tomcat app on apache (using mod_auth_cas) and are granted a ticket for http://service/app then the app contains links to the jetty app "running" on port 81. If I dump the network traffic, I can see that the apache forces the client to re-authenticate to the CAS server by sending: 302 Location: https://casserver:8443/login?serviceurl=http%3A%2F%2Fservice%3A81%2Fjetty<https://casserver:8443/login?serviceurl=http%3A%2F%2Fservice%3A9090%2Fjetty> then the service URL is now: http://service:81/jetty Well if you click the link from a browser, then the cookie will not be sent because the cookie domain will be different. If you control the client and can have the second call send the mod_auth cookie anyhow, then the behavior to look for would be that you do not get the 302 redirect to CAS. I thought configuring properly CAS server so that it consider ticket for http://service/app tickets also valid for http://service:81/jetty would do the trick I don't see how modifying the CAS server in this way is going to help you. but I am now seeing that mod_auth_cas is not even trying to contact the serviceValidate URL so am not sure what is the right way to go... Any help much appreicated. If you were able to reuse the cookie for both clients, then mod_auth_cas should let the second client in without requesting an ST and without validating it. I'm still unclear on your exact limitations and thus whether sharing the cookie is really what you want. Alex. On 13 November 2012 08:03, Ohsie, David <[email protected]<mailto:[email protected]>> wrote: Any reason to the two apps can't be served by the same apache http server? If they can, then the same cookie should work for both, I believe. David Ohsie EMC Corporation From: Alexandre Chapellon [mailto:[email protected]<mailto:[email protected]>] Sent: Friday, November 09, 2012 4:41 AM To: [email protected]<mailto:[email protected]> Subject: [cas-user] Service ticket for multiple service URL I am new using CAS and I'd like to know how to have a service ticket valid for 2 service URL? I need this because one application (let's say app1) is accessed using http, through a web browser and can handle CAS authentication and redirection. This aap1 application is accessible on tcp port 1 on server1. The second application app2 running on tcp port2 on server1 is also using http, but the client has very limited support and for example is unable to post credentials to the credentials requestor or follow the HTTP redirection (the client app is MS-Office). I am using mod_auth_cas in front of those applications to handle the authentication I can pass cookies from the browser to the client app of app2. So I was thinking that if mod_auth_cas cookie is valid both both serviceURLs (http://server1:port1/service AND http://server1:port2), then that would work. Any idea how to do it? Kind regards, Alex. -- You are currently subscribed to [email protected]<mailto:[email protected]> as: [email protected]<mailto:[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]<mailto:[email protected]> as: [email protected]<mailto:[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]<mailto:[email protected]> as: [email protected]<mailto:[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
