Shibboleth SSO и Spring SP: невозможно войти в систему из-за ошибки несоответствия InResponseToField

Question

В моей производственной установке с 2 поставщиками услуг и 2 экземплярами IdP за балансировщиком нагрузки я вижу следующую ошибку в одном из журналов моего SP, и я не уверен, почему:

InResponseToField ответа не соответствует отправленному сообщению

Я использую Shibboleth 3, поставщик услуг Spring Security 3.1.2 RELEASE, Spring Security SAML 1.0.0.

Я не смог последовательно воспроизвести эту ошибку в Production, поскольку это может произойти либо тогда, когда пользователь нажимает на ссылку и требует повторной проверки подлинности, либо когда пользователь находится на экране входа в систему.

До сих пор я смог последовательно воспроизводить, удалив JSESSIONID поставщика услуг (например, перейдя в консоль Chrome и удалив его из списка файлов cookie) непосредственно перед нажатием кнопки submit на экране входа в систему.

Ниже приведен фрагмент журналов для одного из SP, когда эта ошибка возникает в Production - поставщик услуг создает другой JSessionID после аутентификации, аналогично настройке, которую я описал выше:

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)

Возможное решение с проблемой безопасности

Одним из возможных решений является отключение определенных проверок проверки запросов в поставщике услуг.

Этот пост форума предлагает использовать EmptyStorageFactory стратегия для SAML хранение и использование defaultTargetURL в SavedRequestAwareAuthenticationSuccessHandler боб.

В этом посте упоминается угроза безопасности с помощью этого обходного пути, когда существует возможность повторной атаки. Наши SP и IdP только HTTPS, так что это может быть смягчено - есть ли другие уязвимости, которые могут быть введены?

Answer 1

Это может быть проблема с вашей конфигурацией балансировщика нагрузки. В вашем случае важно настроить липкий сеанс в вашем балансировщике нагрузки. Рассмотрим сценарий, когда запрос на аутентификацию был сделан SP1, и ваш LB перенаправил ответ на SP2, в этом случае SP2 собирается выбросить эту ошибку, которую вы получаете. Если ваш LB перенаправляет ответ на SP1, логин будет работать нормально. Это может быть случайным случаем, и поэтому вы не можете последовательно воспроизвести эту ошибку. Попробуйте настроить липкий сеанс в вашем LB. Дайте мне знать, если это поможет.