"saml.threatpulse.net redirected you too many times" error rendered when user authenticating to WSS

Products

• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

Users accessing internet via WSS using IPSEC access method.

Cisco SD-WAN device used to bring up two concurrent IPSEC tunnels into WSS, where the user traffic is load balanced across the two tunnels.

Initial tests without authentication worked perfectly. As soon as SAML authentication is enabled on WSS, the user is correctly redirected to the SAML IDP server.

After user authenticates with their valid credentials on the SAML IDP server, they are not redirected back to the original URL they were going to, but are shown the following error page with a "saml.threatpulse.net redirected you too many times" error, and the generic ERR_TOO_MANY_REDIRECTS status. 

Clearing cache or going incognito mode makes no difference.

Environment

Cisco SD-WAN with IPSEC tunnels into WSS.

SAML authentication enabled on WSS.

Cause

Client affinity through one tunnel is not supported by firewall or router.

Many/most ECMP solutions use 5-tuple based hash algorithm to load-balance across multiple routes. This causes the SAML interactions between the client and WSS to be sent across different tunnels, hitting different WSS pods/proxies and causing the authentication to fail.

Resolution

If the router or firewall supports client affinity, enable this configuration.  If client affinity is not an option but affinity based on destination is possible then use Explicit over WSS IPSec as a solution.

This change, to not do ECMP and use standard destination-based routing to split the traffic, makes sure that all traffic from one user remains persistent across the same IPSEC tunnel.

Additional Information

HAR files confirm that, when the redirect loop occurs, the POST to saml.threatpulse.net with the SAML assertion is constantly redirected to the same SAML assertion consumer service URL by the Proxy.

WSS HTTP access logs confirm that, when the redirect loop occurs, the users authentication traffic is split across the two tunnels and hitting different WSS proxy servers

 - original URL user going to that triggered redirect to WSS SAML Service Provider hits WSS Proxy1 via IPSEC tunnel 1 and is redirected to saml.threatpulse.com

 - subsequent request to saml.threatpulse.net hits WSS Proxy2 via IPSEC tunnel 2 and is redirected to SAML IDP server

Since HTTP is stateless and no link exists between the proxy HTTP service from Proxy 1 and SAML service provider on Proxy 2, the authentication never completes succesfully.

Enabling persistence so that all user requests in the SAML authentication flow hit the same Proxy creates this link and allows it to succeed.