what is replicated in CAS clustering

David Pham dpham6 at gmail.com
Fri Sep 7 11:34:24 EDT 2007 

Scott,
Thanks for the reference to BerkleyDb.  Off the top of your head, do you
know if the persistence is implemented using a  RDBMS such as mySQL or a
flat file?

Regards, David

On 9/7/07, Scott Battaglia <scott.battaglia at gmail.com> wrote:
>
> David,
>
> You'd have to implement a Ticket Registry that persists them (we have a
> BerkleyDb example in CAS).  However, if you are using the distributed JBoss
> Cache implementation, if you take one down and bring it back up I would
> think (in theory) that it should receive all of the information.  If you
> take them all down at the same time, well.... :-)
>
> -Scott
>
> On 9/7/07, David Pham <dpham6 at gmail.com> wrote:
> >
> > Thanks for the input Scott.
> >
> > Additionally this question is somewhat related to session replication.
> > Is there also a way to set up persistent storage for the ticket granting
> > cookies?  My understanding is that CAS stores the tickets in-memory but with
> > the experiment I'm doing, I will be taking CASes online and offline at timed
> > intervals and it would be ideal if I can somehow dump the ticket registry to
> > a database or a flatfile.
> >
> > Regards, David
> >
> > On 9/6/07, Scott Battaglia < scott.battaglia at gmail.com> wrote:
> > >
> > > 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
> > >
> > > _______________________________________________
> > > 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
>
> _______________________________________________
> 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/20070907/947574d7/attachment.html

More information about the cas mailing list