Configuring SAML SSO with a load balancer

[#1]

Recently when configuring SAML-Based SSO between IdentityNow and IdentityIQ, I ran into the following error message:

2017-03-27 16:16:05,154 ERROR http-nio-8080-exec-4 common.binding.decoding.BaseSAMLMessageDecoder:215 -

SAML message intended destination endpoint 'https://identityiq.test.com/identityiq/dashboard.jsf'

did not match the recipient endpoint 'http://identityiq.test.com/identityiq/dashboard.jsf'

2017-03-27 16:16:05,154 ERROR http-nio-8080-exec-4 sailpoint.web.sso.SAMLSSOAuthenticator:320 - org.opensaml.xml.security.SecurityException:

SAML message intended destination endpoint did not match recipient endpoint

First, some background on the environment and components in play here:

IdentityIQ 7.1

Tomcat 8.5.11

IdentityNow

F5 BIG-IP

The reason the error was being thrown was because of the way we configured the F5 Load Balancer and the backend Tomcat applications.  The Load Balancer in this scenario was handling SSL Offloading.  Users accessed IdentityIQ by navigating to https://identityiq.test.com/identityiq/login.jsf.  The Load Balancer would then handle proxying that traffic to the backend Tomcat application servers which were listening on http://hostname1.test.com:8080/identityiq/login.jsf and http://hostname2.test.com:8080/identityiq/login.jsf.  Initially, the process was working adequately with Active Directory pass-through authentication. 

When SAML SSO was enabled with IdentityNow, authentication would fail regardless of if the request was IdP-initiated or SP-initiated.  The genesis of the problem was that we had the Tomcat application instances listening on port 8080 over HTTP, while IdentityNow was configured with https://identityiq.test.com/identityiq/dashboard.jsf as the SAML Assertion Consumer Service URL for IdentityIQ.  If it was updated to http:// instead the request would fail because the Load Balancer wasn't listening on HTTP.

The solution for this specific configuration was to update the server.xml files for Tomcat (in the /tomcat/conf folder).  Out of the box, Tomcat has the following configuration:

<Connector port="8080" protocol="HTTP/1.1"

           connectionTimeout="20000"

           redirectPort="8443" />

In order to make this functional, the Connector entry was updated to the following:

<Connector port="8080" protocol="HTTP/1.1"

           connectionTimeout="20000"

           proxyPort="443"

           scheme="https" />

Once the configuration was updated, the "does not match recipient endpoint" error went away.  Those additional entries instructed Tomcat to return 443 when a request.getServerPort() command is issued and to return https when request.getScheme() is called.

[sunnyajmera]

had the same issue, the provided solution worked for me. Thanks.

[gkabra]

Excellent! This worked for me. I would be very intrested to know how did you that find the problem was with Apache configurations. Might be very useful to know the debugging steps.

[IIQUserOnCompass]

Wouldn't you also need to specify proxyName?

[jeff_haima]

One note I will add, I needed to add this to each server that was being load balanced. When I only had it configured for some of the servers it did not work at all and I couldn't even load the dashboard.jsf page.

[mattsayar]

@IIQUserOnCompass adding proxyName fixed it for me, however I had a slightly different problem. I was getting this error message because tomcat was changing the URL to the hostname of the server, so it was saying "<my-fancy-url>/identityiq/dashboard.jsf did not match the recipient endpoint at <hostname>:8080/identityiq/dashboard.jsf".

The below fixed it

<Connector port="8080" protocol="HTTP/1.1"
           connectionTimeout="20000"
           proxyPort="443"
           proxyName="<my-fancy-url>"
           scheme="https" />

[vkodali]

Does this work with SSL configuration as well on tomcat?