| Announced on | Rollout starts | Rollout ends |
|---|---|---|
|
July 29, 2022 |
July 27, 2022 |
Aug 3, 2022 |
Zendesk is excited to announce a new SSO feature that lets you set up separate SAML or JWT configurations for team members and end users. This feature provides an out-of-the-box solution for customers who want to authenticate all types of users, including team members and end users, using SSO but want to persist user data on separate Identity Providers (IDPs) based on user type. With this solution, you can create two separate SSO configurations, one for your team members and one for your end users.
Why did we build it?
In the past, Zendesk only allowed one SAML or JWT configuration for both types of users. However, many customers have different IDPs set up for different user roles. As a result, some customers had to make compromises with their SSO setup and give up using SSO authentication for end users because we only supported one SAML setup per Zendesk instance. But now we allow customers to create separate SAML or JWT configurations for the each user type. Users’ data can reside in their respective IDPs and still allow any type of user to sign in to Zendesk using SSO.
How does it work?
You can now create SSO configurations and provide a unique name for each one. Examples: “Okta-SAML-Team_Members” or “Google-JWT-End_Users”. Once you’ve created those configurations, you can go to Security > End Users and select the SSO configuration through which you want your end users to be authenticated. You can do the same for team members. Go to Security > Team members and select the SSO configuration. If you have only one SAML or only one JWT configuration for all types of users, just perform the same steps and select the singular configuration option.
Tell me more
See the following articles for more information:
- Using different SAML and JWT SSO (single sign-on) configurations
- Managing single sign-on (SSO) configurations
- Single sign-on (SSO) options in Zendesk
Limitation
We make the distinction to redirect users to their respective IDP based on the URLs through which they access the Zendesk instance. So we recommend that team members and end users use their respective URLs to be redirected to their respective IDP for SSO authentication.
6 Comments
Barkha Bhatia:
This is really a great feature and we thank you very much for the implementation!
However, in order to be able to use this enhancement comprehensively, we would not only need the distinction between "Team member" and "End user", but also per brand for the End user.
Example:
Use case:
For End user, which we serve via several Zendesk brands, we currently use the Zendesk integrated authentication and cannot change this in the near future.
Beside End user we serve with one Zendesk brand of our Zendesk instance a Partner Portal.
We would like to migrate this brand to Azure AD B2C as external authentication as soon as possible so that we can give partners access to the relevant documents located on our Microsoft Sharepoint such as recorded webinars, slidedecks, sales kits, product training, beta software downloads without having to create and maintain their own logins, and to offer seamless integration in terms of good usability.
Due to the volume as well as primarily the file size, we cannot attach these documents directly to Zendesk Guide articles and Zendesk Gather posts.
Are there any plans for such an enhancement or should I submit a feature request?
If you have any questions, please feel free to contact me at any time.
Hey Team,
I agree with Josef here. I have customers who are looking to be able to do SSO per brand, or no SSO. I can submit a second use case here on where this would come into play.
The customer has 2 brands:
Brand A: End-user auth via SSO
- This brand requires customers to log in as they are paid customers who pay for a service with the company.
Brand B: No Auth - open to the public
- The brand is to be used as a sales portal where sales forms and information can be surfaced to customers who have not yet signed up for the service. No login is required as there is no sensitive information on this HC, all public-facing content.
Hi Josef Prandstetter Amie Brennan
First off, thanks a ton for your kind words and the feedback you shared with us. We love your engagement through community and other channels.
The good news is that the use cases you have described here are on our roadmap. Below is a sneak preview of how we want to progress.
- First, we want to allow Zendesk admins to set up Authentication such that a single brand customer's users can log in using any authentication method out of Native Auth ( username/password based), SSO, and Social Sign. Zendesk admin will be able to choose which method they want to allow for the respective users (agents/end users) depending on their architectural and security posture requirements.
- After that we want to enable the same level of flexibility and granularity for multi SSO - multi-brand - multi authentication customers' use cases.
Barkha Bhatia
Thanks for the information - that sounds amazing - can you give a very, very rough timeline for implementation?
This feature is great. I would love also to like to see options for Help Center/Brand specific SSO configurations. My team has expanded our Zendesk instance to non support teams whose user base expands further than my orgs user base(~6000). Our IT does not support our full global user base (~200K) however this team's requirement is that global end users should be able to submit tickets to their Branded Help Center. Currently we have no way to restrict access to our Help Center so we are forced to manage access individually.
Hi Kekoa Mooney Thanks a lot for the feedback, I will email you and setup some time with you to go a little deeper into this.
Please sign in to leave a comment.