Providing high-availability for Shibboleth Identity Provider and Central Authentication System

Authors: Brusten Philip & Van der Velpen Jan
Last modified: Friday, 09-Jun-2006 15:25:18 CEST

Table of contents


On this page we will first describe the problem space of the current setup (Shibboleth Identity Provider and CAS (Central Authentication System)). Afterwards we give a solution to this problem followed by the actual implementation.

Problem space

With the new Authentication and Authorisation Infrastructure we have centralised all authentication traffic to one machine and this 24 hours a day, 7 days a week!
In our other documentation ( we suggested a configuration of both the Shibboleth Identity Provider (IdP) and the Central Authentication Service (CAS) on the same server. We have illustrated this configuration below:

The host (ip: has two different services running on his system: IdP and CAS. All authentication requests will be handled by this host.
Because all authentication will be centralised on this one host, we must provide high availability so we can guarantee uptime to the applications using authentication.

Problems like network, hardware & infrastructure problems need to be solved!


We need to provide high availability for both IdP and CAS. High availability is the ability to provide user access to the IdP and CAS for a high percentage of time by attempting to reduce unscheduled outages, to decrease the impact of scheduled downtime of IdP and CAS.
To provide this high availability we make an identical system in failover. Failover means that this second system can take over when the primary system failes, due to problems or maintainance operations.

This situation is illustrated below:

Both servers are the same as for functionality because they are identical to each other. One disadvantage of this setup is that the client's data on one system will not be shared with the other system. One could setup replication of client's data, but that is a very complex operation. In case of failover, the services will still be available but the client's state will be lost.
Network Load Balancing of Microsoft® offers a possible solution called affinity, this will bind a client to one of the servers based on his ip address. When a client has multiple connections to one of these servers he will always return to the same server, that way the client's data will be preserved. This solution isn't possible for the functionality of the IdP, because their will be a callback from the SP's to the IdP, and the client will be the SP. There is no way to couple the client's address to the SP's address.

Another idea is trivial: in this case there are two completely separate components: IdP and CAS. In stead of putting all the load on one machine and let the other one do nothing, why not split up those two components? Unfortunately also this causes problems. The CAS-client -which does authentication for the IdP servlet- does an out-of-band callback to CAS-server. When using NLB, a callback from IdP to CAS will be serviced on the SAME machine. This means the CAS-client callback will be handled by the CAS-server that should be in standby. Off course this operation will fail all the time. Replicating state of CAS-server might be a solution here. Another solution to this would be to somehow force the callback to be handled by the NLB mechanism, and thus the active CAS-server.

The conclusion we take from all this is that we cannot balance the load equally over both servers, unless this we share or replicate all client's data. The best solution is a hot-standby setup where one system takes over when the other one has problems or is being maintained.


We can achieve the failover setup on a server running Microsoft Windows Server 2003® with Network Load Balancing.
We based this document on
This document contains all information applicable to our setup of Network Load Balancing, further details can be found in the document mentioned above.

We assume you have setup two servers with both IdP and CAS, as described in
In our example we called both servers, the first server has a unique (intern) ip address, the second has a unique (intern) ip address All configurations need to be exactly the same, so you could setup the first system, then take an image of the first an put in on the second one (only possible if they are exactly the same).

Setup cluster hosts

We will run over some steps to activate NLB on each host. You can first do this for the first server and afterwards for the second one. We've taken screenshots of the configuration of both servers. The screenshots of the first server are located on the left, the other, server two specific screenshots, are located on the right.

The first step will be to verify the ip address you set up for the server. Go to the properties of your network interface:

Go to the properties of the Internet Protocol (TCP/IP)

Check the static ip address for the server. This ip address will be used later as dedicated ip address. In normal situations this ip address wont be available from the outside.

Activate Network Load Balancing and go to the properties:

Now we will configure the Cluster Parameters. This configuration is the same for both servers. The ip address you configure here must be added to the list of ip addresses of the Internet Protocol (TCP/IP). You will have to choose your cluster operation mode, the possibility's are unicast or multicast. Both possibility's have advantages and disadvantages.

The Network Load Balancing driver does not support a mixed unicast an multicast environment. All cluster hosts must be either multicast or unicast; otherwise, the cluster will not function properly.

If clients are accessing a Network Load Balancing cluster through a router when the cluster has been configured to operate in multicast mode, be sure that the router meets the following requirements:

If your router does not meet these requirements, you can create a static ARP entry in the router. For example, some routers require a static ARP entry because they do not support the resolution of unicast IP addresses to multicast MAC addresses.

You can also enable Internet Group Management Protocol (IGMP) support on the cluster hosts to control switch flooding when operating in multicast mode. IGMP is a protocol used by Internet Protocol version 4 (IPv4) hosts to report their multicast group memberships to any immediately neighboring multicast routers.

When you enable remote control you can manage all NLB configuration on one host with the NLB manager (this will be covered later). When you enable remote control, you must provide a identical password on both cluster hosts.

The previous tab is identical for both cluster hosts, the tab Host parameter is unique for each cluster host. Each host must have its dedicated ip address, as mentioned before. With the unique host identifier you can specify which cluster host will be the default host, when no rules apply to the request. You also need to specify which is the initial host state.

You can now setup the port rules for the requests. You must keep in mind that you have to setup an equal amount of port rules on each cluster host. These rules must also match in port range, protocol and filtering mode.
In the setup that we propose, it is not necessary to setup port rules. The priority is defined in the "Host Parameters" tab.

When you press "Ok", you will receive the following notice:

You need to add the cluster ip address to Internet Protocol (TCP/IP) stack.
Go to the properties of Internet Protocol (TCP/IP), next press the Advanced button.

Add the cluster ip to the Ip addresses list. You must do this for both cluster hosts.

The implementation of NLB is now finished.

Managing Network Load Balancing

When you activated remote control on the Cluster Parameters, you can make use of the Network Load Balancing Manager. The NLB Manager can be started from command line: Nlbmgr.exe or by going to the Administrative tools in the Start menu.

Network Load Balancing Manager is used to create and manage Network Load Balancing clusters and all cluster hosts from a single computer, and you can also replicate the cluster configuration to other hosts. By centralizing administration tasks, Network Load Balancing Manager helps eliminate many common configuration errors.


Microsoft, Windows, Windows Server 2003 are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.