SnowPro Advanced: Security Engineer Question 41
Single answerTroubleshoot SSO integration issuesA company uses federated authentication for Snowflake with an external SAML 2.0 identity provider (IdP). After a planned IdP certificate rotation, users can still authenticate successfully to other enterprise applications, but Snowflake SSO starts failing for all browser-based logins. When users attempt to sign in, Snowflake returns a SAML validation error indicating the response signature cannot be verified. The Snowflake security engineer confirms that the account URL, ACS URL, and entity ID configured in the IdP are unchanged. Which action should the engineer take first to restore SSO access?
- A
Update the Snowflake security integration to use the IdP's new SAML2_X509_CERT value
- B
Alter the affected users to set RSA_PUBLIC_KEY so Snowflake can validate signed SAML assertions
- C
Regenerate the Snowflake account's key pair and upload the new public key to the IdP
- D
Change the network policy to allow the IdP's source IP addresses so signed SAML responses are accepted
Show answer and explanation
Correct answer: A
Explanation
This scenario points directly to a common SSO troubleshooting pattern: authentication began failing immediately after an IdP certificate rotation, and the error indicates Snowflake cannot verify the SAML signature. In Snowflake SAML SSO, the security integration stores the IdP metadata required for validation, including the IdP signing certificate via parameters such as SAML2_X509_CERT. If the IdP starts signing assertions with a new certificate and Snowflake still trusts the old one, all SSO attempts will fail with signature validation errors. Because the account URL, ACS URL, and entity ID were confirmed unchanged, the most likely root cause is the stale signing certificate in the Snowflake security integration. Best practice when troubleshooting SSO is to isolate whether the failure is due to endpoint mismatch, audience/issuer mismatch, username mapping, or certificate/signature validation. A certificate rotation that affects only Snowflake strongly suggests a trust configuration issue on the Snowflake side. Relevant Snowflake documentation includes SAML 2.0 federated authentication configuration and managing security integrations, especially the certificate-related settings used for validating IdP-signed SAML responses.
- A. Correct.
Correct. In Snowflake SSO with SAML 2.0, Snowflake validates the signature on the SAML response/assertion using the IdP signing certificate configured in the security integration. If the IdP rotates its signing certificate and Snowflake is still using the old certificate in SAML2_X509_CERT, signature verification will fail even if URLs and identifiers remain unchanged. Updating the security integration with the new IdP certificate is the appropriate first remediation step.
- B. Incorrect.
Incorrect. RSA_PUBLIC_KEY on a Snowflake user is used for key-pair authentication, not for validating SAML assertions from an external IdP. This option reflects a common confusion between Snowflake key-pair authentication and federated SSO. SAML signature validation is performed against the IdP certificate stored in the SSO security integration, not against per-user RSA keys.
- C. Incorrect.
Incorrect. Snowflake account key pairs are not what the IdP uses to sign SAML responses to Snowflake. In a typical Snowflake SAML federation setup, the IdP signs the assertion and Snowflake validates it using the IdP certificate. Regenerating a Snowflake key pair would not resolve an IdP certificate rotation issue and would introduce unnecessary changes.
- D. Incorrect.
Incorrect. Network policies can block access based on client IP, but they do not affect cryptographic validation of a SAML response signature. The error specifically indicates signature verification failure, which points to a certificate or signing configuration mismatch rather than source IP filtering.