When running Federation Services, and a user attempts a SP initiated POST request, the user receives 400 error. The following is written to the FWSTrace.log:
Transaction with ID:
2b474df9-cc268318-a53293bf-1b3bb99d-7e444b1a-eb failed. Reason:
NO_SAML_REQUEST_OR_SPID
No SAMLRequest or SPID parameter in request to SAML2 Single Sign-On
Service.
The request ends SAML2 Single Sign-On Service request processing with HTTP error 400.
Siteminder Federation R12.52 and higher, all platforms (prior to version 12.52, only the redirect binding was supported for SP-initiated requests; SP-initiated requests via POST were not supported until R12.52).
Assuming the SAMLRequest parameter included in the POST data is properly formatted and contains the expected data, this error is most often caused by not having the Policy Server's Session Store enabled. When an unauthenticated user submits a SP Initiated POST request, the Policy Server needs a mechanism for holding the post data during the series of redirects that occur during authentication.
The Policy Server requires the Session Store for this (please note that persistent sessions are not required for this use case; enabling the Session Store is sufficient).
Without the Session Store enabled, the POST data is lost during authentication, and thus when the user returns to the saml2sso URL, it is now a GET request and the query sting looks similar to this:
SMASSERTIONREF=QUERY&SAMLTRANSACTIONID=432ef752-62ed604b-5494401a-6de5813d-7f35e66c-8
This problem can also occur if a valid session cookie is not presented upon return to saml2sso after authentication. Such a scenario can occur if the authentication URL and saml2sso are not in the same cookie domain, or if flags are set on the session cookie such that the browser will not present the cookie to the saml2sso URL. The same error as above will occur, caused by the request URL not containing sufficient information to determine the proper Authentication URL.
(NOTE: This problem will not occur for an authenticated user who submits an SP initiated POST request. This is because the saml2sso URL can process the POST data immediately without redirecting the user for authentication.)
Configure and enable the Session Store on the Policy Server (this is done in the Policy Server Management Console on the Data tab and does require a restart of the Policy Server to take effect).
Workaround:
If a Session Store cannot be enabled for any reason, the only workaround is to only allow the redirect binding for SP Initiated requests. This moves the SAMLRequest parameter to the URL and does not require the Session Store to be enabled.