Partner portal SSO integration causing redirect loop after cloud migration

CRM Zendesk Sell
, , , , , , , ,
1

We recently migrated our partner portal to Azure cloud hosting and now facing a continuous redirect loop during SSO authentication. Partners using Azure AD SAML get stuck in an endless redirect between our portal and the identity provider. The SAML ACS URL configuration seems correct in our deployment, but I’m concerned about session persistence settings in the cloud environment. Our load balancer might not be maintaining sticky sessions properly. Before migration, SSO worked flawlessly on-premise. Now partners can’t access the portal at all, which is blocking critical business operations. Has anyone dealt with similar redirect issues after moving to cloud infrastructure? I’ve verified the SAML metadata is correct, but the redirect loop persists.


SAML ACS URL: https://partners.ourcompany.com/saml/acs
Entity ID: urn:partners:ourcompany:prod
Load Balancer: Azure Application Gateway
Error: Too many redirects (ERR_TOO_MANY_REDIRECTS)
2

Another common culprit is the Application Gateway health probe interfering with SAML sessions. If your health probe is hitting the same endpoints used in the SAML flow, it can create phantom sessions or invalidate legitimate ones. Configure your health probe to use a dedicated endpoint that doesn’t touch the authentication system. Also verify that your backend pool has sufficient instances and they’re all healthy - if instances are flapping, session state gets lost even with sticky sessions enabled.

3

I’d also check the actual session storage mechanism. In cloud environments, if you’re relying on in-memory sessions without a distributed cache, sticky sessions become critical but fragile. Consider implementing Redis or Azure Cache for Redis to store session state externally. This makes your application stateless and eliminates dependency on sticky sessions entirely, which is more robust for cloud deployments.

4

Based on your symptoms and our collective troubleshooting, here’s the comprehensive solution addressing all three critical areas:

1. SAML ACS URL Configuration: First, verify your ACS URL exactly matches what’s registered in Azure AD, including protocol and any path components. Update your Zendesk Sell partner portal configuration:


# Pseudocode - SAML ACS configuration steps:
1. Access Zendesk Sell Admin > Partner Portal > SSO Settings
2. Set ACS URL: https://partners.ourcompany.com/saml/acs (exact match)
3. Configure Entity ID: urn:partners:ourcompany:prod
4. Enable "Require Signed Assertions" and "Require Signed Response"
5. Set Assertion Consumer Service Binding to HTTP-POST
6. Save and download updated metadata XML for Azure AD

2. Session Persistence in Cloud: The redirect loop is almost certainly caused by missing session affinity. Configure Azure Application Gateway with proper sticky sessions:


# Azure CLI - Enable cookie-based affinity:
az network application-gateway http-settings update \
  --gateway-name PartnerPortalGateway \
  --name BackendSettings \
  --cookie-based-affinity Enabled \
  --affinity-cookie-name ApplicationGatewayCookie

Also critical: Set your application session timeout to be longer than SAML assertion lifetime. In Zendesk Sell, increase session timeout to at least 3600 seconds (1 hour) to match typical SAML assertion validity.

3. Load Balancer Sticky Sessions: Beyond basic affinity, configure these Application Gateway settings:

  • Connection Draining: Enable with 120-second timeout to prevent session loss during backend updates
  • Health Probe: Create dedicated probe endpoint /health that doesn’t touch authentication
  • Cookie Settings: Ensure cookies use Secure flag and SameSite=None for cross-domain SAML
  • SSL Termination: If terminating SSL at gateway, add X-Forwarded-Proto header forwarding

Additional Critical Fixes:

  • RelayState Preservation: Verify your load balancer doesn’t strip or modify RelayState parameter in SAML requests. This parameter must pass through unchanged.

  • Session Storage: Implement distributed session storage using Azure Cache for Redis. This eliminates dependency on sticky sessions and makes your deployment more resilient:


# Connection string in Zendesk Sell config:
SESSION_STORE_TYPE=redis
REDIS_CONNECTION=partners-cache.redis.cache.windows.net:6380
REDIS_SSL=true
SESSION_TIMEOUT=3600

  • Cookie Domain: Update cookie domain to match your cloud hostname. In your application config, set COOKIE_DOMAIN=.ourcompany.com to work across subdomains.

  • Firewall Rules: Ensure Azure NSG allows bidirectional HTTPS (443) between Application Gateway and backend pool, and between backends and Azure AD endpoints.

Testing Procedure:

  1. Clear all browser cookies and cache
  2. Access partner portal URL directly
  3. Monitor SAML requests using browser dev tools Network tab
  4. Verify RelayState parameter is preserved through entire flow
  5. Check that session cookie is set with correct domain and attributes
  6. Confirm backend instance handling request remains consistent (check X-Backend-Server header)

After implementing these changes, the redirect loop should be resolved. The key is ensuring session state is either maintained through sticky sessions or externalized to Redis, while also guaranteeing SAML parameters pass through your infrastructure unchanged. Test thoroughly with multiple partner accounts before declaring victory.