Big-IP SAML2.0 IdP to same SP back-end for multiple host aliases

Description

I'm wondering how it can be achieved to configure SAML2.0 on APM as IdP in a way to prevent No RelayState mapping found for RelayState value xxx errors when coming from an FQDN for which SAML2.0 has not been configured.

Example

Having abc123xyz.acme.com exporting SP Metadata and importing IdP Metadata based on this host alias, for which SAML2.0 is operating as expected. Now our customer are not able to remind abc123xyz.acme.com, so we are offering fancypad.acme.com (super easy to remind) but getting back RelayState error, which is obvious because for fancypad.acme.com alias no SP IdP relation has been configured.

Question

Its possible on SP side to configure the IncomingRequest parameters to send the application URL, for example, but it will depend if the f5 IdP can differentiate it and send to the same host that did the request?

There are customers having used a BIG-IP or other appliances which mentioned forwarding requests to the correct SPs based on specific host aliases and Service-URLs. Thus the URL was appropriately masked and rewritten by the reverse proxy. The host header was replaced with the host value extracted from the matched ACS URI of the internal SP.

Would lead to the following example which illustrates the Assertion Consumer Service endpoints for an SP that is only using the SAML2 HTTP-POST

binding.

Binding                                                                                Endpoint                                                       Status 

urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST         https://abc123xyz.acme.com/sso/SAML2/POST             Pre-existing

urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST         https://fancypad.acme.com/sso/SAML2/POST             Need to add

The question is, how to overcome this behaviour which is leading to 'No RelayState mapping found for RelayState value xxx'?

Any help would be greatly appreciated, best wishes

Florian