SAML config save fails: Okta IdP certificate wrongly rejected (validator requires cert CN to equal okta.com domain)

SAML config save fails: Okta IdP certificate wrongly rejected (CN must equal okta.com domain)

Component: openmetadata-service — Security / SAML Type: Bug Severity: High — blocks editing/saving SAML SSO configuration for any Okta-based deployment via the UI Affected versions: 1.12.x and current main (validation code unchanged)

Summary

Saving a SAML SSO configuration that uses an Okta IdP fails validation with an "IdP X.509 Certificate" error, even when the certificate is valid and unchanged. The certificate validator requires the IdP certificate's Common Name (CN) to equal the Okta domain (www.okta.com or *.okta.com), but Okta application signing certificates are issued with CN = <org name> (e.g. CN=my-company, O=Okta), never the okta.com domain. As a result the check rejects essentially every legitimate Okta SAML signing certificate.

Steps to reproduce

1. Configure SAML SSO with an Okta IdP. The IdP Entity ID is the standard Okta form: http://www.okta.com/<appId>.
2. Provide the IdP X.509 signing certificate from Okta's metadata (CN is the org name).
3. Edit and save the security configuration (UI → PATCH /api/v1/system/security/config, which validates).

Expected: Configuration saves; certificate is accepted because it parses and is within its validity window. Actual: Save is rejected with a field error on the IdP X.509 certificate: Okta certificate validation failed. Certificate CN '<org>' does not match Entity ID domain 'www.okta.com'

Root cause

SamlValidator.validateIdpCertificateAgainstConfig(...), Okta branch:

if (entityIdDomain != null && entityIdDomain.contains(".okta.com")) {
  if (!certCN.equals(entityIdDomain) && !certCN.equals("*.okta.com")) {
    throw new CertificateException("Okta certificate validation failed. ...");
  }
}

• entityIdDomain is derived from the IdP Entity ID host → www.okta.com.
• certCN for an Okta app signing cert is the org name, not a domain.
• The equality check therefore always fails for valid Okta certificates.

The certificate is already structurally validated earlier in validateX509Certificate(...) (parses as X.509, not expired / not-yet-valid). The CN-equals-domain assumption is only meaningful for Auth0-style tenant certs, not Okta.

Impact

• Any Okta SAML customer is blocked from saving/editing SSO config through the validating path (UI). Commonly surfaces during a domain change or routine config edit, where a re-save triggers validation for the first time.
• The error is misleading: it points at the certificate field, leading users to repeatedly re-format/re-upload a certificate that was never the problem.

Suggested fix

Relax the Okta branch so it does not require certCN == entityIdDomain. Options:

1. Drop the hard failure for Okta and downgrade to the same non-fatal warning used for generic providers (log a warning if CN doesn't match, do not throw). Rely on the existing parse + validity checks.
2. If stronger validation is desired, validate against attributes that Okta certs actually carry (e.g. O=Okta) rather than CN-equals-domain.

A regression test should cover an Okta IdP whose certificate CN is an org name (not a domain) and assert that validation passes.

Workaround (operator)

Persist the configuration via PUT /api/v1/system/security/config (admin token), which writes and hot-reloads the auth system without running this validation. The UI uses the validating PATCH path, which is why the UI is blocked.