Spring SAML with reverse proxy - inresponsetofield of the response doesn't correspond to sent message

[veeru-as]

We have our spring boot app which is integrated with Spring SAML. And we are also using Spring SAML DSL in WebSecurityConfigurerAdapter to initiate the SAML context.

Here is how we have configured the http security for SAML using SAML DSL.

    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);

Notice the hostname and port. I have given proxy's hostname and port.

Our boot application is running on https://localhost:8443/admin. In this case SAML is working absolutely fine.

Now we are trying to use Zuul as a reverse proxy for our application.

Now is zuul will be running on localhost:9000. Here is the zuul route config

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

Here is the application configuration on OKTA

Now, when we access our application via https://localhost:9000/admin/ and try to login with SAML, we are getting below error while authenticating in spring SAML.

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

I found out that while sending the AuthNRequest, the message ID is getting stored to HTTP Session storage. But when the response comes back, the session storage it empty. May be its creating a new session.

Went through the docs, and found that we have to use SAMLContextProviderLB. This is already being used by SAML DSL.

There are multiple questions in SO similar to the problem but not exactly with load balancer/proxy.

How do we tell spring saml to preserve the session till the SAML auth process is complete?

Again, this problem is only while using our application with a reverse proxy like ZUUL.

Here are the logging statements with session ID:

In working case

before sending request

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

After receiving response

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

In case of sending via reverse proxy(ZUUL)

before sending request

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

After receiving response

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

Notice the difference in the session ID in case of reverse proxy

Why is that its creating a new HTTP Session when we are working with Zuul proxy?

[veeru-as]

Finally found out the issue.

in Zuul, the sensitiveHeaders has got a default value of Cookie,Set-Cookie,Authorization

Now if we dont set the property itself, then these headers are going to be treated as sensitive and doesnt get flown downstream to our service.

Had to set the the sensitiveHeaders value to empty so that the cookies get passed on to the service. Cookie contains our JSESSIONID which has identifies the session.

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

[KarthikTamilarasan]

I have faced similar issue while working deploying the application on Azure app service. I was able to resolved the issue after maintaining same session while saving and verifying the data. Thanks for sharing the above details .