SecureAuth version affected: 9.1 - 9.2
Description:
Starting in 9.1, the IdP URL encodes the query string i.e. the SAML request. If there is a further redirect within the IdP then it can make the original SAML request invalid by double URL encoding the query string when it goes back to the Service Provider.
Cause:
The example below shows a SAML trace of an Windows SSO realm where the SAML Request after the redirect from the begin site is different than the original query string. Within the same realm this can be OK because the query string is cached and does not usually cause an issue.
The issue is if there is a missing token redirect to another realm, this will cause the altered SAML request query string to become invalid and error out after authentication. The example above is configured for FPFinder, where if a user does not have a device recognition token, it will redirect to another realm so a user can register for a device recognition token.
Resolution: Using the above use case, have the 2nd realm use a Custom Redirect on the post auth page to redirect to the 1st realm now that the user has a valid device recognition token.
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
Comments
Article is closed for comments.