SP-initiated SAML breaks when the vendor enforces signed AuthnRequests
A 1,600-user healthcare SaaS company uses Okta to connect to 42 SAML apps. The vendor for ChartBridge recently changed its security requirements: every SAML AuthnRequest sent to Okta must be signed with the vendor's new certificate, and the assertion must be encrypted. The Okta app configuration was updated with the new assertion encryption certificate, but the Request Signature setting was left unchanged. IdP-initiated sign-in from the Okta dashboard still works. SP-initiated sign-in from ChartBridge fails before the Okta login page renders; users see Invalid AuthnRequest signature. The vendor's metadata URL has not changed, and the old signing certificate is still published alongside the new one until the end of the quarter. 220 clinical staff are affected, including weekend shift workers.
1. Why does IdP-initiated sign-in still work while SP-initiated fails? What does that tell you about where to look?
Read the worked answer
IdP-initiated sign-in starts at Okta, so no AuthnRequest is sent from ChartBridge to Okta. Okta creates the assertion and sends it to the configured ACS URL. SP-initiated sign-in starts at ChartBridge, which sends a signed AuthnRequest to Okta. If Okta has not been configured to validate that vendor signature, the flow fails before the login page renders. That points to the SAML request-validation settings, not to the assertion signing or encryption settings. The assertion encryption certificate change was probably necessary but insufficient. I would inspect the app's SAML settings for the request-signing certificate, confirm that request signature validation is enabled, and verify that the certificate matches the vendor's current signing certificate. The fact that IdP-initiated works is useful evidence, but it is not proof that the full SAML configuration is correct.
2. List the configuration checks and the order you would perform them, including how to avoid breaking the 220 users during the fix.
Read the worked answer
I would work from the vendor metadata outward. First, download the current metadata and compare the entity ID, SSO URL, and signing certificate with the Okta app. Second, in the Okta SAML app, open the Sign On settings and verify the single sign-on URL and audience URI still match the vendor. Third, under advanced settings, upload the vendor's current public signing certificate for request signing and enable Request Signature. Do not change assertion signing or encryption at the same time; isolate one variable. Fourth, test with a pilot account using SP-initiated sign-in from ChartBridge and inspect the SAML tracer to confirm the AuthnRequest is signed and accepted. Fifth, communicate to the weekend shift before the change window, keep the old certificate available until the vendor retires it, and document a rollback that disables request signing only if the vendor temporarily reverses its requirement.
3. The vendor says to enable SHA-1 because a legacy client still needs it. How do you respond?
Read the worked answer
I would not downgrade the whole app to SHA-1 without isolating the risk. First, confirm which client actually requires SHA-1 and whether it is a supported browser, a middleware component, or an old integration. If only a small legacy client is affected, the better answer is to keep SHA-256 for the main app and handle the legacy client separately, or require the vendor to fix its client. If a temporary exception is unavoidable, I would document the risk, limit it to a separate app or tenant, set an expiry date, and add monitoring. The judgement is to avoid weakening the authentication path for 220 clinical users because of one legacy component. Security requirements should be met by fixing or isolating the exception, not by globally disabling modern signing.