Working with SAML for single sign-on (SSO)

Venafi Platform allows you to use modern single sign-on (SSO) identity providers (like Okta, Azure, Ping Identity, etc.) that use the SAML 2.0 standard. Using a third-party identity provider can greatly enhance your security posture. For example, they can simplify configuration of two-factor authentication (2FA), a protection against phishing threats and other password vulnerabilities.

Venafi Platform has long allowed you to use a variety of single sign-on methods like Windows authentication and certificate authentication. With the ability to connect to identity providers (IDP) via SAML, you have even more options for protecting your machine identity management system.

In this release of Venafi Platform, there are some items you should be aware of:

  • When you import the identity provider SAML file, the associated certificate is automatically enrolled in TLS Protect at the monitoring level. A higher level of enrollment is not possible, since SAML certificates are not issued and imported like a normal certificate. To renew the SAML certificate you need an entirely new identity provider metadata file.
  • Venafi Platform requires the entire SAML Response to be signed (but not encrypted, which is not supported). Some IDPs only sign the Assertion, so you may need to specify signing the entire Response.
  • We do not support signed authentication requests.
  • The default search expression will need to be changed, as documented in the phase one instructions.
  • We do not currently support single log out (SLO), however, we do support a Logout URL, if your IDP allows you to log out by simply visiting a URL.
  • We do not support forced log on.
  • You can only configure one Authentication connector at a time. We don't support multiple connectors.

  • While any SAML 2.0 IDP should work, we have tested with the following:

    • Active Directory
    • Azure
    • Okta
    • Ping
  • The clock skew allowance is set to 180 seconds. The Venafi server and IDP server time can be off by 180 seconds and still sign in.

Configuration process

There are three high-level steps to configure SAML SSO for Venafi Platform.

Phase 1. Prepare Venafi Platform for SAML and obtain the Service Provider Metadata XML file. See the steps in Prepare Venafi Platform for SAML SSO.

Phase 2. Configure the Identity Provider and obtain the IDP Metadata XML file. The steps for phase two depend on your IDP. We've tested and outlined the following:

Phase 3. Configure SAML on your Venafi server. See the steps in Importing Identity Provider Metadata XML into Venafi Configuration Console for SAML.

If you have questions, try reviewing SAML troubleshooting tips.

Technical implementation details

On the SAML signing certificate we verify:

  • The certificate is not expired
  • The certificate matches the certificate we have on file for the SAML profile
  • The correct certificate was used to create the signature
  • The signature is still valid (validity period hasn't expired and certificate has not been revoked).

The SAML Response must:

  • Contain the ID attribute
  • Contain the version attribute, and the version must be 2.0
  • The InResponseTo attribute must match TPP's authentication flow
  • Have a signature on the response
  • The destination must be entered, and must match the FQDN of the Venafi cluster
  • Status must be present, and have a value of Success
  • Issuer must be present, and must match the issuer on the SAML profile

The SAML Assertion must:

  • Contain the version attribute, and the version must be 2.0
  • Audience attribute must equal the Venafi Platform service provider ID
  • Contain a Subject
  • SubjectConfirmation attribute must be present, and have the method of bearer
  • If the assertion is signed, the signature must be valid (however, the assertion does not need to be signed)
  • The NotBefore and NotAfter attributes in the Conditions are validated, respecting clock skew
  • Contain the Issuer, which must match the issuer on the SAML profile
  • Assertion ID must be present
  • The NotOnOrAfter attribute must be present in the assertion