SAML error "InResponseToField of the Response doesn't correspond to sent message errors" in VMware Tanzu Application Service (TAS) for VMs

Products

• VMware Tanzu Application Service for VMs

Issue/Introduction

When using chrome as your browser and trying to authenticate with a SAML provider, such as VMware Identity Manager (VMID), when you log into Apps Manager and other similar services you get the following error message: InResponseToField of the Response doesn't correspond to sent message

Environment

Product Version: 2.10

Cause

This issue arises due to the session ID getting lost during the request/response interaction between UAA and the SAML IDP. More information regarding why this happens can be found in the following article: SameSite default value of __VCAP_ID__ cookie changes with Chrome 80 release VMware Tanzu Application Service (TAS) for VMs

Resolution

In summary, UAA will redirect you to the SAML IDP along with a request for the SAML assertion. Once the user enters his/her credentials, you are redirected back to UAA along with the SAML assertion. If the original session ID is not present, then it's possible that the request will go to a UAA instance that did not initiate the request.

Since UAA holds the request information in memory locally and is not shared among all instances of UAA, the request will be invalidated, unless we tell UAA not to ignore validation. As you can see, this issue only occurs if you have more than one instance of UAA.

To workaround this, you need to set a property on UAA to disable this request/response validation.

Note: This modification should be considered temporary, as the next deployment through Ops Manager will overwrite this update.

1. Go to the Ops Manager VM and navigate to /var/tempest/workspaces/default/deployments.

2. Find the CF deployment YAML, which would have a file name that looks like cf-xxxxxx.yml.

3. Edit this file in an editor and go to the SAML section. This section should look something similar to: 

saml:
          activeKeyId: key1
          serviceProviderKey: ''
          serviceProviderKeyPassword: ''
          providers:
          signRequest: true
          signatureAlgorithm: SHA256
          entityid: http://login.sys.skynetsystems.io
          serviceProviderCertificate: ''
          wantAssertionSigned: false

4. Add the property disableInResponseToCheck: true to this section. The SAML section should now look similar to the following now:

saml:
          disableInResponseToCheck: true
          activeKeyId: key1
          serviceProviderKey: ''
          serviceProviderKeyPassword: ''
          providers:
          signRequest: true
          signatureAlgorithm: SHA256
          entityid: http://login.sys.skynetsystems.io
          serviceProviderCertificate: ''
          wantAssertionSigned: false

5. Perform a manual deploy using the edited CF manifest using the following command:

bosh -d cf-xxxxxx deploy cf-xxxxxx.yml

6. This deployment should be fairly quick as it's only updating UAA. Once completed, verify that the issue is no longer present.