Hi all! I'm spamming a bit on this list these days but I'm going mad to configure this cas platform. The only problem that's still open is about ticket registry replication (I've had a discussion here in the last days about this).
I'm using jboss-cache as specified in the clustering cas guide, the only difference is that I put the jboss-cache jars in $CATALINA_HOME/webapps/cas/WEB-INF/lib instead of putting them in the localPlugins/lib and rebuilding/redeploying cas, but I don't think this is the problem. I'm not quite sure if the problem is session stickiness on the load balancers, or if it actually is a jboss-cache misconfiguration, so I'll try to explain my platform. Two hw servers, identically configured. Apache 2.2.4, Tomcat 5.5.23 , CAS 3.07 , jboss-cache 1.4.1SP4, JDK 1.6.0_02 . All the client connections are received by apache, which only listen on the SSL port 443 and has a virtualhost configured with mod_jk to proxy connections to tomcat. In tomcat, as a consequence, I have no HTTP/HTTPS connectors active, only the AJP connector. The application using cas is a java webapp (running in the same tomcat) and the cas client is cas filter . The two apache are balanced through an F5 BIG-IP load balancer, with a virtual server configured with session persistence based on SSL ID . I'm running all in the intranet, so the same virtual server is also used by the cas client for the login and validation URLs. That is: -the browser connects to the url "https://portale.inca.it/WebMail"; , -the request is received by one of the apaches , which then proxies the connection to one of the two tomcats via mod_jk (which has sticky_sessions enabled) to reach the WebMail content -the receiving tomcat reads the web.xml , and redirects the user to the cas login page, https://portale.inca.it/cas/login -again, the browser points to portale.inca.it/cas/login, so connects to apache and then to tomcat -user logs in to cas. The TGT ticket is generated. The browser is redirected to the original context /WebMail -the same apache as before manages the connection, and because of session stickiness the connection is dropped to the same tomcat as before. -Now, the tomcat serving the /WebMail context makes a connection to the validationUrl to check if the ticket is valid. This connection will not necessarily be handled by the same tomcat that granted the ST, and I imagine that this is what jboss-cache should do: replicate those tickets so that they are always identical on both servers. But if the connection is taken by the other server, it says that the ticket does not exists and the ticket is not validated. This is what happens in the catalina.out after enabling debugging: on the first server: 2007-08-23 03:28:48,502 INFO [ org.jasig.cas.web.flow.AutomaticCookiePathSetterAction] - <Setting ContextPath for cookies to: /cas> 2007-08-23 03:29:00,008 DEBUG [ org.jasig.cas.CentralAuthenticationServiceImpl] - <Attempting to create TicketGrantingTicket for [EMAIL PROTECTED]> 2007-08-23 03:29:00,068 INFO [ org.jasig.cas.authentication.AuthenticationManagerImpl] - <AuthenticationHandler: org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler successfully authenticated the user which provided the following credentials: [EMAIL PROTECTED]> 2007-08-23 03:29:00,068 DEBUG [ org.jasig.cas.authentication.principal.UsernamePasswordCredentialsToPrincipalResolver] - <Creating SimplePrincipal for [EMAIL PROTECTED]> 2007-08-23 03:29:00,072 DEBUG [ org.jasig.cas.ticket.registry.JBossCacheTicketRegistry] - <Adding ticket to registry for: TGT-2-MjrcydZIn1DsV1KeSNcdUKSESC0MEDYVHO5-inca-portal1.inca.it > 2007-08-23 03:29:00,074 DEBUG [ org.jasig.cas.ticket.registry.JBossCacheTicketRegistry] - <Retrieving ticket from registry for: TGT-2-MjrcydZIn1DsV1KeSNcdUKSESC0MEDYVHO5-inca-portal1.inca.it> 2007-08-23 03:29:00,076 DEBUG [ org.jasig.cas.ticket.registry.JBossCacheTicketRegistry] - <Adding ticket to registry for: ST-2-cEYswXNAwUw2Ith36JfR4Tw5Gg7fF6BYfA1-inca-portal1.inca.it> 2007-08-23 03:29:00,077 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service ticket [ ST-2-cEYswXNAwUw2Ith36JfR4Tw5Gg7fF6BYfA1-inca-portal1.inca.it] for service [ https://portale.inca.it/WebMail/LoginManagerServlet?action=login] for user [ [EMAIL PROTECTED]> 2007-08-23 03:34:01,475 DEBUG [ org.apache.catalina.cluster.session.DeltaManager] - <Notifying cluster of expiration primary=/cas sessionId [true]> And then, on the second server: 2007-08-23 03:29:00,569 DEBUG [ org.jasig.cas.ticket.registry.JBossCacheTicketRegistry] - <Retrieving ticket from registry for: ST-2-cEYswXNAwUw2Ith36JfR4Tw5Gg7fF6BYfA1-inca-portal1.inca.it> 2007-08-23 03:29:00,571 DEBUG [ org.jasig.cas.CentralAuthenticationServiceImpl] - <ServiceTicket [ ST-2-cEYswXNAwUw2Ith36JfR4Tw5Gg7fF6BYfA1-inca-portal1.inca.it] does not exist.> Aug 23, 2007 3:29:00 AM edu.yale.its.tp.cas.client.CASReceipt getReceipt SEVERE: validation of [[edu.yale.its.tp.cas.client.ProxyTicketValidatorproxyList=[null] [ edu.yale.its.tp.cas.client.ServiceTicketValidator casValidateUrl=[ https://portale.inca.it/cas/proxyValidate] ticket=[ ST-2-cEYswXNAwUw2Ith36JfR4Tw5Gg7fF6BYfA1-inca-portal1.inca.it] service=[https%3A%2F%2Fportale.inca.it%2FWebMail%2FLoginManagerServlet%3Faction%3Dlogin] errorCode=[INVALID_TICKET] errorMessage=[ticket ' ST-2-cEYswXNAwUw2Ith36JfR4Tw5Gg7fF6BYfA1-inca-portal1.inca.it' not recognized] renew=false entireResponse=[<cas:serviceResponse xmlns:cas=' http://www.yale.edu/tp/cas'> <cas:authenticationFailure code='INVALID_TICKET'> ticket ' ST-2-cEYswXNAwUw2Ith36JfR4Tw5Gg7fF6BYfA1-inca-portal1.inca.it' not recognized </cas:authenticationFailure> </cas:serviceResponse> ]]]] was not successful. Am I somehow wrong in the theory? Is jboss-cache working properly and I must change the session stickiness configuration on the balancer or on mod_jk? Are there alternative methods to replicate the session registry to jboss-cache? One thing I've noticed in the starting log is this: 2007-08-23 03:25:58,166 INFO [org.jasig.cas.util.JBossCacheFactoryBean] - <Starting TreeCache service.> ------------------------------------------------------- GMS: address is fe80:0:0:0:214:4fff:fe8d:d186:32862 ------------------------------------------------------- In the guides and examples I've seen this is an IPV4 address, while this seems to be in IPV6... could this be normal? I'm sorry for the long post but I really can't figure it out. It's 4am here in Italy and I'm working on this almost without rest from 3 days now... Any help would be _really_ appreciated. Thanks in advance. -- Claudio Tassini
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
