Tenable Security Center SSO with Okta

Hello @avshch (BCRC)​ Thank you for posting on our Community page!

You are asking whether anyone has successfully implemented SSO between Okta and Tenable Security Center (on-premises) using the SAML authentication flow documented by Tenable, and whether there are known issues with IdP-initiated authentication flows when SP-initiated flows are already working.

IdP-initiated SAML flows are supported by Okta, but they require specific configuration on both the identity provider (Okta) and service provider (Tenable Security Center) sides. The fact that SP-initiated flow works but IdP-initiated does not suggests a mismatch in how Tenable Security Center is configured to handle unsolicited SAML assertions or RelayState parameters.

Root Cause:

IdP-initiated flows differ from SP-initiated flows in a critical way: the user initiates login directly from the Okta dashboard (or a direct link to Okta's assertion consumer service endpoint), and Okta sends a SAML response without a prior authentication request from the service provider. Tenable Security Center may not be configured to accept unsolicited assertions, or it may require specific RelayState handling that differs from the SP-initiated setup.

Solution:

Follow these steps to troubleshoot and configure IdP-initiated authentication:

1. Verify Tenable Security Center accepts unsolicited SAML assertions. Consult the Tenable Security Center SAML configuration documentation (the article you referenced) to confirm that IdP-initiated flows are explicitly supported. Some on-premises deployments require a specific configuration flag or metadata setting to enable this.
2. Check the Okta app's SAML settings for RelayState handling. In the Okta Admin Console, navigate to Applications → your Tenable app → Sign On. Scroll to the SAML 2.0 section and verify that the Default RelayState field is configured. For IdP-initiated flows, this field should contain the URL where users should be redirected after successful authentication (typically the Tenable Security Center dashboard or a specific page within it).
3. Confirm the Assertion Consumer Service (ACS) URL is correct. In the same SAML 2.0 section, verify that the Single Sign-On URL (ACS URL) matches exactly what Tenable Security Center expects. Mismatches between what Okta sends and what Tenable accepts will cause IdP-initiated flows to fail.
4. Test IdP-initiated flow from the Okta dashboard. Assign the Tenable app to a test user, have that user log into Okta, and click the Tenable app tile. Monitor the browser's network tab or Tenable's authentication logs to see what SAML response Okta is sending and whether Tenable is rejecting it.
5. Review Tenable Security Center logs for SAML errors. Check Tenable's SAML authentication logs (typically in the Security Center web interface under Administration → Logs or similar) for specific error messages. Common issues include "Invalid Audience," "Invalid Recipient," or "Unsupported assertion format."
6. If Tenable Security Center requires a specific RelayState value, configure it in Okta. Some on-premises SAML implementations expect a particular RelayState parameter. If Tenable's documentation specifies a required RelayState value, enter it in the Okta app's Default RelayState field.
7. Contact Tenable Support if the issue persists. If you have verified all Okta-side settings and Tenable Security Center still rejects IdP-initiated assertions, reach out to Tenable Support with your Okta IdP metadata and Tenable's SAML logs. They can confirm whether your on-premises deployment supports IdP-initiated flows and provide any deployment-specific configuration.

Thank you for reaching out to our Community and have a great day!

--

Help others in the community by liking or hitting Select as Best if this response helped you.