Hi Matt, What about just using a database that both are pointing at? Thats what we are currently using in our cluster.
cheers, Steve On 17/08/2011, at 5:26 PM, Kirk, Matt wrote: > John, > > My understanding is that the DefaultTicketRegistry is not replicated across a > CAS Cluster, therefore when a user authenticates for a given service and > presents the Service Ticket to the service, that service may well (probably > almost certainly) visit a different node in the cluster (via a load balancer) > when validating that ticket. If the ST details are not replicated across all > nodes then the ticket validation will fail and the user will be denied access > to the service they have just authenticated for. By using a distributed > Ehcache for the ticket registry, all nodes will be made aware of all tickets, > thus allowing ticket validation to take place on any node in the cluster. > > Unless of course I have missed something too! > > Cheers, > Matt > > > From: Ourada, John [[email protected]] > Sent: 16 August 2011 16:17 > To: [email protected] > Subject: RE: [cas-user] CAS in load balanced environment > > Matt, based on what I have read on the JASIG site, I agree with you. > > Part of the requirements given to me was to not have a user re-authenticate > if part of the cluster fails. Memcache was eliminated. Using a DB involved > too many groups within IS and increased cost. > > I am curious why you are choosing the EHCache ticket registry over > DefaultTicketRegistry. Am I missing something? > > -john > > From: Kirk, Matt [mailto:[email protected]] > Sent: Tuesday, August 16, 2011 10:05 AM > To: [email protected] > Subject: RE: [cas-user] CAS in load balanced environment > > Thanks for all the feedback. > > We're opting for the distributed Ehcache ticket registry over a database > persistent registry across a CAS Cluster as we feel that if a node goes down, > then the ticket replication will allow seamless access to services and > therefore the DB is not required (and would itself be a single point of > failure unless replicated in some fashion). The failed node can then be > re-started and rejoin the cluster and be re-populated with the current > tickets via the distributed Ehcache. > > If the entire cluster were to go down it would require users to > re-authenticate but we consider this a (hopefully) rare and fatal system > failure so forcing users to re-authenticate after system re-start is > acceptable. > > This approach removes the need for a database and all the cost / admin etc > that goes with it. > > Do you think is is a reasonable solution? Have I missed something which may > change my thoughts? > > Thanks, > Matt > > > From: Scott Battaglia [[email protected]] > Sent: 16 August 2011 14:55 > To: [email protected] > Subject: Re: [cas-user] CAS in load balanced environment > > On Tue, Aug 16, 2011 at 9:47 AM, Marvin Addison <[email protected]> > wrote: > > what is the Memcache solution and do you have a setup guide? > > See https://wiki.jasig.org/display/CASUM/MemcacheTicketRegistry. I'll > discuss briefly what's _not_ in the manual. I think there's some > misinformation in the community, borne out in list discussions and > other venues, about the need for the repcache patches to memcached for > clustering. I think repcache is absolutely unnecessary based on the > failure mode of memcached. Consider a memcached cluster of 3 nodes, > all noted in the CAS configuration. The Java memcached client will > calculate a key and store it on one node. If that node goes down, the > client will attempt to retrieve the key from the dead node and fail, > returning an empty value. That will appear to CAS and ultimately the > user that he or she is unauthenticated and will simply need to > reauthenticate. Upon reauthentication the client will know that there > are only two nodes remaining, and calculate a new key that will be > stored on one of the two available nodes and proceed as normal. That > is a _very_ graceful failure mode in my opinion, and there's no need > for anything additional like repcached. > > It really depends on your needs. You may feel that its acceptable to force > them to log back in if a node goes down, others may not. This is why we have > a number of these backing mechanisms, you find the one that matches your > expertise and meets your availability requirements. > > However, as you note, using repcached is optional, and just provides an extra > level of redundancy if you want to apply the patch. (we did at Rutgers) > > Cheers, > Scott > > > > > Is one solution favourable over another? > > Most folks choose based on experience with a particular technology. > We use JpaTicketRegistry on PostgreSQL in production, but I'd be happy > to switch to memcached if needed. I personally think Terracotta, > JBossCache, and Infinispan are interesting technologies that are > overkill for CAS. The complexity is not worth the benefits. That is > absolutely a personal opinion and lots of folks would disagree. > > M > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > Information in this email including any attachments may be privileged, > confidential and is intended exclusively for the addressee. The views > expressed may not be official policy, but the personal views of the > originator. If you have received it in error, please notify the sender by > return e-mail and delete it from your system. You should not reproduce, > distribute, store, retransmit, use or disclose its contents to anyone. Please > note we reserve the right to monitor all e-mail communication through our > internal and external networks. SKY and the SKY marks are trade marks of > British Sky Broadcasting Group plc and are used under licence. British Sky > Broadcasting Limited (Registration No. 2906991), Sky Interactive Limited > (Registration No. 3554332), Sky-In-Home Service Limited (Registration No. > 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are > direct or indirect subsidiaries of British Sky Broadcasting Group plc > (Registration No. 2247735). All of the companies mentioned in this paragraph > are incorporated in England and Wales and share the same registered office at > Grant Way, Isleworth, Middlesex TW7 5QD. > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > Information in this email including any attachments may be privileged, > confidential and is intended exclusively for the addressee. The views > expressed may not be official policy, but the personal views of the > originator. If you have received it in error, please notify the sender by > return e-mail and delete it from your system. You should not reproduce, > distribute, store, retransmit, use or disclose its contents to anyone. Please > note we reserve the right to monitor all e-mail communication through our > internal and external networks. SKY and the SKY marks are trade marks of > British Sky Broadcasting Group plc and are used under licence. British Sky > Broadcasting Limited (Registration No. 2906991), Sky Interactive Limited > (Registration No. 3554332), Sky-In-Home Service Limited (Registration No. > 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are > direct or indirect subsidiaries of British Sky Broadcasting Group plc > (Registration No. 2247735). All of the companies mentioned in this paragraph > are incorporated in England and Wales and share the same registered office at > Grant Way, Isleworth, Middlesex TW7 5QD. > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
