Bug: Realm Redirects Double URL Encode the Query String and Break SAML Requests

Version Affected: 9.1.0-45 and lower, 9.2.0-18 and lower, 9.3.0-3 and lower
Bug Number: EE-991 (IdP 9.1), EE-937 (IdP 9.2)
Bug Status: Closed - Fixed
Fixed in Version(s): 9.1.0-46, 9.2.0-19, 9.3.0-4

 

Overview

When a realm redirects the browser to another step within the same realm (for example, a begin site such as WinSSO) or to a different realm (for example, using Adaptive Authentication), the query string can be progressively URL-encoded more than once instead of being checked for existing encoding first. Since a SAML request is carried inside the query string, this double (or multiple) URL encoding can invalidate the SAML request, causing authentication to fail or the browser to loop between realms or service providers.

 

Cause

Each redirect step re-encodes the query string without checking whether it has already been encoded. Opening the browser's Developer Tools and reviewing the Network tab during the redirect chain shows this progressive encoding taking place.

One example of this defect involves an FPFinder (device recognition) realm: if a user does not have a device recognition token, the realm redirects to a second realm so the user can register one. The extra redirect re-encodes the query string, so by the time the browser returns to the original realm, the SAML request no longer matches what was originally sent and authentication fails. The screenshots below show a SAML trace for a Windows SSO realm where the SAML request differs from the original query string after the redirect from the begin site.

Resolution / Workaround

This defect is fixed in hotfixes 9.1.0-46, 9.2.0-19, and 9.3.0-4. Upgrading to one of these versions (or later) resolves the issue.

If you cannot upgrade immediately and are affected by the FPFinder redirect scenario described above, work around the issue by having the second realm (the one that registers the device recognition token) use a Custom Redirect on its Post Auth page to send the user back to the first realm once they have a valid device recognition token, instead of relying on the default redirect back. This avoids the extra redirect step that triggers the double encoding.

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.