Zendesk offers the ability to set separate authentication policies for agents vs end-users. This helps you secure your Zendesk by allowing you to create a more strict authentication policy for agents while still providing easy access to your customers and end-users.
With this functionality, you can...
- Set different password policies for agents vs end-users.
- Set different authentication methods for agents vs end-users (e.g. Google sign-in for agents, Zendesk sign-in for end-users)
- Restrict your agents to sign in with only one authentication method that you choose: username + password, Google, or SSO (SAML or JWT).
You will only be able to select a single authentication mechanism for agents. If you select SSO with IP restrictions, your agents will be allowed to sign in with Zendesk credentials outside of the IP range. - Enable SSO for only agents, or only end-users, or both.
You will not be able to select different SSO configurations for end-users vs. agents if you select SSO for both.
You can set up both JWT and SAML, designating the primary SSO mechanism for Zendesk redirection
Security settings that pertain to all users, such as IP restrictions and SSL, can be found in the Security (
) section of Admin Center.
Sign-in page
If SSO is enabled only for end-users, they are taken directly to the SSO sign-in page. Agents have to navigate to the /access/normal URL to sign in using their Zendesk account credentials.
If SSO is enabled for agents and not end-users, a link called "I am an Agent" is displayed on the sign-in page. Clicking this link takes the agent directly to the SSO sign-in page.
9 Comments
We have both SSO enabled for agents and customers. We want to use SAML for our agents and JWT for our customers. If we setup JWT to be the default mechanism, our Azure AD SAML integration is no longer working. When we setup JWT as default, logout url is no longer working for JWT. What should be the proper configuration?
Thanks,
Hey Jonathan!
Great question, the trick is to enable both, make the one you want to use for end-users the primary one using the SSO switch that appears when you enable both SAML and JWT, and finally you create a button in your Help Center called "Sign in for agents" that will point to the Login URL for agents :)
Hi,
I do not get the following:
We use ADFS, does this mean that I can only have one Relying party definition and that I have to send the role admin/agent/user via ADFS. So all values on both SSO (admin+agent, end user) settings under security have to be the same?
Best
Martin
Hi Martin,
You can set up SSO with ADFS (see this article if you haven't already) for both agents and end-users, and you can even map custom roles (more on that here.) You don't need to set up multiple relying party trust identifiers, you just need to be able to tell Zendesk which people are agents, either by sending that from ADFS when they log in or having a Zendesk admin set that manually in the agent interface. If you don't want to map roles from ADFS to Zendesk, users who sign in who don't exist yet in Zendesk will be marked end-users. The Zendesk security settings will be the same in this case for both agents and end-users.
Hopefully I understood your question correctly. You can always send a ticket to support@zendesk.com if you need to talk more about your specific use-case.
Thanks!
Hi, yes that totally explains it. Thanks for the clarification.
We have agents login via Microsoft Office 365, via the I am an Agent link on the regular login. We want to enable SSO/JWT for end users, but when we turn this on, we no longer have access to the I am an Agent link. Is there a direct link to login as an Agent via Office 365 that redirects to the agent's dashboard? As of now we are planning on keeping the Zendesk Auth as a back up to SSO but the backup page https://<ourdomain>.zendesk.com/access/normal, doesn't have the "I am an Agent" link either.
Hey David,
Your agents should be able to navigate to subdomain.zendesk.com/agent to navigate to the Support login page for agents.
Are you experiencing anything different on your end?
Brett,
That did the trick. I must have missed that link in the documentation and the one on the login page before implementing SSO was a direct link to MS.
Thanks,
David
Happy to help David :)
Please sign in to leave a comment.