The most common way to load balance a web application is to use content switching to assign requests from clients to a number of different back-end servers based on load, round-robin, etc. There is a number of different network layers that can be switched.

The simplest design is to switch at the address/port layer, without regard for anything above that. With this design, using SSL requires that each web server support SSL itself, generally with the same certificate since the hostname is common across all of them. Using the SP software in this design is fairly simple (other than session caching, see below). Each server can share essentially the same ShibbolethXml configuration and is configured to use the same logical hostname.

From the outside, all the servers look the same. Your AssertionConsumerService location(s) will be common across all the servers and it doesn't matter which server actually initiates the redirect to the IdP. The only issue to address is session caching.

A more complex scenario pushes the SSL processing up front and proxies https requests into http. In this scenario, virtualization settings are required to deal with the mismatch between the physical scheme and port and the logical scheme and port. The SPNoSSL topic, among others, talks about this issue.

Session Caching

The main problem with clustering the SP is session caching. By default, there are no cache options that can span multiple machines. This means that you must choose one of these options:

Make load-balancing "sticky" for the maximum length of a session to avoid switching cluster members.

Implement a cache plugin module in C++ that can read/write sessions from/to a shared or replicated database.

Deploy cluster members to utilize a shared shibd process by using a non-loopback socket to communicate with it over a private network.

Avoid the SP's session caching layer and quickly establish a cluster-safe session using some other application-specific technology.

The fourth option is the most common because for applications to be clusterable, they usually already need such a mechanism for themselves, so it's best to just hook into that. You can usually reduce stickiness to a few minutes for Shibboleth itself to get a session built, and purge the cache aggressively to avoid build-up of stale sessions.

There have been some reports that the third option is workable, but it's scaling properties are unknown, and it creates a single point of failure since one of the members (running shibd) is the choke point.

The cache plugin option does work, but the plugin API is rather complex. Shibboleth 2.0 will include a simplified caching API and support for ODBC out of the box.