Set up multiple SAML IDPs with load balancing

When using artifact resolution, the SPs exchange the artifact for a SAML assertion by directly connecting to the IDP (not via the user's browser).

In deployments with more than one active IAM instance (active-active setups), the instance handling the artifact resolution request must be able to access the information required to issue the SAML assertion.

  • There are two ways to achieve this:
  • Storing session state in an external Redis session repository. This is the preferred way. This article is not about this way.
  • Let IAM internally forward requests to the instance holding the information for creating the SAML assertion. This setup is described in this article.

This article is not about the recommended setup. It describes a way to handle artifact resolution for active-active setups without storing the session state in Redis.

Due to its complexity, the setup described here should only be used if storing the session state in a Redis cluster is not an option.

The SAML IDP implementation supports load-balanced IAM instances by annotating every SAML artifact with an ID identifying the source IDP so that SPs can fetch the Assertion from the correct IDP.

Prerequisites

  1. The IDPs must be able to directly access each other to cater to misguided artifact resolution requests.
  2. The IDPs must be directly reachable from the SP.

The load balancing itself is not done by Airlock IAM but by an upfront load balancer, typically Airlock Gateway.

Configuration Step 1 - Airlock IAM configuration

Every server must use its own internal protocol, hostname, port, and context path in the loginapp's IDP configuration (i.e., the values required so that every IDP can access the other IDP(s) directly).

We use the following example values:

First IDP

Second IDP

Protocol

https

https

Hostname

host1

host2

Port

8080

9090

Context path

/auth

/auth

  1. Goto to:
    Loginapp >> SAML >> SAML 2.0 Identity Provider
  2. In the Load-Balancing property group, fill in the properties Protocol, Host, Port, and Context Path of the IDP instance being configured. Again, note that the combination of these properties must allow other IDP instances to access this very IDP instance.
  3. In the Server List property, provide the connection details of all IDPs (the one being configured and all other IDP instances).
    Example value:
    https://host1.example.com:8080/auth
         https://host2.example.com:9090/auth

It is crucial to configure the Server List property identically in all IDP instances.

This is because it is used to define the internal ID encoded in the MessageHandle of an Artifact which is relevant in internal processing.

Configuration Step 2 - SAML metadata files

In each IDP metadata file, the URLs of the Server List property are used according to the following two rules:

  • Each IDP gets assigned an index (starting at 0 without gaps) according to the Server List property. The assigned indices are the same for all IDPs' metadata files.
  • Each IDP puts its own URL for the ArtifactResolutionService at the top of the list.

When putting the IDP's own URL to the top of the list, make sure to move the whole ArtifactResoluationService XML tag and do not only change the index.

Example for the first IDP (Index 0):

<ArtifactResolutionService index="0"
	Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
	Location="https://host1.example.com:8080/auth/ArtifactResolver/metaAlias/iamIdp" />
<ArtifactResolutionService index="1"
	Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
	Location="https://host2.example.com:9090/auth/ArtifactResolver/metaAlias/iamIdp" />

Example for the second IDP (Index 1)

<ArtifactResolutionService index="1"
	Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
	Location="https://host2.example.com:9090/auth/ArtifactResolver/metaAlias/iamIdp" />
<ArtifactResolutionService index="0"
	Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
	Location="https://host1.example.com:8080/auth/ArtifactResolver/metaAlias/iamIdp" />

Note that it makes no difference which idp.xml is passed on to the SP. Only if the SP does not support this scenario, it would always take the first entry listed by default.

After changing the metadata XML files, the IAM instance must be restarted.