Hi all, Using the email below (and other information from around the web), I was able to implement CAS clustering on two different hosts. Things are running, but I still have some questions and I hope someone can clarify them for me.
Background: I am clustering the login flow using Tomcat session replication, and the tickets are being replicated using the JBossCacheTicketRegistry. Both seem to be working fine. My first question: If I am using the JBossCacheTicketRegistry, do I have to implement a custom RegistryCleaner (which is alluded to here: http://www.ja-sig.org/products/cas/server/cluster/index.html)? My second question (actually 2 questions): I have set up unique tickets for users that are generated on each host (TGTs), but do I have to worry about service tickets? In other words, I am passing a unique (one per host) value to the value attribute of the ticketGrantingTicketUniqueIdGenerator bean. Should I be doing the same thing for the service tickets (the serviceTicketUniqueIdGenerator bean)? I also see this error in the logs, and it has me a little worried: 2007-05-21 14:05:35,594 INFO [org.jasig.cas.ticket.proxy.support.Cas20ProxyHandler] - <No UniqueTicketIdGenerator specified for org.jasig.cas.ticket.proxy.support.Cas20ProxyHandler. Using org.jasig.cas.util.DefaultUniqueTicketIdGenerator> So, the same for the above, should I set this to (via the bean property) to the serviceTicketUniqueIdGenerator bean (which uses DefaultUniqueTicketIdGenerator)? This is how I am doing uniqueness for ticketGrantingTicketUniqueIdGenerator: <bean id="placeholderConfig" class="org.springframework.beans.factory.config.PropertyPlaceholderConfi gurer"> <property name="locations"> <list> <value>file:/apps/local/share/etc/host.properties</ value> <!-- The values in this file are unique to the host on which it resides. --> </list> </property> </bean> <!-- ID Generators --> <bean id="ticketGrantingTicketUniqueIdGenerator" class="org.jasig.cas.util.DefaultUniqueTicketIdGenerator"> <constructor-arg index="0" value="${host.name}" /> </bean> Basically, I am appending the hostname to the end of the TGTs. This also allows us to know from which server a user initially logged in just by looking at the ticket. Please let me know if something looks askew. Many thanks. -lucas On Jan 16, 2006, at 10:58 AM, Scott Battaglia wrote: > iztok wrote: >> on sticky sessions. why are they needed? > CAS3 maintains the state of your login flow in the FlowScope of the > login flow. The default storage location of this is the session. > So if > you have multiple CAS machines and you're not replicating session > state > across machines (or have reimplemented the FlowStorage) then you > need to > make sure the client goes back to the same machine that has his or her > state. >> if in a clustered environment, both CAS server1 and server2 have the >> same state, presumably they will each make the same decision if >> asked? >> > Yes, you just have to make sure they have the same state :-) And > depending on your set up there are potentially a few things to change > (see above) >> we are not so much interested in load balancing but more in >> availability. so we do not care too much if the users are imperfectly >> load balanced but we do care about is users be able to use another >> cas >> server seamlesly if the one they got their TGC or ST on implodes. >> >> <snip /> >> >> i guess we need to ensure that if i get my TGC from server1, and >> subsequently obtain my ST from server2, my app can still validate the >> ST against server3 .... is that possible? >> > It most certainly is! You'll need to replace the default > TicketRegistry > with one that shares data (we have a simple JDBC one in the CAS- > Modules > project but you may need a more complex one). Depending on your > clustering/failover needs/setup you may also need to swap out the > default FlowStorage with one that doesn't use the session. I would > also > recommend grabbing the DefaultUniqueTicketIdGenerator which allows you > to append a suffix so that if properly configured you can assure > uniqueness across JVMs of Ticket Id generation. > -Scott >> _______________________________________________ >> Yale CAS mailing list >> [email protected] >> http://tp.its.yale.edu/mailman/listinfo/cas >> > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
