We are seeing an inconsistent issue/behavior with our environments. We implemented an SP initiated SAML SSO with our SP partner and started in two of our staging/UAT environments and now ready to implement/deploy into production but seeing this issue.
We request the SP initiated resource which then redirected to SiteMinder FSS, then FSS redirect the browser to redirect.jsp authentication page, which will then redirect to our custom login page/form. User then input credentials and a form POST is sent to login.fcc. After user authenticated, browser is redirected back to FSS and the SAML SSO process continues.
We implemented this in our staging/UAT environment and it appears to be working fine but in production, we get an error from FSS HTTP 400 "BAD_SAML_REQUEST_ENCODING". We compared and confirm that the code is the same for both the UAT and production custom logon page so can't figure out whey we're getting this problem on one environment but not the other.
We opened a support case with CA but have not had much response at all so hoping folks from the community can help before our hard production go-live date of June 24th. This problem does not happen if we point the login page to use the OOTB login.fcc. We initially thought that our custom login page is the cause but confirmed that the code base is exact same for the two environments so does not explains why it works for one but not the other.
The underlying problem appears to be that after the credentials are posted to login.fcc there is a redirect back to FSS but it appears that the encoded URL has been decoded and thus FSS can't interpret the request. Please see the attached FWTrace.log files one for an env that works and another for one that fails. You will see that on the env that fails, the redirect to FSS with the SAMLRequest parameter and that the URL encoding has been decoded compare to the other environment.
The custom login page is the most likely root of the problem. It appears that it is URL decoding the SAMLRequest parameter instead of preserving it. Here is the SAMLRequest prior to authentication:
This value decodes to a proper authnrequest.
After authentication, here is the SAMLRequest:
This value cannot be Base64 decoded. This is because the original value has been URL decoded. If the value above is URL encoded, it can then be Base64 decoded to a proper authnrequest.
Not seeing this problem in lower environments is most likely due to chance. The requests in the lower environments were perhaps not SP-initiated, or did not contain characters subject to URL encoding such that the unneeded URL decoding that takes place during authentication had no effect with the specific requests in the lower environments.