HTTP Status 400 - Bad Request with Error messasge BAD_SAML_REQUEST_ENCODING

Document ID : KB000007847
Last Modified Date : 14/02/2018
Show Technical Document Details
Issue:

When trying SP initiated federation request URL, user gets the following error HTTP Status 400 - Bad Request.

SAMLRequest was received by Siteminder IDP, but IDP side FWStrace.log shows error: BAD_SAML_REQUEST_ENCODING

[06/22/2017][13:21:13][1920][8920][1dad1c94-f7aa53ab-06a69df2-548f4426-07280dc3-c2][SSO.java][doGet][Transaction with ID: 1dad1c94-f7aa53ab-06a69df2-548f4426-07280dc3-c2 failed. Reason: BAD_SAML_REQUEST_ENCODING]

[06/22/2017][13:21:13][1920][8920][1dad1c94-f7aa53ab-06a69df2-548f4426-07280dc3-c2][SSO.java][doGet][The SAMLRequest parameter was not encoded properly.]

[06/22/2017][13:21:13][1920][8920][1dad1c94-f7aa53ab-06a69df2-548f4426-07280dc3-c2][SSO.java][doGet][Ending SAML2 Single Sign-On Service request processing with HTTP error 400]

Environment:
Any CA SSO 12.51 or 12.52 version policy server with federation security services. Siteminder is IDP, 3rd party software is SP.
Cause:

The error was due to incompatible encoding format used in Authnrequest created by SP partner. CA SSO product as IDP commonly accepts GET(REDIRECT) formatted SAMLRequest during HTTP GET or REDIRECT.

Here is original Authnrequest example

<?xml version="1.0" encoding="UTF-8"?><samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" AssertionConsumerServiceIndex="1" ID="_25137bc531ad82033ca54f02288cbcfc" IssueInstant="2017-05-19T16:21:26Z" Version="2.0"><saml:Issuer>www.hostname.com</saml:Issuer><samlp:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/></samlp:AuthnRequest>

There are two ways to encode above xml into SAMLRequest and two different ways to pass it to partner as well.  In this case, customer is using HTTP GET.

https://idp.ssocircle.com/sso/toolbox/samlEncode.jsp

GET(REDIRECT) encoding,  which uses  DEFLATE compression method, its output will be accepted by CA SSO in HTTP GET:

fZFPb8IwDMW%2FSuR7S5Ou0EW0qAIhIW3TNNgOu0whDSNSm7A4pezbL%2FyT2IWb5eef%2FJ49nhzahuyVQ21NATROgCgjba3NdwHvq3mUw6Qco2ibHa86vzVv6qdT6EngDPKTUEDnDLcCNXIjWoXcS76snp84ixO%2Bc9ZbaRu4Qe4TAlE5HwwBqa7l1BrsWuWWyu21VAtTq0PwC2QxK%2BCLZTQdrWWWUlHnLElTKbKHTcJYnsu13MgwhtgFCr0wvgCW0FGUZBF9XNEhZ5Sz4SeQj%2BsZggk4h%2BYnzpV938dbi%2F5oNpa2HQ9u1ct9XoK4mL3aRstfUjWN7adOCa8K8K5TQObWtcLfz37s6DranEa5d8KgVsbDoDyv%2FP%2BF8g8%3D

POST encoding, which uses base64 encoding, its output below for the same xml Authnrequest, will not be accepted by CA SSO during HTTP GET or REDIRECT, which will result error 400:

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48c2FtbHA6QXV0aG5SZXF1ZXN0IHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6cHJvdG9jb2wiIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphc3NlcnRpb24iIEFzc2VydGlvbkNvbnN1bWVyU2VydmljZUluZGV4PSIxIiBJRD0iXzI1MTM3YmM1MzFhZDgyMDMzY2E1NGYwMjI4OGNiY2ZjIiBJc3N1ZUluc3RhbnQ9IjIwMTctMDUtMTlUMTY6MjE6MjZaIiBWZXJzaW9uPSIyLjAiPjxzYW1sOklzc3Vlcj53d3cuaG9zdG5hbWUuY29tPC9zYW1sOklzc3Vlcj48c2FtbHA6TmFtZUlEUG9saWN5IEFsbG93Q3JlYXRlPSJ0cnVlIiBGb3JtYXQ9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpuYW1laWQtZm9ybWF0OnRyYW5zaWVudCIvPjwvc2FtbHA6QXV0aG5SZXF1ZXN0Pg==

Resolution:

Since SP is 3rd party software, its code logic or configuration must be changed so that it will send SAMLRequest in the proper encoding format in order to bypass the error and be processed by CA Siteminder IDP.

Additional Information:

https://docops.ca.com/ca-single-sign-on/12-52-sp1/en/configuring/legacy-federation/configure-a-saml-2-0-identity-provider/initiate-single-sign-on-from-the-idp-or-sp#InitiateSingleSign-onfromtheIdPorSP-ServiceProvider-initiatedSSO(POSTorartifactbinding)

http://docs.oasis-open.org/security/saml/v2.0/

https://en.wikipedia.org/wiki/DEFLATE

https://en.wikipedia.org/wiki/Base64