what is replicated in CAS clustering

Thu Sep 6 14:57:35 EDT 2007

On 9/6/07, David Pham <dpham6 at gmail.com> wrote:
>
> 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.

There should be some domain that points to both of those servers (how else
would your users access CAS as a single "service"?).  That domain should be
what is set.

-Scott

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
> >
> >
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas/attachments/20070906/6befc10b/attachment.html 