Andrew,
     You bring up a good point as I am unsure of what exactly is replicated
as well.  Presumably we want the ticket granting cookie that is generated by
the CAS to be replicated across the cluster.  That way when one of the peer
CASes goes offline and the client is authenticated against another CAS, the
ticket cookie they received  from the first CAS is valid thus
reauthorization is not required.  Is this the case?

Regards, David

On 8/28/07, Andrew Petro <[EMAIL PROTECTED]> wrote:
>
>  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
> [email protected]
> http://tp.its.yale.edu/mailman/listinfo/cas
>
>
_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas

Reply via email to