Springboot SAML integration fails on Google App Engine, InResponseToField doesn't correspond to sent message

I have created a Springboot Restful Application for my organization. I have a requirement to,

  1. Implement SAML/SSO with IdP (ADFS2.0),
  2. Deploy the application on Google's App Engine (GAE).

I have managed to deploy the Springboot Application on GAE (with SAML) successfully.

And I have tested the SAML/SSO with a Mock version of IdP (something similar to SSO-Circle) on localhost and it works smoothly.

But, When I deploy the Application on GAE (with either Mock version of IdP or a QA version of IdP), I started getting

InResponseToField doesn't correspond to sent message

, and I did find a fix for it in the Spring docs here.

But, I fail to understand, even after intense debugging, why I get that error in the first place (although I get a different error later after applying the fix, which I will describe later further).

Much confusing part is when I had a look at the App Engine Logs, I found out,

  1. that on making /saml/login call, the log trace shows

HttpSessionStorage : Storing message a3bbxxxx6c17 to session BXtxxxx1CCw

  1. and then when IdP redirects back to the Application on the endpoint /saml/SSO, the log throws an error,

HttpSessionStorage : Message a3bbxxxx6c17 not found in session BXtxxxx1CCw

along with the exception

SAMLException: InResponseToField of the Response doesn't correspond to sent message a3bbxxxx6c17

  1. I also cross verified the SAML request(XML) that goes out from Application to the IdP and SAML response(XML) which comes back from the IdP to the Application and both of them have the a3bbxxxx6c17 message. So, why Springboot is confused on GAE and works fine with localhost.

Also, when I do what the spring docs says, "checking of the InResponseToField can be disabled by re-configuring the context provider", I notice a loop happening, i.e.,

  1. /saml/login -> 2. /saml/SSO -> /landing -> 3. /saml/SSO -> /landing -> 4. /saml/SSO -> /landing -> 5. /saml/SSO -> /landing .... and so on, until the IdP rejects the request saying too many request in fraction of time.

I don't understand why this is happening either, but my hypothesis is this can be due to the above issue. Any thoughts?