CoSign: Collaborative Single Sign-On  
AnnouncementsDiscussion
 

cosign-discuss at umich.edu
general discussion of cosign development and deployment
 

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: replication behind load balancer



On 24 Mar 2005, at 10:46, johanna bromberg craig wrote:
Also, as a side note, I'm not sure fail over in the clients will work right if both cosign servers are behind a load balancer. I haven't drawn it all out yet, but the basic idea behind client fail over is that the filters ask every weblogin server they are aware of ( A, B, and C ) based on the lookup they did at startup. If they are talking to a load balancer that only had 1 IP/name, they might only get A when in fact B happen to have the most up-to-date information. Like I said, I haven't really thought about this though, so I might be wrong, too.

You're correct. My suggested configuration would be to have the load balancer only handle HTTP(S) traffic. In order for filter <-> cosignd interactions (include replication and fail over) to function properly, the filters need to have direct access to each of the cosignd's.


On 24 Mar 2005, at 14:20, Brian Hatch wrote:
Here's a horrible thought: does the filter try each returned A record in
sequence, without eliminating duplicates?
How often does it check the DNS name weblogin.example.com, by the way?

The apache and IIS filters only looks up the server address(es) at restart, not sure what Java CoSign does. Duplicates are not suppressed, and DNS order is maintained. Filters are expected to cache and reuse connections to cosignd. Most filter connections to cosignd are relatively long lived (minutes, hours). Idle connections are timed out by cosignd.


:wes


 
Copyright © 2002 - 2004 Regents of the University of Michigan :  Page last updated 15-December-2010