SAML IdP Metadata Renewal and NameID Mismatch
A financial services firm uses FortiAuthenticator 6.5 as its SAML identity provider for 1,500 users. Salesforce SP-initiated SSO has worked for a year. A newly deployed custom SP now fails: users authenticate at FAC, then receive either Invalid signature or Audience restriction mismatch. The SP administrator refreshed metadata yesterday and changed the ACS URL from https://sp.example.com/saml/consume to https://sp.example.com/auth/saml/consume. The FAC IdP signing certificate was renewed last week, but the custom SP still has the old metadata. FAC NTP is four minutes behind the SP. The FAC NameID format is Unspecified; the SP expects the user email address. A few users also report that IdP-initiated login returns them to the FAC portal instead of the application. The SP entity ID is urn:example:sp and the expected audience is https://sp.example.com/saml. FAC SAML logs show Signature validation failed and Subject not found.
1. Rank the likely causes of the SP-initiated failures and describe the checks you would perform in order.
Read the worked answer
First compare metadata on both sides: the SP entity ID and audience must match what FAC has for that SP, and the ACS URL must be the new https://sp.example.com/auth/saml/consume. The old ACS URL alone can produce audience or recipient mismatch. Second, the SP still trusting the old IdP signing certificate explains the signature failure after renewal; import the new FAC metadata into the SP or install the new signing certificate. Third, four minutes of clock skew can invalidate assertions; correct NTP on both systems. Fourth, the NameID issue is separate and often appears as Subject not found. Work in that order because metadata and signature errors block all users, while NameID affects only attribute-dependent logins. Use a SAML tracer and FAC SAML logs to confirm which assertion field is rejected.
2. How should NameID and attributes be configured so the custom SP receives email without breaking Salesforce?
Read the worked answer
Do not change the global IdP NameID setting if Salesforce already works. In FortiAuthenticator, create or edit the custom SP entry, set the NameID format to emailAddress if the SP accepts that standard format, or leave Unspecified and release an email attribute with the exact name the SP expects. Add an attribute mapping such as mail or email from the FAC user record, and confirm the SP accepts the name. Test SP-initiated login for a user with a populated email attribute and a user with a missing email to see the failure mode. If the SP requires a persistent opaque identifier, use a stable attribute rather than email. Keep Salesforce on its existing SP profile so its NameID behavior is not changed.
3. What is needed for IdP-initiated login to land in the custom SP rather than the FAC portal?
Read the worked answer
IdP-initiated login needs a target SP and a response consumer URL. In the FAC SAML IdP configuration, ensure the custom SP is enabled for IdP-initiated SSO and that the default relay state or landing URL points to the SP ACS endpoint, not the FAC portal. The SP must accept unsolicited SAML responses; not all SPs do. Generate the IdP-initiated login URL or portal tile for that SP, then test in a private browser. If the SP rejects unsolicited assertions, use SP-initiated login instead. Also verify that the FAC portal tile is assigned to a group that includes the test users; otherwise the tile returns them to the portal.