Skip to main content
Any standards-compliant SAML 2.0 identity provider works with OpenCX. Use this guide for OneLogin, JumpCloud, Ping Identity / PingFederate, Duo SSO, Auth0, on-prem Microsoft AD FS, or anything else that speaks SAML 2.0. The mechanics are identical, only the admin console differs.
If you’re on Microsoft Entra ID, Okta, or Google Workspace, use the dedicated guide instead; it names the exact screens: Entra ID, Okta, Google Workspace.

The values you exchange

You give OpenCX your IdP metadata; OpenCX gives you the service-provider (SP) values below. Every SAML IdP has a field for each. OpenCX → your IdP (SP values): Your IdP → OpenCX (metadata): your IdP metadata URL (preferred) or metadata XML, which contains your issuer/entity ID, SSO endpoint, and signing certificate. Hand this to your OpenCX contact.

Required assertion shape

For OpenCX to accept a login, the signed SAML response must satisfy all of the following:
Set Name ID format to urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress and the value to the user’s primary email. OpenCX keys the member identity on this, a non-email Name ID (e.g. a directory GUID) causes duplicate accounts on re-login.
Send these attributes so OpenCX can create and display members:
To drive OpenCX roles from your directory, send a multi-valued groups attribute containing the user’s group names or IDs. Map these to OpenCX roles in role mapping. Without it, everyone lands as the default role.
The SAML response and/or assertion must be signed with your IdP’s certificate (the one in your metadata). OpenCX rejects unsigned assertions. Signed and encrypted assertions are supported on request.

Setup

1

Create a SAML app in your IdP

Create a new SAML 2.0 application (sometimes called “relying party trust” in AD FS, “connector” in Auth0, or “custom SAML app” elsewhere).
2

Enter the OpenCX SP values

Paste the SP Entity ID and ACS URL from the table above into your IdP’s audience/entity and ACS/reply fields.
3

Set Name ID and attributes

Configure Name ID as email, and add the email / first name / last name attributes (and groups if you’re mapping roles).
4

Sign the assertion

Ensure response/assertion signing is enabled with your IdP certificate.
5

Send your metadata to OpenCX

Give us your metadata URL (preferred) or XML. We register your issuer, SSO endpoint, and certificate on your connection.
6

Assign users

Grant a pilot group access in your IdP, then expand once it passes.

AD FS specifics

Add a Relying Party TrustEnter data manually (or import the OpenCX SP metadata if you’re given a URL). Use the ACS URL as the SAML 2.0 SSO service endpoint and the SP Entity ID as the relying party identifier.
Add a Send LDAP Attributes as Claims rule mapping E-Mail-Addresses → E-Mail Address, Given-Name → Given Name, Surname → Surname, and Token-Groups → a groups claim. Then a Transform rule mapping the E-Mail Address claim to Name ID with format Email.
AD FS publishes federation metadata at https://<your-adfs-host>/FederationMetadata/2007-06/FederationMetadata.xml. Give that URL to OpenCX so certificate rollovers are picked up automatically.

Test and enforce

1

Test SP-initiated login

In a private window, go to platform.open.cx, enter a pilot’s work email, and confirm the round trip to your IdP and back into the Inbox.
2

Confirm the role

Verify the pilot’s OpenCX role matches your group mapping.
3

Enforce

When clean, ask OpenCX to enforce SSO. Read the pre-cutover checklist and secure your break-glass account.

Troubleshooting

See Troubleshooting SSO for assertion, attribute, clock-skew, and certificate errors that apply to every SAML IdP.