Page Comparison

...

Now, let's say you can't do that. Now you have to actually cluster the SP's session store. There are a couple of ways to do this. One of them is fairly simple, but requires a private network between the cluster members, and maintains a single point of failure. The other is much more work, and is most likely also going to be a single point of failureThere are a few other options discussed below.

Cookie-Based Session Recovery

The SP has a feature to store a limited amount of attribute and sesssion data in the client in an encrypted cookie, and a shared key across a set of servers can be used to recover the session on each node as the client moves between them. This is transparent, but isn't intended for use by a client constantly moving between servers on every request due to the overhead. The feature is discussed in the SessionCache page.

Shared Process

The "simple" solution is to take advantage of the fact that the SP is divided into two pieces, and all of the session state is maintained in the shibd process rather than the web server. While the SP installation requires that you install both halves on each machine, you don't actually have to use both halves on each server. If you have a fast enough, and secure enough, network, you can utilize a TCP connection to connect a number of web servers running the SP to a single shibd "listener" process. This process can run on any of the cluster nodes, or on a separate box devoted to it. To set this up, just follow the documentation for using the TCP Listener plugin.

...

The overhead of this approach has not been studied extensively, but in 2.0 the design was substantially changed in order to minimize the network traffic needed. For a typical application not under extreme load, this is likely to be viable. However, you have to understand a few things:

• Performance becomes pretty horrible very quickly as load increases. This is a bad solution for any but a lightly used site.
• The protocol between the servers is NOT secure. It's a simple XML protocol running over TCP. You MUST rely on a secure network between the servers, ideally a private subnet.
• The server running shibd is a single point of failure. If the process fails or the server fails, you'll lose all active sessions. However, you can restart any of the web servers without losing any state. They will reload any sessions as needed.
• Session affinity is still important here. You'll get much better performance if you keep some locality of reference, because the sessions are cached in the web servers as well.

...