Question

在我的生产设置中，在负载均衡器后面有2个服务提供商和2个IdP实例，我在其中一个SP的日志中看到以下错误，我不确定原因：< / p>

响应的InResponseToField与发送的消息不对应

我正在使用Shibboleth 3，Spring安全3.1.2 RELEASE服务提供商，Spring Security SAML 1.0.0。

我无法在生产中始终如一地重现此错误，因为当用户点击链接并需要重新进行身份验证或用户登录屏幕时，可能会发生此错误。

到目前为止我能够一致地重现的方式是在点击提交之前删除服务提供商的JSESSIONID（例如，转到Chrome控制台，并从Cookie列表中删除它）登录界面。

以下是生产中发生此错误时其中一个SP的日志片段 - 服务提供商在身份验证后创建了不同的JSessionID，类似于设置I＆＃39; ve如上所述：

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)

安全问题的可能解决方案

一种可能的解决方案是禁用服务提供商的某些请求验证检查。

此forum post建议使用EmptyStorageFactory策略进行SAML存储，并使用defaultTargetURL bean中的SavedRequestAwareAuthenticationSuccessHandler。

这个post提到了这种解决方法的安全风险，其中存在重放攻击的可能性。我们的SP和IdP只有HTTPS，所以这可以减轻 - 是否还有其他漏洞可以引入？

Answer 1

您的负载均衡器配置可能存在问题。在您的使用案例中，在负载均衡器中配置粘性会话非常重要。考虑一种情况，当SP1发出身份验证请求并且您的LB将响应重定向到SP2时，在这种情况下，SP2将抛出您正在接收的此错误。如果你的LB重定向到SP1的响应，登录将正常工作。这可能是一个随机的情况，这就是为什么你无法一致地重现这个错误。尝试在LB中配置粘性会话。如果有帮助，请告诉我。

Shibboleth SSO和Spring SP：由于＆＃34; InResponseToField＆＃34;无法登录错配错误

1 个答案: