When IG is acting as the service provider (SP), the SAML federation flow fails upon receiving the SAML response from the IdP. You will see the following error in the route logs when this happens:20210705-11:29:01:831 | ERROR | https-openssl-nio-18443-exec-1 | o.f.o.h.s.ChfHttpServletRequestAdapter | SAML2 error triggered - httpStatusCode: 400, errorCode: invalidACSLocation and errorMessage: Invalid Assertion Consumer Location specified 20210705-11:29:01:831 | ERROR | https-openssl-nio-18443-exec-1 | o.f.o.h.s.SamlFederationHandler | SSO Failed: Invalid Assertion Consumer Location specified
The incoming request URI in the SAML flow does not match the Assertion Consumer Service Location URLs set in the SP metadata (sp.xml). When this happens, the flow fails with the Invalid Assertion Consumer Location specified error. This error can happen for a number of reasons, including, but not limited to:
- The Assertion Consumer Service Location URLs set in the SP metadata are different to the incoming request URI.
This may simply be that the URLs are different or the Assertion Consumer Service Location URLs set in the SP metadata do not include the port. Since IG 6.5.3, you must always specify the port in the sp.xml, even when using default port values (443 or 80). This change occurred because IG uses AM's federation libraries, and AM 6.5.3 introduced checks to ensure the URLs specified in the Assertion Consumer Service exactly match the SP's scheme, FQDN and port for improved security. See Important Changes in AM 6.5.3 (SAML v2.0 Assertion Consumer Service URLs Must Exactly Match) for further information.
- The baseURI decorator is set in the top level of the route, which alters the incoming SAML request URI and causes a mismatch with the Assertion Consumer Service URL set in the SP metadata. This is likely to be an issue if you have created a single route that combines the processing of SAML requests (using the SamlFederationHandler) with other requests.
- There's a reverse proxy or load balancer in front of IG which is doing SSL Offloading, which alters the incoming URI.
This issue can be resolved as follows, depending on the cause:
- Make sure the Assertion Consumer Service Location URLs specified in the sp.xml file exactly match the incoming request URI, including the port. For example, they would look similar to this if you're using a default port:<AssertionConsumerService isDefault="true" index="0" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://sp.example.com:443/fedletapplication" /> <AssertionConsumerService index="1" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://sp.example.com:443/fedletapplication" />
Share your updated metadata, if needed, with the IdP.
- Move the baseURI decorator into a handler that deals with all the other requests rather than specifying the baseURI at the top level of the route. If you are using IG 7.1 and later, you can alternatively set the useOriginalUri property in the SamlFederationHandler to force the handler to use the original URI instead of the rebased URI when validating RelayState and Assertion Consumer Location URLs. See SamlFederationHandler for further information.
See How do I use the baseURI and originalURI in IG 6.x and 7.x? for further information on using the baseURI effectively.
- Apply one of the solutions discussed in IG (All versions) redirects to HTTP when a reverse proxy or load balancer is doing SSL/TLS offloading depending on the version you are using, and whether IG is in web container mode or in standalone mode.