search

Sustainsys / Saml2

Saml2 Authentication services for ASP.NET
Other
957 stars 603 forks source link

Header Too Large error #1369

Closed subodhan-arinsights closed 1 year ago

subodhan-arinsights commented 2 years ago

We are using SustainSys Saml2 AspNetCore library with Duende IdentityServer V5 to implement SSO with Saml2P. Our set-up has Load Balancers in front of the IdentityServer.

We are facing an issue of Too Large Header error thrown by our LoadBalancer. After we receive the request from the SSO-Idp at Saml2/Acs, the request is processed successfully. However, when the response is sent out (directed to go to the Identity Server endpoint), the Load Balancer gives an error 502 Bad Request (with underlying message that says the Target sent very large header).

This error is noticed only for one user. Incoming message from IdP, with around 27K header size, is successfully passed on the Acs endpoint. We believe that since this user is a member of multiple security groups, the incoming header size is quite large.

Does the Acs processing add anything to the request headers before the message is passed on to the IdentityServer Callback? Has anyone else noticed such behavior? If yes, how is it resolved?

explunit commented 1 year ago

You might be encountering the situation described in #594

subodhan-arinsights commented 1 year ago

I don't believe so. This happens in case on one person (from one client), whether he signs-in using a normal browser or in-private session. He gets the error on the first attempt. The error is thrown by the LoadBalancer (incoming message from the client passes through the LoadBalancer successfully to the ACS end point and is processed successfully). When the ACS command send the response to IdentityServer end point, the LoadBalancer throws error.

Other login requests before and after this one, go through successfully.

AndersAbel commented 1 year ago

The ACS endpoint calls sign in when done. When used with IdentityServer, this is typically the external cookie scheme. By default, all claims/payload from the SAML assertions is written to the encrypted (extenral) cookie. If the claims/attribute set is large, that can definitely cause the cookie headers on the next request to be too large.

There are two ways to handle this:

  1. Override the AcsCommandResultCreated notification and clean up the generated Claims set by removing anything you do not need. Also, translating to shorter claim names might help here.
  2. Use server side storage for the external cookie scheme.