How To: Push a Relay State via IdP-Initiated SAML – SecureAuth Support

Version Affected: All

Overview

This article explains how to make a dynamic relay state persist through an IdP-initiated SAML request, instead of being wiped blank.

Push a Dynamic Relay State via an IdP-Initiated Request

A relay state normally comes from the service provider (SP), since it's the SP's own SAML assertions that carry it — whether the relay state is dynamic or static. For an IdP-initiated request, if a dynamic relay state is instead passed using the standard RelayState URL parameter, it gets wiped blank as the request is processed, because relay state is expected to originate from the SP side rather than be injected into an IdP-initiated URL.

Confirm the realm's SAML Assertion / WS Federation configuration has its WSFed Reply To/SAML Target URL field left blank, to confirm the setup is ready for an IdP-initiated request.

SAML Assertion / WS Federation configuration panel with the WSFed Reply To/SAML Target URL field left blank.

In a URL like the following, the RelayState parameter carries the dynamic relay state directly:

https://secureauth.xxxx.com/secureauthxxx/?SPID=https://sso2.qwikcast.tv&RelayState=Https://www.google.com

Network trace showing the request's query string, with SPID and RelayState captured as separate parameters.

A deeper look at the same trace shows the relay state is wiped blank further along in the request:

Network trace showing the request body with a SAMLResponse parameter and an empty RelayState parameter.

To make the relay state persist through an IdP-initiated request, use the Target parameter instead of RelayState:

https://secureauth.xxxxx.com/secureauthxxx/?SPID=https://sso2.qwikcast.tv&Target=Https://www.google.com

With the parameter changed to Target, the relay state persists and the request correctly redirects to the dynamic target URL.

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.