具有反向代理的 Spring SAML - 响应的 inresponsetofield 与发送的消息不对应

Posted 2023-02-27

【中文标题】具有反向代理的 Spring SAML - 响应的 inresponsetofield 与发送的消息不对应

【英文标题】：Spring SAML with reverse proxy - inresponsetofield of the response doesn't correspond to sent message

【发布时间】：2019-11-25 19:03:22

【问题描述】：

我们有与 Spring SAML 集成的 Spring Boot 应用程序。我们还在 WebSecurityConfigurerAdapter 中使用 Spring SAML DSL 来启动 SAML 上下文。

以下是我们如何使用 SAML DSL 为 SAML 配置 http 安全性。

http.authorizeRequests().antMatchers("/saml*").permitAll().anyRequest().authenticated().and().apply(saml())
                .userDetailsService(sAMLUserDetailsService).serviceProvider()
                .keyStore()
                .storeFilePath(this.sslResource.getKeyStore())
                .password(this.sslResource.getKeyStorePassword()).keyname(this.sslResource.getKeyAlias())
                .keyPassword(this.sslResource.getKeyStorePassword()).and().protocol(this.serverResource.getProtocol())
                .hostname(String.format("%s:%s", "localhost", 9000))
                .basePath("/admin").and().identityProvider()
                .metadataFilePath(samlMetadataUrl);

注意主机名和端口。我已经给出了代理的主机名和端口。

我们的启动应用程序正在https://localhost:8443/admin 上运行。在这种情况下，SAML 工作得非常好。

现在我们正在尝试使用 Zuul 作为我们应用程序的反向代理。

现在 zuul 将在 localhost:9000 上运行。这是zuul路由配置

zuul: 
  routes:
    admin-ui: 
      path: /admin/**
      service-id: admin-ui
      strip-prefix: false
      customSensitiveHeaders: false

这是 OKTA 上的应用程序配置

现在，当我们通过 https://localhost:9000/admin/ 访问我们的应用程序并尝试使用 SAML 登录时，我们在 Spring SAML 中进行身份验证时遇到以下错误。

InResponseToField of the Response doesn't correspond to sent message a20jj965cg1ja8g01gbjg1d542dhg1e

我发现在发送 AuthNRequest 时，消息 ID 被存储到 HTTP 会话存储中。但是当响应返回时，会话存储它是空的。可能是它创建了一个新会话。

浏览了文档，发现我们必须使用 SAMLContextProviderLB。这已被 SAML DSL 使用。

SO 中有多个问题与问题类似，但与负载均衡器/代理不完全一样。

我们如何告诉 spring saml 在 SAML 身份验证过程完成之前保留会话？

同样，这个问题仅在我们的应用程序与 ZUUL 之类的反向代理一起使用时才会出现。

以下是带有会话 ID 的日志记录语句：

工作中

发送请求之前

 o.s.s.saml.storage.HttpSessionStorage    : Storing message a29jbce497fg0hjgaa8cf669hh1e8h to session D1694D9C4C19E5A4B0D3768A290FC144

收到回复后

o.s.s.saml.storage.HttpSessionStorage    : Message a29jbce497fg0hjgaa8cf669hh1e8h found in session D1694D9C4C19E5A4B0D3768A290FC144, clearing

如果通过反向代理（ZUUL）发送

发送请求之前

 o.s.s.saml.storage.HttpSessionStorage    : Storing message a4i8jj75fe214b70bdf27dg8idc2a9 to session F26763C072560A421B54CBBB2C4BC8C3

收到回复后

o.s.s.saml.storage.HttpSessionStorage    : Message a4i8jj75fe214b70bdf27dg8idc2a9 not found in session E59A025009ADD06BB3F35F8250A66208

注意反向代理情况下会话 ID 的差异

任何帮助将不胜感激。

【问题讨论】：

我的部分问题正是***.com/questions/46301883/…中解释的内容

【参考方案1】：

终于找到问题了。

在 Zuul 中，sensitiveHeaders 的默认值为Cookie,Set-Cookie,Authorization

现在，如果我们不设置属性本身，那么这些标头将被视为敏感的，并且不会向下游传输到我们的服务。

必须将sensitiveHeaders 值设置为空，以便将cookies 传递给服务。 Cookie 包含我们的 JSESSIONID，它标识了会话。

zuul: 
  sensitiveHeaders: 
  routes:
    admin-ui: 
      path: /admin/**
      service-id: admin-ui
      strip-prefix: false
      customSensitiveHeaders: false