I have APM setup as an SP, bound to an external IdP. The flow is the user logs into the IdP and clicks on the link to my SP FQDN to serve as an IdP inititated SAML auth. Access Policy is simple, just a SAML Auth followed by a SSO variable assign. In the APM debug logs, we see where APM believes the inbound request to be a SP inititated request and an AuthN request is sent back to the IdP, resulting in the user being 302 redirected back to the IdP login page. Everything is encrypted so hard to say just yet but am I right to think that the SAML assertion is either not being generated properly from the IdP and sent over or the encryption keys/certs are wrong? Anything else I can do to troubleshoot before I strip off all the encryption requirements to get a look into the payload?
To add to that. The IdP is sending the AudienceRestriction attribute in the SAML POST. From what I have read, when this is sent, the F5 EntityID , the ACS, and this Attribute all need to match. I do not think the F5 SAML SP ACS can be modfied which means we need to use the exact URI that ends in /ACS on the F5 APM consumer service. That said, when you try to add multiple IdP bindings to your SP, it asks you for a specific Landing URI. If they all have to match the AudienceRestriction there is no way to differentiate, hense negating the ability to do many to one Idp to SP. Is that accurate? Any suggestions or known best practices here?