ADFS is saving the SAML authn request it receives from the SP by splitting it up and saving it in the series of MSISSamlRequest, MSISSamlRequest1, MSISSamlRequest2 cookies. If you decode these cookie values, you’ll see the original SAML authn request plus some other information saved by ADFS.
This isn’t a requirement of the SAML specification. Instead, it’s the way Microsoft has decided to save state in this scenario.
Depending on what else is happening with the HTTP response from ADFS, this can result in the 400 bad request as the combination of the very long set-cookies headers and other headers is too long for the browser.
I wasn’t able to reproduce the 400 error, but I do see these MSISSamlRequest* cookies when testing here.
These cookies are only present if the SAML authn request is sent using an HTTP Post. They’re not present if the SAML authn request is sent using HTTP-Redirect.
I recommend not using the HTTP-Post binding but instead default to the HTTP-Redirect binding.
In your saml.config, you will have the following included as part of the <PartnerIdentityProvider> configuration for ADFS:
SingleSignOnServiceBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Remove this so that the binding will default to HTTP-Redirect.
No changes should be required in ADFS or elsewhere.
Regards ComponentSpace Development
|