You can have up to two active SAML and two active JSON Web Token (JWT) SSO configurations, which can be assigned to different collections of users. Each will have their own remote login pages.
The following Admin Center page shows two primary SAML configurations—one for end users and one for team members.
About redirecting users to remote login pages
Zendesk redirects unauthenticated users when they click the Sign in link in Help Center or navigate directly to the sign-in page in Zendesk.
If you have more than one authentication method configured for your users, you can assign separate primary SSO methods for end users and team members. Zendesk attempts to anticipate whether an unauthenticated user is an end user or team member and routes them to the appropriate remote login page.
For the best customer experience, you should set the primary SSO method for end users to be the one used by the majority of your end users to ensure they get the benefit of the redirect. The users that use the other remote login pages must navigate to them on their own. Make sure to provide them with the correct URL. Another solution is asking your web team to add links on the redirect login page that the other users can use to access their login pages.
Example set up
- JWT-VIP: Assigned to VIP end users
- SAML-EndUsers: Assigned to all other end users
- JWT-TeamMembers: Assigned to all team members
On the Team member authentication page, you've only assigned the JWT-TeamMembers SSO method to team members. Therefore, you don't need to select a primary SSO method for team members to use. All team members will be redirected to the remote login page for this SSO method, which is your corporate employee login page.
Then you set SAML-EndUsers as the primary SSO method on the End user authentication page because that's what the majority of your end users will use. The remote login page for this SSO method is your company's default customer login page. Your VIP end users will also be redirected to this page even though they're configured to use the JWT-VIP SSO method. Since these are your most important customers, you need to ensure they can easily sign in, too. You can provide them with the correct URL for the remote login page they should use or have your web team add a link directing them to the VIP login page.
12 Comments
We're having similar problems setting this up as the the advice listed here doesn't seem to work for us either.
It seems that whatever method is set as primary takes precedent, even if you try and navigate to the login url that isn't the primary, it still redirects you to whichever happens to set as primary at the time. Is this actually working for anyone?
Hey @...,
We have a case where we're using JWT for customers and SAML for agent. What we're expecting is, when we register a new end-user, the user gets a verification link. when this verification url is accessed, It does not take the user to be verified, but asks the user to login to my SAML configured SSO page. (Also, my SAML is the primary SSO ) .
How do I avoid this get my user to verify normally and create a new password to access zendesk?
Hi Milton,
I will create a ticket from your comment so that our team can take a closer look at your issue.
Hi Raghav,
When a user is added to a Zendesk account, an automatic email notification will be sent to the user. Because they're authenticated with a non-Zendesk password, the profile is created without a password because they don't need to sign in to Zendesk. Since you've set up external authentication and the users don't use Zendesk credentials to sign in, to avoid any confusion, we recommend to:
- In the Account emails section, deselect Also send a welcome e-mail when a new user is created by an agent or admin
- In Allow users to change their passwords, deselect this option.
Its been half a year since this was updated, so what is the URL to get a valid saml SAMLRequest token when JWT is primary?
Hey Ymeiner,
If I understand your question correctly the URL is your remote SAML server which we pass the user over to. They then login and your SAML server responds back to us with the token.
If this isn't the URL, you're referring to let me know.
Thanks!
Eric
Hi eric, yes i understand that but if saml is not the primary login method - this forward to the iDP will not be created. what is missing is a zendesk link that is allowing us to chose the login method.I don't know any way that MS/AZURE saml can provide a login with relaystate without the valid SAMLRequest in the address.
Yaron
btw, the issue that i am facing is basically described here: https://social.msdn.microsoft.com/Forums/en-US/e6f5d9ee-9ca5-4027-971d-b89735fe2a85/does-azure-support-dynamic-relaystate?forum=WindowsAzureAD
in order to do relaystate correctly we need the request to include the ID and IssueInstant from Zendesk. this is something that no IT person can give us. You are the SP, you are responsible of creating a method for deep linking over specific login method.
Hey Yaron,
Thanks for the clarification. The forward should be created when your agents click the "I am an agent" option at sign in. This will then pass the request to your SAML provider with all necessary parameters. If this isn't happening, feel free to open up a ticket with us and I'd be happy to look over your configuration.
Eric, we have a ticket open alreay, feel free to DM me (ymeiner everywhere) and we can discuss.
Hi,
Is there any update or solution on this issue?
We are experiencing the same issue. JWT is our primary SSO for customers, and SAML is for agents.
Thanks.
we have similar issue. JWT SSO setup as primary, AWS SSO configured as SAML provider for SAML SSO. If our team responsible to add "I am an agent link to the customer login page" where I can find instructions?
Thanks
If JWT SSO is your primary, then Zendesk only knows to redirect all users to the JWT Sign-In URL. This is, naturally, not a Zendesk page, so Zendesk's infrastructure has no control over redirects after this point. Our recommendation is that your web developers add a hyperlink, labelled something to the effect of "I am an Agent," to the JWT Page, which redirects to the SAML Sign-In Page. This will allow your agents to access their sign-in page, while still directing your users to their sign-in page by default.
We don't include instructions for this process, as how the hyperlink is created depends on your JWT Sign-In Page, and how you obtain the SAML Sign-In URL depends on your SAML provider. Thus, any instructions would be personal to your own use-case, and outside of our ability to support.
Please sign in to leave a comment.