3

When the Saml2/acs endpoint gets called from the idp the set-cookie header is massive and it keeps resulting in:

Bad Request - Request Too Long HTTP Error 400. The size of the request headers is too long.

Cookies on sample site after ACS endpoint has been called

My question is if anyone has ran into this issue before, and if there is any simple way to solve it. I've tried to make the SAM (SessionAuthenticationModule) to store the cookies in IsReferenceMode to only save references to the cookie itself to reduce the size of the cookies but to no avail. It seems like the set-Cookie header bypasses the SAM configuration.

My iDP at this point hasn't supplied any ServiceProviderCertificate, so i am currently running without with the setting authenticateRequestSigningBehavior set to "Never". Could this play a part?

Worth to mention is that im running localhost aswell as when at the iDP i get this error on BankID on same device.

Been stuck on this for awhile now and would appreciate any input at all.

1 Answers1

2

Looks like there is a lot of information in that FedAuth cookie. Try implementing the AcsCommandResult created notification and clean out all the claims that you don't need on the created identity. That should trim the cookie size down.

Anders Abel
  • 67,989
  • 17
  • 150
  • 217
  • Thanks for the answer @Anders! I understand what you are suggesting, but i think i'm trying to implement it the wrong way since the action doesn't seem to get called. The way i've gone about it is currently setting the action to my custom method in global.asax init method. Is implementing these notifications included anywhere in the documentation? Thanks in advance / Robin – Robin Ljungqvist Oct 01 '18 at 12:26
  • Depends on what package you're using. Since your talking about global.asax, I guess it's the HttpModule? Then there's a static instance `Sustainsys.Saml2.HttpModule.Saml2AuthenticationModule.Options.Notifications` that you should update. – Anders Abel Oct 01 '18 at 17:57