The problem gets stranger. I setup both the client apps and CAS on the same jBoss cluster, both as HA-singletons.
- As HA-singletons they are running a single instance, although CAS and the client app might be on different nodes. - URL references are all based on the cluster alias (which points to the load Apache/mod_jk load balancer). - *In theory* Apache is routing all calls for CAS or the client app to the same singleton instance every time. - If only one node is active, everything works flawlessly. Could it be that redirects to a different app (on a different node but same DNS alias) are confusing Apache's session stickyness? From: Bruno Melloni [mailto:[email protected]] Sent: Monday, May 24, 2010 10:09 AM To: [email protected] Subject: RE:[cas-user] CAS can be clustered, but CAS *clients* cannot be clustered - CORRECTION As Marvin indicated my problem seems to be with the balancer's Session Affinity. I am using Apache with mod-jk as a poor-man's load balancer. The puzzling thing is that even though I already had it configured for sticky sessions (mod-jk's name for Session Affinity), it seems to send the redirect back from CAS to the wrong client node much of the time. Just in case someone is familiar with mod-jk, here is my workers.properties configuration: # for mod_jk # Define list of workers that will be used # for mapping requests. worker.list=loadbalancer,status # Define Node1 # modify the host as your host IP or DNS name. worker.node1.port=8009 worker.node1.host=myNode1Host.myDomain worker.node1.type=ajp13 worker.node1.lbfactor=1 worker.node1.ping_mode=A # Define Node2 # modify the host as your host IP or DNS name. worker.node2.port=8009 worker.node2.host= myNode2Host.myDomain worker.node2.type=ajp13 worker.node2.lbfactor=1 worker.node2.ping_mode=A # Load-balancing behaviour worker.loadbalancer.type=lb worker.loadbalancer.balance_workers=node1,node2 worker.loadbalancer.sticky_session=1 # Status worker for managing load balancer worker.status.type=status From: Bruno Melloni Sent: Monday, May 24, 2010 9:33 AM To: The Community discussion list is for questions, comments, feedback and issues associated with CAS and its clients. Subject: RE: CAS can be clustered, but CAS *clients* cannot be clustered - CORRECTION My apologies to Mihir and Marvin. It looks like there are a couple bugs with the mailing list software which I just reported. I just found your responses on Nabble. From: Bruno Melloni Sent: Friday, May 21, 2010 11:27 AM To: Bruno Melloni; The Community discussion list is for questions, comments, feedback and issues associated with CAS and its clients. Subject: RE: CAS can be clustered, but CAS *clients* cannot be clustered Never mind the workaround... it also throws fails to recognize the ticket. No idea why. With an HASingleton it is supposed to be a 1-1 mapping. From: Bruno Melloni Sent: Friday, May 21, 2010 11:01 AM To: 'The Community discussion list is for questions, comments, feedback and issues associated with CAS and its clients.' Subject: CAS can be clustered, but CAS *clients* cannot be clustered After innumerable trial and error attempts and 3 postings to the list that went unanswered, I reached the conclusion that you can cluster CAS but you cannot authenticate through CAS from a clustered client application. The error? Always something like: "Authentication Failed: ticket 'ST-2-aQJM2bMCvJfcfj4M6hhR-cas' not recognized". The likely cause? * If you use the cluster(/load balancer) alias in the callback to j_spring_cas_security_check then half the time the call goes to the wrong node, which doesn't recognize the ticket. Even clustering the session with <distributable/> doesn't seen to do the trick. * If you use the node hostname in the callback, then you still (always?) get the error, probably because the hostname is different from the cluster alias the browser used to make the original call. Workaround: Since you can't truly cluster, the next best thing is to setup the client WebApp as an HighAvailability-Singleton. An HASingleton won't help you with load, but if a node goes down your users will be able to start a new session almost immediately. Not perfect... but better than running on Standalone hosts. From: Bruno Melloni Sent: Wednesday, May 19, 2010 3:06 PM To: Bruno Melloni; The Community discussion list is for questions, comments, feedback and issues associated with CAS and its clients. Subject: Authentication Failed: ticket 'ST-2-aQJM2bMCvJfcfj4M6hhR-cas' not recognized I have been using CAS for a while. We are slowly moving to a clustered environment. To avoid the complexity of a clustered CAS server, I set it up as an HA-Singleton while letting the client app be clustered. A typical call looks like: * Browser calls the client app. Uses the cluster DNS alias that points to the load balancer. * Load balancer chooses a node and passes the call to the client app on node X. * Client app calls CAS for authentication. Uses the cluster DNS alias that points to the load balancer. * Load balancer passes the call to the single instance of CAS. * CAS authenticates and calls back the app with the authenticated ticket. Here come the problem: * If I use the DNS alias for the cluster the call goes to the load balancer, which in turn may or may not pass the call to the right node. If it goes to the wrong node, it obviously doesn't work. * So I think, no problem... I'll add self-signed certificates to each node and pass the node's hostname and port in the callback so that CAS will make the callback to the right node. But this is when I get. No idea why, although I suspect it might have something to do with the browser calling the client with the cluster alias and CAS calling back using the node hostname name. Help! Callback configuration: <bean id="serviceProperties" class="org.springframework.security.cas.ServiceProperties" p:service="https://${appServer}:${appHttpsPort}/${appName}/j_spring_cas_security_check"; p:sendRenew="false" /> -- 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
