Configuring Nomad Federated Login with SAML

Nomad Federated Login with SAML supports multiple deployment topologies. Support depends on how Nomad servers, ID Vaults, and authentication endpoints are configured.

Scenario 1: Single Nomad Server (Supported)

Configuration:
  • One Nomad server
  • Nomad is accessed using a single hostname
  • Nomad Federated Login with SAML enabled
  • One ID Vault supporting all users
  • One IdPCat document configured for the Nomad hostname
  • The ID Vault Control document contains a single entry in the "Nomad Federated Login Approved IdP Configurations" field corresponding to the Nomad server's hostname.

Scenario 2: Multiple Nomad Servers Behind a Load Balancer (Supported)

Configuration:
  • Multiple Nomad servers
  • Load balancer configured with session persistence (sticky sessions) for the single load-balanced hostname.
  • Nomad is accessed using a single load-balanced hostname
  • Nomad Federated Login with SAML enabled
  • One ID Vault supporting all users
  • One IdPCat document configured for the load-balanced hostname
  • The ID Vault Control document contains a single entry in the "Nomad Federated Login Approved IdP Configurations" field corresponding to the load-balanced hostname

This is the recommended deployment model for high availability and horizontal scalability.

See the Using the Nomad server on Domino behind a reverse proxy / load balancer topic for more details.

How it works:

The load balancer maintains session affinity so that the authentication flow returns to the same Nomad server that initiated the login request. The user's ID is successfully retrieved from the shared ID Vault and authentication completes successfully.

Scenario 3: Individual Nomad Servers with Separate ID Vaults (Supported)

Configuration:

  • Multiple Nomad servers
  • No load balancer
  • Nomad is accessed using individual server hostnames
  • Nomad Federated Login with SAML enabled
  • Each Nomad server uses its own dedicated ID Vault
  • User policies direct users to the appropriate ID Vault
  • Each ID Vault has its own IdPCat document configured with the corresponding Nomad Postback URL
  • Each ID Vault Control document contains a single entry in the "Nomad Federated Login Approved IdP Configurations" field

This deployment is appropriate for environments where users are separated into independent groups each having their own ID Vault, such as geographically distributed deployments. Users must access the Nomad server associated with the ID Vault containing their Notes ID. Organizations should ensure users are directed to the correct Nomad server.

Scenario 4: Multiple Nomad Servers Sharing a Single ID Vault (Scenario 4: Multiple Nomad Servers Sharing a Single ID Vault is not)

Configuration:

  • Multiple Nomad servers
  • No load balancer
  • Nomad is accessed using individual server hostnames
  • Nomad Federated Login with SAML enabled
  • One ID Vault supporting all users
  • Individual IdPCat documents configured for each Nomad server
  • The shared ID Vault Control document contains multiple entries in the "Nomad Federated LoginApproved IdP Configurations" field.

Behavior:

During authentication, the ID Vault validates the SAML assertion and selects one of the configured Nomad Federated Login Approved IdP Configurations when generating the postback URL. Because the authentication flow is not guaranteed to return the user to the same Nomad server that initiated the authentication flow, authentication may fail.

When this occurs, users may experience one or more of the following symptoms:

  • The original browser tab does not complete authentication.
  • A second browser tab opens on a different Nomad server.
  • The second browser tab displays the SAML response instead of completing authentication.
  • The user is unable to access Nomad.

Because this setup will only work 1/Nth (where N is the number of Nomad servers) of the time, this setup is Not Supported and should be considered as not working at all.

Customers requiring multiple Nomad servers that access a shared ID Vault without using a load balancer should migrate to the Domino OIDC Provider introduced in Domino 14.5.1 because OIDC based flows support multiple Nomad servers accessing a shared ID Vault and overcomes the limitations of the SAML-based flows.