...
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.
...
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:
...
- 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 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.%COMMENT%