How To: Preserve the WSFed Query String Through a SAML Consumer Realm

Version Affected: All

 

Overview

Office apps on mobile devices, such as Outlook, only work if the WSFed query string is preserved. When the workflow routes through a SAML Consumer realm, that query string is normally lost in the redirects, causing the Outlook app to fail. This happens because the redirect to the 3rd-party IdP, and the assertion it returns to the SAML consumer, don't carry the WSFed query string along with them.

Preserve the WSFed Query String Through a SAML Consumer Realm

The first realm hit saves the query string's values as part of the ASP session, but retrieving them later requires setting up both realms in a specific way. This requires the WSFed realm and the SAML Consumer realm:

1. On the WSFed realm, set a begin site that redirects to the SAML Consumer realm.
2. On the SAML Consumer realm, set a begin site that redirects to the 3rd-party IdP.
3. On the SAML Consumer realm, set the Post Auth action to custom redirect, pointing to the root of the WSFed realm, for example ../SecureAuth1/.
4. Match the Forms Auth Encryption and Validation keys across both realms.
5. Set the Pre-Auth Cookie on the WSFed realm to match the Post Auth cookie name of the SAML Consumer realm.
6. On the WSFed realm's Workflow tab, set Receive Token to Token.
7. Set the Workflow to Username & Password or Username & Password | 2nd Factor.

This produces the following workflow:

SP > SecureAuth > 3rd Party IdP > SecureAuth > SP


 

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.