what is replicated in CAS clustering

[David Pham]

Scott,
   In regards to replicating the client-side cookies I understand that in
order to make the cookie visible to all the CASes in the cluster, we have to
configure them to be on the same domain by modifying the cookieDomain
property.  But what if our CASes are not in a domain?  In other words, each
of my CAS is housed on its own host computer and the domain is simply "
localhost.localdomain" where the hosts know of each other because they
belong to the same private network.

Regards, David

On 8/29/07, Scott Battaglia <scott.battaglia at gmail.com> wrote:
>
> Guys--
>
> Depending on how you configure CAS, various items can be replicated.
>
> If you use a Distributed Ticket Registry, such as JBossCache (or any
> custom one such as a JDBC), the Ticket Granting Tickets and Service Tickets
> are replicated amongst the CAS servers.  Their updated state should also be
> replicated amongst CAS servers the instant (well conceptually, the instant)
> they are modified.
>
> If you've configured Tomcat (or your container) for session replication,
> then the Tomcat sessions should be replicated.  Tomcat sessions only contain
> information relevant to the initial Spring Web Flow login process (if you
> don't replicate Tomcat sessions then you need to use sticky sessions or
> modify the Web Flow configuration to use client side storage).
>
> Client Side information is still maintained within the browser.  The
> cookie that holds the Ticket Granting Ticket ID should be sent to either CAS
> server, assuming the domain/path information is specified correctly (and
> since the registry is duplicated, all tickets should be accessible).  The
> same thing can be said for the "warn" cookie.
>
> -Scott
>
> On 8/29/07, Andrew R Feller <afelle1 at lsu.edu> wrote:
>
> >  Andrew,
> >
> >
> >
> > Yes, I believe we are saying the same thing.  The distinction I was
> > trying to bring up was client-side cookies stored in your web browser versus
> > server-side sessions.  There is no way, I am aware of, to replicate
> > client-side cookies on a user's web browser.  I know the ticket granting
> > ticket's cookie should be scoped a specific domain/subdomain that only the
> > CAS servers can see and thus available to all of them.
> >
> >
> >
> > Thanks,
> >
> > Andy
> >
> >
> >
> > Andrew R Feller, Analyst
> >
> > Subversion Administrator
> >
> > University Information Systems
> >
> > Louisiana State University
> >
> > afelle1 at lsu.edu
> >
> > (office) 225.578.3737
> >   ------------------------------
> >
> > *From:* cas-bounces at tp.its.yale.edu [mailto:cas-bounces at tp.its.yale.edu]
> > *On Behalf Of *Andrew Petro
> > *Sent:* Tuesday, August 28, 2007 6:47 PM
> > *To:* Yale CAS mailing list
> > *Subject:* what is replicated in CAS clustering
> >
> >
> >
> > Andrew,
> >
> > > client-side cookies are not replicated;
> > > only Tomcat's session data and ticket registries are.
> >
> > I'm not sure I understand the distinction.
> >
> > To the extent that CAS uses session cookies, these will be applicable
> > across clustered CAS server instances in the case where a fronting load
> > balancer makes them all appear to the browser to be the same hostname.
> > Session data will be as you say can be replicated across the cluster via
> > Tomcat session replication.  What makes a jsessionid cookie interesting is
> > that it keys into that server-side session data, which so long as it is
> > exclusively composed of serializable [1] objects can be clustered across the
> > Tomcats.
> >
> > The ticket granting cookie is valid by virtue of its bearing a valid
> > "Ticket Granting Ticket".  Ticket granting tickets are stored in the ticket
> > registry, and so clustering of the ticket registry accomplishes making a
> > ticket granting cookie applicable across the cluster.
> >
> > User preference cookies (e.g. indicating the preference not to be
> > transparently signed on) are not dependent on server-side state, so there's
> > nothing to cluster.  I'm not sure what it would mean to replicate these
> > cookies, but in any case they should work the same across clustered CAS
> > nodes.
> >
> > Are we agreeing in all details and just saying the same thing
> > differently, or have I missed something here?
> >
> > Andrew
> >
> >
> >
> > [1] sort of
> >
> >
> >
> >
> > 2)  Within a cluster of CAS servers, how often does the ticket data get
> > replicated? If one peer server goes offline then online, does the session
> > data (as well as the ticket data) get replicated immediately or is there an
> > interval at which this happens?   I am assuming there must be some
> > handshaking process between the new server and existing servers thus
> > allowing the new server to sync up with the cluster.
> >
> > * *
> >
> > *[Andrew R Feller] *
> >
> > *In the scenario of one node dropping from the cluster and reappearing,
> > the JBoss Cache will re-establish its ticket registry whenever it
> > successfully joins the cluster; there is no "waiting time".  Cluster
> > membership discovery can either be multicast or unicast depending upon your
> > networking situation.  As far as frequency of ticket replication, that is a
> > function of both JBoss Cache and Tomcat session replication.  However, I
> > believe Claudio is mistaken in that client-side cookies are notreplicated; only Tomcat's session data and ticket registries are.
> > *
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 2)  Within a cluster of CAS servers, how often does the ticket data get
> > replicated? If one peer server goes offline then online, does the session
> > data (as well as the ticket data) get replicated immediately or is there an
> > interval at which this happens?   I am assuming there must be some
> > handshaking process between the new server and existing servers thus
> > allowing the new server to sync up with the cluster.
> >
> >
> >
> > The ticket replication is managed through two different mechanisms:
> > client-side cookies are replicated using the cluster feature of the
> > application server (tomcat), while the cas ticket registry is replicated
> > among the cluster nodes using some other "pluggable" method. The document
> > you read explains how to set up this through the jboss-cache libraries. In
> > both cases, the syncronization method can be configured, but for cas cluster
> > to work properly it should be set in syncronous mode, which means that data
> > is replicated between the nodes each time it's modified.
> >
> >
> >
> >
> >
> > _______________________________________________
> > Yale CAS mailing list
> > cas at tp.its.yale.edu
> > http://tp.its.yale.edu/mailman/listinfo/cas
> >
> >
>
>
> --
> -Scott Battaglia
>
> LinkedIn: http://www.linkedin.com/in/scottbattaglia
> _______________________________________________
> Yale CAS mailing list
> cas at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas/attachments/20070906/77bacf78/attachment.html