Skip to content

Shibboleth IdP Load Balancing

Our test IdP is now a pair of load balanced servers (actually, they're currently two virtual machines on the same physical server, but this is for testing). idp-dev1 and idp-dev2 are running the lbcd service to enable lbnamed failover; the servers are balanced as idp-dev.stanford.edu, which is currently listed in the InQueue and DevFed (our little test federation) metadata.

The load balancing works for Shibboleth's Browser/POST profile, where a Shibboleth handle is passed from the IdP via a browser redirect to the SP; the SP then queries the IdP using that handle. In the basic configuration, each IdP uses an in-memory map of handles to principals. Since all the IdPs in a load balanced pool need access to the same mapping, there's a CryptoShibHandle class that creates a handle by encrypting the principal with a key shared by all the IdPs.

The CryptoShibHandle classes stores the key in a Java keystore, but using the JCEKS keystore format rather than the more common JKS format (which the IdP tools use to store the public keys used to validate signed federation metadata). The Shibboleth IdP source includes an Ant rule to generate a keystore in the correct format, with a default key name and password. Once a new keystore has been created and copied to /etc/shibboleth/handle.jks (for example) on all the IdPs, the IdP name mapping configuration in idp.xml should be changed to

<NameMapping
      xmlns="urn:mace:shibboleth:namemapper:1.0"
      id="crypto"
      format="urn:mace:shibboleth:1.0:nameIdentifier"
      type="CryptoHandleGenerator"
      handleTTL="28800">
  <KeyStorePath>file:/etc/shibboleth/handle.jks</KeyStorePath>
  <KeyStorePassword>shibhs</KeyStorePassword>
  <KeyStoreKeyPassword>shibhs</KeyStoreKeyPassword>
  <KeyStoreKeyAlias>handlekey</KeyStoreKeyAlias>
</NameMapping>

Each IdP can use the same K5 keytab to bind to the directory servers, and a shared WebAuth key can also be used to mask the load balancing. However, a solution is needed to address sharing complex eduPersonTargetedIds and the salts used to create simple eduPersonTargetedIds (using SHA1 or MD5), since those were being stored on a database on the single IdP server. The next post will describe the setup of a replicated MySQL databases on idp-dev1 and idp-dev2.