Single sign-on (SSO)

Fix SAML single sign-on errors

When SAML single sign-on (SSO) to the Ploy dashboard fails after you configure your identity provider, the fix is usually one of three things: map an email attribute in the assertion, sign the SAML response, or regenerate the identity provider metadata from a SHA-2 certificate. Match your symptom below.

After completing sign-in at your identity provider, the browser shows "SAML authentication failed"

We could not read a usable email address from the assertion. Ploy looks for an attribute named one of:

  • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

  • http://schemas.xmlsoap.org/claims/EmailAddress

  • emailaddress

  • email

If none of those attributes is present, Ploy falls back to the Subject NameID, and only when its format is exactly urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress. The email is trimmed and lowercased, and a blank value is rejected.

Fix: map an email attribute using one of the accepted claim names, or send the email as an email-format NameID.

  • Okta: expand Show legacy configuration and add a Profile attribute statement with Name email, Name format Unspecified, and Value user.email.

  • Microsoft Entra ID: add the claim http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress mapped to user.mail as an additional claim.

Sign-in fails with access denied and an error like {:envelope, {:error, :no_signature}}

The SAML response envelope is not signed. We require the response envelope to be signed: a signed assertion with an unsigned response is not enough.

Fix: sign the response.

  • Okta: set Response to Signed.

  • Microsoft Entra ID: set Signing Option to Sign SAML response and assertion.

Assertion encryption is not required, and unencrypted assertions are accepted.

Sign-in fails even though the ACS URL, Entity ID, and NameID format all match Ploy's SP metadata

The identity provider metadata XML you imported into Ploy came from a SHA-1 certificate. We reject SHA-1 signatures and digests.

Fix: regenerate or download the identity provider metadata XML from the SHA-2 certificate (in Okta, the metadata comes from the SHA-2 cert, not SHA-1) and update the metadata in Single Sign-On (SSO) in your organization settings.

How Ploy handles SAML

You can start sign-in from your identity provider or from Ploy; both flows are supported. Ploy signs its own authentication requests and its service provider metadata.

Was this helpful?
Was this helpful?