Setting up SAML with Okta

The Okta side of a SAML setup, and the two settings that cause most of the failures: which address is sent, and who the application is assigned to.

The Okta side of a SAML setup, and the two settings that cause most of the failures: which address is sent, and who the application is assigned to.

Set it up

1. Add Zendesk as an application in Okta.
2. Configure the SAML settings with your Zendesk details.
3. Map the email attribute.
4. Assign the application to the right group of people.
5. Copy the certificate and sign-in address into Zendesk.
6. Test with one account in a private window.

Failure one: the email attribute

Zendesk identifies people by email address. If Okta sends a username, an identifier or a different address, the sign-in either fails or creates a new user.

Check what is actually being sent, not what you configured.

Failure two: assignment

An application configured perfectly and assigned to nobody produces an error for everybody. It is the first thing to check when it works for you and not for the team.

Assign by group

Not individually. Then a new colleague added to the group in Okta has Zendesk access automatically, and somebody removed loses it, which is the point of doing this at all.

Test in a private window

With your ordinary session still open elsewhere. If the configuration is wrong you can still reach the settings and fix it.

Certificates expire

And when one does, nobody can sign in, with no warning beforehand. Note the expiry date somewhere your team will see it, because this is a scheduled outage nobody scheduled.

Then disable Zendesk passwords

Once it works for everybody. Leaving them enabled keeps a second route in that Okta does not control.

See also

• Enabling SAML single sign-on
• Managing your SSO configurations
• My agent cannot sign in: what to check