Http Error 400: The size of the request headers is too long

SAML for ASP.NET
1

-SAML v2.0 for .NET4
- Product version 2.6.0.15

I’m using ComponentSpace to log in to an ADFS server from an ASP.Net MVC application. I’m getting the message “Http Error 400: the size of the request headers is too long” and the browser URL is displaying the value of the SingleSignOnServiceUrl property I have in my .config file. This only occurs for some users on some browsers (Chrome and Edge) . Clearing cash doesn’t work, but some users can connect using incognito mode on the browser.

Any idea what I can do to solve this ?

2

I haven’t come across this error before.

I suggest using the browser developer tools to capture the network traffic to see what’s going on.

Does one of the HTTP headers look long?

Please report back what you find.

You’re welcome to send the capture HAR file as an email attachment to support@componentspace.com and we’ll take a look.

3
[quote]
ComponentSpace - 8/5/2022
I haven't come across this error before.

I suggest using the browser developer tools to capture the network traffic to see what's going on.

Does one of the HTTP headers look long?

Please report back what you find.

You're welcome to send the capture HAR file as an email attachment to support@componentspace.com and we'll take a look.

[/quote]


I sent the HAR file.

4

There are some very large MSIS* cookies. These originate from ADFS. It saves the SAML authn request it receives as a cookie value. I’m not sure why there are multiple MSISSamlRequest* cookies and why their values are so long.

Please send the actual HAR file as an email attachment. I’d like to see the flow from when the SAML authn request is sent to ADFS through to the 400 error. Make sure to close all instances of the browser beforehand to clear all session cookies.

5

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 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.