2007/8/21, Andrew R Feller <[EMAIL PROTECTED]>:
Are you sure that both Tomcat clustering and CAS clustering are
configured correctly? By using Tomcat 5.5, I assume that you are using
multicasting for both Tomcat and CAS; only Tomcat 6.0 supports unicast
discovery via static members.
I'm not really expert about tomcat , but I can say that it's clustering
works because I can see that each established connection generates a
sessionID wich is visible by both the servers using a test jsp.
[Andrew R Feller]
Hrmmm, I think the issue you might be having is that the ticket granting
ticket cookie (TGC) generated by CAS isn't visible to the other server.
IIRC, the clustering guide didn't mention that you needed to configured
CAS to use a higher level domain that both CAS servers can see cookies
for.
To fix this issue, open the cas-servlet.xml file and look for the
warnCookieGenerator and ticketGrantingTicketCookieGenerator and set the
cookieDomain property like so:
<bean id="warnCookieGenerator"
class="org.springframework.web.util.CookieGenerator">
<property name="cookieDomain" value="example.com" />
<property name="cookieSecure" value="true" />
<property name="cookieMaxAge" value="-1" />
<property name="cookieName" value="CASPRIVACY" />
<property name="cookiePath" value="/cas" />
</bean>
<bean id="ticketGrantingTicketCookieGenerator"
class="org.springframework.web.util.CookieGenerator">
<property name="cookieDomain" value="example.com" />
<property name="cookieSecure" value="true" />
<property name="cookieMaxAge" value="-1" />
<property name="cookieName" value="CASTGC" />
<property name="cookiePath" value="/cas" />
</bean>
Try changing the logging level to debug for the
org.apache.catalina.cluster package to confirm that Tomcat clustering
works. As for CAS, I think you should be able to log at the
org.jasig.cas.ticket.registry package to monitor the JBoss Cache ticket
registry.
jboss cache 2.0
tomcat 5.5
cas 3.0.7
I'm sorry but as I said before I'm not really expert about tomcat. Could
you explain how to do this to me in a step-by-step way? ;P
[Andrew R Feller]
If you want to enable logging within CAS, you can download the Log4j JAR
and place it within either Tomcat's lib directory or CAS's lib directory
and configure it to log different levels of messages based on the
package / class names of code being executed. To do so,
1. Read the Log4j documentation
(http://logging.apache.org/log4j/docs/documentation.html)
2. Obtain a copy of Log4j version 1.2+ and place it in either the
Tomcat lib directory (CATALINA_HOME/lib) or the CAS lib directory
(CATALINA_HOME/webapps/cas/WEB-INF/lib)
3. Configure Log4j to log messages; a sample configuration is
below:
# For JBoss: Avoid to setup Log4J outside
$JBOSS_HOME/server/default/deploy/log4j.xml!
# For all other servers: Comment out the Log4J listener in
web.xml to activate Log4J.
log4j.rootLogger=ERROR, stdout, logfile
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d %p [%c] -
<%m>%n
log4j.appender.logfile=org.apache.log4j.RollingFileAppender
log4j.appender.logfile.File=cas.log
log4j.appender.logfile.MaxFileSize=512KB
# Keep three backup files.
log4j.appender.logfile.MaxBackupIndex=3
# Pattern to output: date priority [category] - message
log4j.appender.logfile.layout=org.apache.log4j.PatternLayout
log4j.appender.logfile.layout.ConversionPattern=%d %p [%c] -
%m%n
# WARNING: Setting the org.springframework logger to DEBUG
displays debug information about
# the request parameter values being bound to the command
objects. This could expose your
# password in the log file. If you are sharing your log files,
it is recommend you selectively
# apply DEBUG level logging on a an org.springframework.*
package level (i.e. org.springframework.dao)
log4j.logger.org.springframework=WARN
#log4j.logger.org.springframework.web.servlet.i18n=DEBUG
#log4j.logger.org.springframework.web.servlet.view=DEBUG
#log4j.logger.org.quartz=DEBUG
log4j.logger.org.jasig=INFO
# WARNING: Setting the flow package to DEBUG will display
# the parameters posted to the login servlet including
# cleartext authentication credentials
log4j.logger.org.jasig.cas.web.flow=INFO
#log4j.logger.org.jasig.cas.authentication=DEBUG
#log4j.logger.org.jasig.cas.web.flow.TicketGrantingTicketCheckAction=DEB
UG
#log4j.logger.org.jasig.cas.services.DefaultServiceRegistry=DEBUG
#log4j.logger.org.org.jasig.cas.services=DEBUG
Furthermore, we're using Jboss Cache 1.4.1SP4, Tomcat 5.5 and CAS 3.0.7
with JDK 1.6. Should these versions be compatble with each other?
[Andrew R Feller]
These versions should be compatible. I am currently using JBoss Cache
1.4.1 SP4, Tomcat 6, CAS 3.0.7, and JDK 1.6.2 and it works fine.
Hope that helps,
Andrew R Feller, Analyst
Subversion Administrator
University Information Systems
Louisiana State University
[EMAIL PROTECTED]
(office) 225.578.3737
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Claudio Tassini
Sent: Tuesday, August 21, 2007 7:10 AM
To: [email protected]
Subject: CAS cluster don't replicate tickets
Hi all,
we're trying to configure a clustered CAS 3.0.7 platform,
following the instructions at
http://www.ja-sig.org/wiki/display/CASUM/Clustering+CAS#ClusteringCAS-re
ferences
<http://www.ja-sig.org/wiki/display/CASUM/Clustering+CAS#ClusteringCAS-r
eferences> .
We connect to a webapp which redirects to the cas login url.
Once the login is done, cas redirects the user to the webapp page. cas
and the webapp are on the same tomcat ( 5.5).
All is working flawlessly with a single-server environment, but
after having configured cas and tomcat to replicate sessions and tickets
among two server, we have this behavior:
The user goes to http://oursite.domain.it /application
<http://oursite.domain.it/application> . The application doesn't find a
suitable ticket, so redirects the browser to
https://oursite.domain.it/cas <https://oursite.domain.it/cas/login>
/login <https://oursite.domain.it/cas/login> . The user logs in
successfully and cas tries to redirect the browser back to
http://oursite.domain.it <http://oursite.domain.it/application>
/application <http://oursite.domain.it/application> , which find that
the given ticket is not valid because obtained from the remote server.
Shouldn't they be syncronized? What could be wrong?
With the same configuration, and shutting down one of the two
servers, all works fine.
This is an extract from the log, on the server that grants the
ticket:
2007-08-21 11:52:07,947 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-21 11:52:07,949 INFO
[org.jasig.cas.CentralAuthenticationServiceImpl ] - <Granted service
ticket [ST-3-tqk4bNPe05dvGmgaeJCkBidNCEvNOndyekq-server2] for service
[http://mysite.domain.it <http://mysite.domain.it/Application>
/Application <http://mysite.domain.it/Application> ] for user [
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> ]>
And this is from the other server, contacted by the application
for validation:
Aug 21, 2007 2:02:29 PM edu.yale.its.tp.cas.client.CASReceipt
getReceipt
SEVERE: validation of
[[edu.yale.its.tp.cas.client.ProxyTicketValidator proxyList=[null]
[edu.yale.its.tp.cas.client.ServiceTicketValidator
casValidateUrl=[https://mysite.domain.it/cas
<https://mysite.domain.it/cas/proxyValidate> /proxyValidate
<https://mysite.domain.it/cas/proxyValidate> ]
ticket=[ST-3-tqk4bNPe05dvGmgaeJCkBidNCEvNOndyekq-server2]
service=[http%3A%2F%2Fmysite.domain.it%3A8080%2FApplication]
errorCode=[INVALID_TICKET] errorMessage=[ticket
'ST-3-tqk4bNPe05dvGmgaeJCkBidNCEvNOndyekq-server2' not recognized]
renew=false entireResponse=[<cas:serviceResponse xmlns:cas='
http://www.yale.edu/tp/cas'>
<cas:authenticationFailure code='INVALID_TICKET'>
ticket
'ST-3-tqk4bNPe05dvGmgaeJCkBidNCEvNOndyekq-server2' not recognized
</cas:authenticationFailure>
</cas:serviceResponse>
]]]] was not successful.
Any idea about what could be wrong?
Thanks in advance.
--
Claudio Tassini
_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman
<http://tp.its.yale.edu/mailman/listinfo/cas> /listinfo/cas
<http://tp.its.yale.edu/mailman/listinfo/cas>
--
Claudio Tassini
_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas