Multibrand allows you to control all your company brands in a single Zendesk Support instance. However, security settings will only allow you to set up one single URL for remote logins, which might be problematic if you have different user databases for each of your brands.
Fear no more! This approach will allow you to create an easy script between Zendesk Support and the SSO login script in your server that will allow you to route your customers to specific URLs based on which brand they are trying to log into.
This tip assumes that you have already configured JWT on your server. Otherwise, make sure that you follow the instructions listed on the article Setting up single sign-on with JWT (JSON Web Token) first.
I'm using php in this example, but you can adapt it to other languages if you need to.
This article contains the following sections:
- Two or more brands or more set up
- Two or more user authentication systems with JWT configured
- The scripts
- Update security settings
Two or more brands set up
In order for this tip to make sense, you will need at least two brands configured. You can create them on Admin > Manage > Brands . For details, see Setting up multiple brands (Enterprise) .
After you set it up, save the brand URL and the host mapped brand URL. We will use them in our script later.
Two or more user authentication systems set up with JWT SSO
As mentioned previously, you will need to have set up and configured JWT SSO on your user authentication systems. You can do one for each brand already, but bear in mind that the shared secret that you obtain from security options will have to be the same in all your authentication systems.
Save the login URL and logout URL along with the information from the previous section.
The scripts
Now the fun part begins! Your list of saved URLs might look like this:
Brand 1
Non-Hostmapped URL: https://brand1.zendesk.com
Hostmapped URL: https://support1.example.com
Brand 2
Non-Hostmapped URL: https://brand2.zendesk.com
Hostmapped URL: https://support2.example.com
System 1
Login URL: https://page1.example.com/zdlogin.php
Logout URL: https://page1.example.com/zdlogout.php
System 2
Login URL: https://page2.example.com/zdlogin.php
Logout URL: https://page2.example.com/zdlogout.php
Now, let's create the script. Remove the https:// from the URL for each brand url. Keep them on the website links.
Login Script
<? $brand_URLs = array( "brand1.zendesk.com" => "https://page1.example.com/yourcustomloginjwtscript.php", "support1.example.com" => "https://page1.example.com/yourcustomloginjwtscript.php", "brand2.zendesk.com" => "https://page2.example.com/yourcustomloginjwtscript2.php", "support2.example.com" => "https://page2.example.com/yourcustomloginjwtscript2.php" ); foreach($brand_URLs as $k => $v){ if(strpos($_GET['return_to'],$k)){ header("Location: ". $v); die(); } } ?>
Logout Script
<? $brand_URLs = array( "brand1.zendesk.com" => "https://page1.example.com/yourcustomlogoutjwtscript.php", "support1.example.com" => "https://page1.example.com/yourcustomlogoutjwtscript.php", "brand2.zendesk.com" => "https://page2.example.com/yourcustomlogoutjwtscript.php", "support2.example.com" => "https://page2.example.com/yourcustomlogoutjwtscript.php" ); foreach($brand_URLs as $k => $v){ if(strpos($_GET['return_to'],$k)){ header("Location: ". $v); die(); } } ?>
Update security settings
- In any product, click the Zendesk Products icon (
) in the top bar, then select Admin Center.
- Click the Security icon (
) in the left sidebar, then click the Single sign-on tab.
- For JSON Web Token, click Enabled, then point to the scripts we created. See example below.
- Save your changes.
- Remote login URL - This has to be the URL to the Login Script.
- Remote logout - This has to be the URL to the Logout Script.
- Update of external IDs? - In case that some of your customers have an account in more than one user authentication system with the same email address, to avoid any conflicts when logging in, you must select “On” in this option.
Now your agents or customers will be able to authenticate using their specific authentication system, depending on which brand they are trying to access.
You can also find the scripts here:
Note 1: Security risk is low if you use the script as it is. If you modify it extensively other than the changes mentioned here, you may create a security vulnerability on your own server (not Zendesk’s).
Note 2: Since we only provide 1 JWT Token, all your SSO Scripts will use the same tokens in your authentication systems. If one of your systems is compromised, it may lead to all of your brands being compromised.
26 Comments
Thanks, this is definitely a useful feature for those of us using MultiBrand with tenanted clients with different implementations of SSO.
This is exactly what I need, but I'm struggling following a little bit here. You have two systems listed with login script URL's. Which do you put inside the Zendesk settings? Do you host a login and logout script at each domain, then just one set inside Zendesk?
In your example (below) which information would go inside Zendesk? I am using Wordpress too for both sites if that has any effect. Thanks!
System 1
Login URL: https://page1.example.com/zdlogin.php
Logout URL: https://page1.example.com/zdlogout.php
System 2
Login URL: https://page2.example.com/zdlogin.php
Logout URL: https://page2.example.com/zdlogout.php
Hi Kevin,
The premise here is that you create a new login script and a new logout script that essentially "funnels" both of your existing login/logout scripts into one. You can download Abel's example scripts using the links in the article, and you would replace the links to reflect your Wordpress login script locations. It would probably look something like this:
This may be slightly different depending on your Wordpress setup. Save this new script and host that somewhere on your site, then reference the new script in your Zendesk security settings.
I will reach out to you in a ticket to make sure you have all the info you need.
Does Zendesk plan to allow using of different SSO settings for brands?
Hi Dmitry-
At this time, our multi brand feature should be thought of as "ticket management" as opposed to "user management" in other words brands follow tickets, not users. We do however realize this is a major limitation and are actively working to make multibrand better equipped for user management, including users by brand and SSO by brand for user authentication.
There is more on this here, where SSO per brand is limited as a limitation we are planning to address: Multibranding - Known Limitations
Hi all, we ran into a problem which prevent us from using multibrand feature of Zendesk together with SSO at all. If anyone knows a way out please share your experience. Assuming a user has two different registrations on two Brand sites and tickets in two Brands too. E.g. he uses q@q.q in Brand#1 and k@k.k in Brand#2. What will happen with his tickets if he changes his k@k.k e-mail in Brand#2 to q@q.q? Ok, in this case user merge feature of Zendesk seems a logical step. But if after that he changes his e-mail in Brand#2 back to q@q.q how to deal with it? As far as I can see separating tickets is not possible between two authors, because Zendesk don't have an API to change the author of replies/comments.
Hi Petr - All of your users for all of your brands are managed in the same place and are not associated to a particular brand. You might be interested in some other known issues/limitations with multi-brand which can be found here:
https://support.zendesk.com/hc/en-us/articles/206339578
So to address your particular questions:
What will happen with his tickets if he changes his k@k.k e-mail in Brand#2 to q@q.q?
I'm assuming you mean changing his email address within Zendesk (and not your external auth system.) He will not be allowed to do so, as user q@q.q already exists and no two users can have the same email address. Similarly, user q@q.q will not be able to change their email address to k@k.k.
Ok, in this case user merge feature of Zendesk seems a logical step.
I would be cautious of this. When you merge k@k.k into q@q.q, k@k.k is added as a secondary email address to user q@q.q. A secondary email address will make sure that tickets sent via email from both email addresses are attributed to the same user, but secondary email addresses cannot be used for authentication, so the user will no longer be able to use k@k.k to login.
The simplest way to address this would be to ensure that one user is using one email address to login. The only other way to get this to work would be to ensure that both external authentication systems have the same external ID for both user profiles. If k@k.k and q@q.q both log in using the same external ID, they will both be logged into the same user profile, and each time they log in their info will be overwritten with whichever email address they used to log in. There are limitations to this approach as well, so if you need more details or need any more help with this, I would recommend submitting a ticket to support@zendesk.com.
Thanks!
Is this possible to set up with different systems using the same brand?
Say if page1.example.com and page2.example.com both use brand1.zendesk.com and page3.example.com and page4.example.com both use brand2.zendesk.com. Is this something that can be achieved?
Hi Conor - theoretically this should work fine.
This isn't clear in the documentation, but if you are logging out of Zendesk via the /access/logout URL you will need to pass the return_to parameter yourself in order to work with this script.
e.g.
1. User is in support1.example.com and clicks logout
2. Redirect user to brand1.zendesk.com/access/logout?return_to=http://support1.example.com
3. Zendesk logs the user out and redirects to auth.example.com/zdlogout.php?&brand_id=1234&return_to=http://support1.example.com
If you don't add return_to in step 2, you won't get it in step 3 and the script provided about will probably show a blank screen.
Note: If the user clicks logout from inside Zendesk, it will send this parameter for you, this is only required if you are redirecting your logouts through Zendesk.
Thanks for sharing this, Andrew!
Hi there,
Will you also be implementing multibranding into SAML, to make it possible to use a different IDP for the different brands? If so, do you have an expected release date?
We're an IDP and currently provide a whitelabeled product, for which we also provide support, so SAML is currently not an option, as we cannot have the whitelabled customers logging in via an IDP with our own branding and vice versa.
We currently do not support JWT, and with the mentioned security risks in this article, as well as in the JWT implementation article (info is encoded and not encrypted), we would not be able to implement JWT as a solution.
Another question is if you are going to implement any other SSO methods, such as oAuth2?
Hello Mike - We do plan on supporting multibrand SSO in the future, but there is no ETA that I can give you. You can comment in this product feedback thread to contribute your thoughts on this:
https://support.zendesk.com/hc/en-us/community/posts/203403437-Multi-Brand-Feature-Requests
Hi there,
I am finding difficulty to SSO for my branding page.
I have 2 brand. Ex a.zendesk.com & b.zendesk.com
In my account -> branding -> subdomain by default a is selected.
I can SSO to a.zendesk.com but for b.zendesk.com I am getting error like
Invalid JWT Request
JWT requests must be sent to https://a.zendesk.com/access/jwt
any though will be helpful.
Thanks
Hi Sam - my colleagues have checked this together with you in the ticket #2944754 and everything is working as intended now. Thank you for sharing your specific workflow!
Hi there - I've noticed a problem with the multibrand SSO script. I am using the script above, with no changes, except for URLs. The SSO signin for Brand A works 100%, on all browsers and OS versions we've tested. However, for Brand B, the login redirect does not work correctly on Safari for Mac. Instead of being signed into and returned to Brand B's HC, the user is sent to Brand A's HC and logged in there. I wondered if this was the specific build of Safari that was being used (12604.1.38.1.7), so I tested the login process on a MB Air I have here for testing, that's running macOS 10.13 and a new build of Safari (13604.1.38.1.6), and the same problem occurs. If the problem isn't fixed going forward, then it could be something else.
This incorrect redirect is causing customers to "lose" their tickets, and they simply cannot get logged into the Brand B Help Center, where their Brand B tickets are located. This is pretty crazy! I'm investigating a solution to target just Safari browsers, and that login button, to ask them to switch browsers.
Here's a thread from our forum that shows the problem some people are having: http://discuss.topazlabs.com/t/tickets-not-listed/1865/16
I've remoted into one of these individuals' machine, and it failed for him. He didn't have other browsers installed, and I think it's pretty lame to have to ask someone to install another piece of software just to access our support.
Should I just create a ticket? Anyone else seeing this? The script is good, other browsers are good, Brand A is good. What's bad here?
Hey Joe! I'm so sorry for the delayed response on this!
I see that you did go ahead and create a ticket, and Dylan on our Tier 2 Support team was able to help you get this issue figured out. Let us know if you need anything else!
Hi, I have exact same problem as:
https://support.zendesk.com/hc/en-us/articles/206354108/comments/115001927548
Is there anything I have to do to resolve it?
Hello Support,
I was able to find the ticket where the issue was resolved and am putting that information here for visibility in case others have this issue:
"What you'd ultimately need to do is hardcode https://(defaultsubdomain).zendesk.com/ as
/access/jwt?jwt=
for both brands.1. Hardcode https://(defaultsubdomain).zendesk.com into the script, so the JWT payload always gets sent to https://d(efaultsubdomain).zendesk.com/access/jwt
2. Implement that snippet into the script to use `return_to` so the end-user will be redirected back to the origin Help Center and make sure to append payload for both brand marking URL as fix as '(defaultsubdomain)' and append 'return_to'.
The snippet for your reference:
Thanks, Patrick. This helped me resolve the issue.
Support, please update your script.
Hello,
Say we have two completely separate Zendesk sites and both of them use JWT sso for end users. Could we use this if we merged the other Zendesk site into our main page? We would want to do this to leave both of them on their own sso in order to prevent disruption for end users. Until we saw this we pretty much gave up on the idea.
Thanks..
Hi Ed,
Thanks for contacting Zendesk.
This could potentially work in your company's situation. You'd have to make sure you have the Multibrand option on your Account A, and then create a new brand on Account A for Company B. You'll then need to export the data from your Account B and import into Account A.
Never give up, never surrender.
Would it be possible to have one brand using SSO and the other not?
I was imagining that somehow we might be able to re-direct logins for the non-SSO brand to https://brand.zendesk.com/access/normal and logouts to the equivalent for logging out.
Hello Lisa,
So, unfortunately, as our current setting options stand this would not be possible. However, I think there might be a custom workaround that might be possible to facilitate this. I've gone ahead and converted your request into a ticket so one of our advocates can walk you through this process.
Let me know if you have any other questions regarding this or anything other issues you may run into.
It should be known to future customers that at this moment this is still impossible to have SSO for some brands and normal signup for another brand.
If we had known about this prior to our migration, we would not be stuck in an impossible situation that could be fixed in two lines of code by Zendesk (they already have everything in place except Email verification that redirect to your SSO flow instead of redirecting to a page where users can verify their email)
Only thing you can do is to create your own signin/signup page and integrate the Zendesk API for creating users yourself. So at least 2/3 days of work.
Really disappointed by Zendesk right now.
Hi Mathias,
I totally understand your frustration here and I appreciate you taking the time to share this with us. I'll be sure to pass this feedback along to the appropriate product managers so they're aware of these roadblocks you're running into.
Thanks again!
Please sign in to leave a comment.