CoSign: Collaborative Single Sign-On  

cosign-discuss at
general discussion of cosign development and deployment

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

Re: Cosign in production at UoA and thanks


well I had to modify the architecture a little.
Cosign currently does it load balancing at the client/filter side via
DNS. If it gets a failed check it then check the nest IP in the list.

This doesn't work with a foundry, since on one IP is visible.

So what I did was add a PROXYCHECK. This means the if a cosign daemon
gets a CHECK which fails internally (i.e. the file doesn't exist) it
issues a procy check to other replication hosts (because it knows who
the replication hosts are). A proxy check is exactly the same as a
CHECK, in that it returns the same response (which is then return back
to the client connection). But then the server recieves the replication
events right there and then. This means a proxy check also allows the
server to 'come up to speed' also.

A proxy check is only allowed from hosts the server knows as replication
hosts (so not everyone is allowed to do a proxy check).

The really nice side effect of the proxy check is I can take down one of
the servers for ages, perhaps, and of course the normal replication
would fail (which is still used - but I have modified it a little so it
uses a shared memory queue and is thus a little more resilient to small
network errors). But when i bring it up, through the proxy check it will
some up to speed quite quickly with only the relevant (currently being
used) tickets.

Also to handle this behind a foundry I added the ability for the cosign
daemon to listen on multiple ports (with each port using a different SSL
context (i.e. certificate etc)). This is because, in our case, port 6663
is load balanced through the foundry and as such presents the certificate. But for proxy checka nd replication
you cannot use this, so they replicate to port 6664 on each of the
hosts, which present a host certificate.

Hope this helps. I am willing to help uMich out if they do which to add
this functionality.



On Mon, 2005-06-13 at 11:13, Brian Hatch wrote:
> > Our central servers, consisting of two machines behind a foundry have
> > been preforming brilliantly.
> I would love to hear exactly how you've set up your load balancing.
> Our current needs don't require it, but I'll be rolling it out on the
> BigIPs when I have a chance.  Given Cosign's... unique... architecture,
> I'm curious which way you set things up and how it's working for you.

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