No cookie error in chrome. UnexpectedInResponseToException

Question

Had this working and came back to it yesterday to find a new error which occurs in chrome but not in IE or Firefox. I'm thinking it might have something to do with SameSite but I'm not sure what the resolution would be if that is the case.

NameValueType Message"Received message _d64a80ebdfa477dd8d0cdca8870b8f88 contains unexpected InResponseTo "idba3882747fe944ac87833445b944115f". No cookie preserving state from the request was found so the message was not expected to have an InResponseTo attribute. This error typically occurs if the cookie set when doing SP-initiated sign on have been lost."string

I've seen mention of using Kentor.OwinCookieSaver being problematic, but we are not using that in our application.

This only seems to affect me, when testing from my development environment, but is not problematic in our staging/qa/production environments.

Answer 1

I have the same issue. I upgraded to .NET Framework 4.7.2 to be able to install Sustainsys.Saml2 MVC 2.7.0.0. Firefox and IE are working but same message appears to me. I get an HTTP Error 500, Requested URL: http://...../Saml2/Acs. I am not using Owin.

In Fiddler when I compare IE with Chrome, in the Saml2/Acs, IE has cookies in the response and request header where Chrome does not. When posting to sustainsys, Chrome has a security tab in the response header which IE does not (Sec-Fetch-Site: same-origin).

This is a solution apparently: Saml No Cookie Preserving State ASP.NET CORE

Unfortunately they have startup.cs and I have global.asax.

This awesome Git-repository is the solution: https://github.com/blowdart/AspNetSameSiteSamples/blob/master/AspNet472CSharpMVC5/Global.asax.cs Just copy the method in the global.asax-file and copy the SameSiteCoockieRewriter class and everyhting should be as before updating sustainsys!

Answer 2

This happened to me recently, the SAML was working fine in development and production servers, however, for some reason it suddenly stopped working under development server, but it works fine in production.

(this is really bad, as I couldn't debug or develop anything related to the SAML).

After a full day of researching and try/catch (which I've tried every solution I came across, even the one provided). I managed to fix it in the development by adding the following in the web.config.

<system.web>
  <httpCookies httpOnlyCookies="true" requireSSL="true" sameSite="Unspecified" />
</system.web>

The key point was to set SameSite to Unspecified. Which is the default value of the .NET 4.7.2 and newer. Older versions of .NET my default the value to None. So, injecting the setting directly to the web.config would assure that the application will always send the SAML request without SameSite header.

This link HttpCookie.SameSite explains the changes :

The default value of this property was modified by updates described in KB article 4531182 and KB article 4524421.

Without these updates, the default value is SameSiteMode.None, which does not emit the SameSite cookie header. This conforms to https://tools.ietf.org/html/draft-west-first-party-cookies-07#section-4.1.

After these updates have been applied, the default value is (SameSiteMode)(-1), which corresponds to Unspecified. This preserves the earlier behavior. Setting SameSiteMode.None causes "SameSite=None" to be emitted. This new behavior conforms to https://tools.ietf.org/html/draft-west-cookie-incrementalism-00.

If you need to read more about it The Work with SameSite cookies in ASP.NET

I hope this would help others as well.