3

In my production setup with 2 Service Providers and 2 IdP instances behind a load balancer, I'm seeing the following error in one of my SP's logs and I'm not sure why:

InResponseToField of the Response doesn't correspond to sent message

I'm using Shibboleth 3, Service Provider of Spring security 3.1.2 RELEASE, Spring Security SAML 1.0.0.

I haven't been able to consistently reproduce this error on Production, since it can happen either when a user clicks a link and needs to be re-authenticated or when a user is on the log in screen.

The way I've been able to reproduce consistently so far is by removing the JSESSIONID of the Service Provider (by going to the Chrome console, for example, and deleting it from the cookie list) just before hitting submit on the login screen.

Below is a snippet of the logs for one of the SP's when this error occurs in Production - the service provider is creating a different JSessionID after authentication, similar to the setup I've described above:

2018-03-05 06:33:38 DEBUG HttpSessionStorage:93 - Storing message a7a636i3hee345244e5j390hia90fg to session BC1B9DEC1CF797AA99FF3F8B4431D301

   2018-03-05 06:34:42 DEBUG HttpSessionStorage:117 - Message a7a636i3hee345244e5j390hia90fg not found in session FE9D2450284C49549E7AC212F1271045

   org.opensaml.common.SAMLException: InResponseToField of the Response doesn't correspond to sent message a7a636i3hee345244e5j390hia90fg
           at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.processAuthenticationResponse(WebSSOProfileConsumerImpl.java:139)

Possible Solution with Security Issue

One possible solution is to disable certain request validation checks on the Service Provider.

This forum post suggests using the EmptyStorageFactory strategy for SAML storage and using the defaultTargetURL in SavedRequestAwareAuthenticationSuccessHandler bean.

This post mentions a security risk with this workaround where there is a replay attack possibility. Our SPs and IdPs only HTTPS, so this may be mitigated - are there other vulnerabilities that may introduced?

Maitreya
  • 31
  • 2

1 Answers1

0

It could be a problem with your load balancer configuration. In your use case, it is important to configure sticky session in your load balancer. Consider a scenario when authentication request was made by SP1 and your LB redirected the response to SP2, in this case, SP2 going to throw this error that you are receiving. If your LB redirects the response to SP1, login gonna work fine. That can be a random case, and that is why you are not able to consistently reproduce this error. Try configure sticky session in your LB. Let me know if that helps.

Agam
  • 1,015
  • 2
  • 11
  • 21
  • The setup has a load balancer with sticky session of 3 hours. Also, the SP session is getting stuck to only one SP because I can see the logs generated for only that SP. – Maitreya Mar 13 '18 at 07:05