複数ブランドを使用すると、1つのZendesk Supportインスタンスで自社のすべてのブランドを管理できますが、セキュリティ設定では、リモートログイン用に1つのURLしか設定できません。このため、ブランドごとにユーザーデータベースを構築している場合に問題が生じる可能性があります。
この記事で紹介する方法に従えば、Zendesk SupportとサーバーのSSOログインスクリプトの間にスクリプトを作成することで、カスタマーがログインしようとしているブランドに基づいて特定のURLへルーティングすることができます。
この手順は、サーバーでJWTが既に設定されていることを前提としています。設定していない場合は、まず「JWT(JSON Webトークン)シングルサインオンの有効化」の記事に記載されている指示に従ってJWTを設定してください。
この記事の例ではPHPを使用していますが、必要であれば他のプログラム言語にも適用できます。
この記事では、次のトピックについて説明します。
複数ブランドの設定
この手順を実行するには、少なくとも2つのブランドを設定する必要があります。詳しくは「複数のブランドを設定する方法(ProfessionalアドオンおよびEnterprise)」を参照してください。
ブランドを設定したら、ブランドのURLおよびホストマッピングしたブランドのURLを保存します。これらのURLは後でスクリプトで使用します。
JWTを設定した複数のユーザー認証システム
前述したように、ユーザー認証システムでJWT SSOを設定して構成する必要があります。これまでどおりブランドごとに1つずつ実行できますが、セキュリティオプションから取得する共有シークレットはすべての認証システムで同じでなければならないことに注意してください。
前のセクションの情報といっしょにログインURLおよびログアウトURLを保存します。
スクリプト
保存したURLのリストは次のようになります。
ブランド1
ホストマッピングしていないURL:https://brand1.zendesk.com
ホストマッピングしたURL:https://support1.example.com
ブランド2
ホストマッピングしていないURL:https://brand2.zendesk.com
ホストマッピングしたURL:https://support2.example.com
システム1
ログインURL:https://page1.example.com/zdlogin.php
ログアウトURL:https://page1.example.com/zdlogout.php
システム2
ログインURL:https://page2.example.com/zdlogin.php
ログアウトURL:https://page2.example.com/zdlogout.php
次に、スクリプトを作成します。各ブランドのURLから「https://」の部分を削除します。Webサイトのリンクはそのままにしておきます。
スクリプトは次の場所にもあります。
ログインスクリプト
<?
$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();
}
}
?>
ログアウトスクリプト
<?
$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();
}
}
?>
セキュリティ設定の更新
-
管理センターで、サイドバーの「
アカウント」をクリックし、「セキュリティ」>「シングルサインオン」を選択します。
- 「SSO設定を作成する」をクリックし、「トークン」を選択します。
- 一意の構成名を入力します。
- 「リモートログインURL」に、ログインスクリプトのURLを入力します。
- 「リモートログアウトURL」に、ログアウトスクリプトのURLを入力します。
- 同じメールアドレスで複数のユーザー認証システムにアカウントを持つカスタマーがいる場合、競合を避けるために、「外部IDを更新しますか?」をオンに設定します。
- ITチームに共有シークレットを提供します。チームがJWTを実装する際に必要になります。
- 変更を保存します。
重要な検討事項
- スクリプトをそのまま使用すると、セキュリティリスクは低くなります。ここで説明した変更以外にスクリプトを大幅に変更すると、自社のサーバー(Zendeskではなく)にセキュリティ上の脆弱性が生じる可能性があります。
- JWTトークンは1つしか提供されないため、すべてのSSOスクリプトは各種認証システムで同じトークンを使用します。1つでもシステムが侵害されると、すべてのブランドが侵害される可能性があります。
- SSOを行おうとしたときに「JWTリクエストが無効です」というエラーが出た場合は、後述のトラブルシューティングの説明を参照してください。
トラブルシューティング
無効なJWTリクエストエラーを防ぐには、両方のブランドでhttps://(defaultsubdomain).zendesk.com/を/access/jwt?jwt=
としてハードコーディングしてください。ここで、(defaultsubdomain)はメインブランドのサブドメインです。たとえば、「mydomain.zendesk.com」のように入力します。
- SSOスクリプトに https://(defaultsubdomain).zendesk.comをハードコーディングすると、JWTペイロードは常に https://(defaultsubdomain).zendesk.com/access/jwtに送信されます。
- このスニペットをスクリプトに実装して'return_to'を使用し、エンドユーザーが元のヘルプセンターにリダイレクトされるようにします。両方のブランドマーキングURLのペイロードを'(defaultsubdomain)'として追加し、'return_to'を追加するようにします。
参考までに、スニペットは次のようになります。
if(isset($_GET["return_to"])) {
$location .= "&return_to=" . urlencode($_GET["return_to"]);
}
30件のコメント
Gerald B.
Hi Sarah.
Apologies for the wait regarding your question.
User passwords are not brand restrictive within Zendesk. You would need to implement custom routing based to the brand URL that you created. You can also toggle the SSO setting for end users to "Let them choose" which would give them the option for a Zendesk Login or SSO. You can customize the SSO button's text to signal they users to sign in using the correct method.
https://support.zendesk.com/hc/en-us/articles/5380943678106-Giving-users-different-ways-to-sign-into-Zendesk
I'll set this to Solved for now, but if you have an further questions, please raise a ticket and we will be happy to help troubleshoot for you.
0
Gerald B.
Thank you for contacting the Zendesk Support Advocacy team. My name is Gerald and I'll be assisting you today.
I understand that you want to setup a method to allow agents and admins to reset their passwords by brand. I'm looking into options for you now.
0
Sarah Cullerton
Have this set up but have run into issues with the password reset loop. Brand 1 is SSO redirecting to /access/normal for those attempting to access Brand 2. We're able to get through admin managed password resets through the /password end point but anything going through the /verification endpoint like welcome emails or users resetting their own passwords for Brand 2 gets bounced to SSO. Any advice here so that we aren't relying solely on admins to manage end user credentials for an entire brand?
0
Marco
@ Chris
I think the answer is YES to both questions one and two. The big issue with Zendesk is that you have one single User Registry and one single Authentication status for the whole account. So, if you log into Zendesk via the Brand 2, you are automatically logged in Brand 1 as well. It doesn't matter if you're logged in via SSO or not, you are just authenticated, stop!
The only work-around I see is to restrict access to HelpCenters based on Users/Organizations tags (Users segmentation).
Let's hope to get some better official answer from Zendesk...
0
Chris Fassano
I have some questions regarding this scenario.
1. If a user is created through the SSO option via Brand 1, and then later goes to Brand 2 to log in, would they be presented with the option to reset their Zendesk password?
2. If yes, does that mean they would be able to log into Zendesk via the Brand 2 help center by using their Zendesk credentials rather than their 3rd party SSO credentials?
1
Tony Felicetta
Hello, I have been watching this thread for some time, and through various web searches have been unable to clearly define the steps needed. I am looking for an A-B-C checklist, I have most of it together but then it drops entirely at implementing the JWT login scripts.
For example:
1. Configure Okta SSO JWT authentication within Zendesk (COMPLETE)
2. Configure Multiple Brands within Zendesk (COMPLETE)
3. Configure Multiple Help Centers > 1 or 2 per brand (COMPLETE)
4. FACT - we are using Okta as the SSO solution passing the JWT to Zendesk (confirmed working) -- NEEDED is dependent upon the users email domain (@domain111.com, @domain222.com) this would direct the user to the necessary Help Center
5. QUESTION - where should the proposed login scripts reside, Zendesk or Okta or? This step is very vague and does not seem to describe "how" the JWT identifies the logged in user to direct them to the appropriate help center. For example, a user with email @domain111.com would be directed to support-domain111.zendesk.com , similarly if the user email domain is @domain222.com then they would be directed to support-domain222.zendesk.com .
0
Joyce
I can see that you open a messaging request for this concern and were advised to create Product Feedback for your use case.
0
Jason Wong
When setting up a JWT for end users to login vs. agents with SSO. the login page is missing the forgot password link. Any way to add that back? Our customers are unable to request a password reset.
0
Julio H
Currently, you can allow the end user to choose among several SSO options (Google, Microsoft, custom SSO...) or Zendesk default authentication (username and password).
For more information, please visit: Providing multiple sign-in options for team members and end users.
Unfortunately, there is not a simple way to achieve this. However, this could be possible to achieve, but using JWT and your own custom authentication. They customer A and B must login to your custom authentication system, and then via JWT, allow them to access Zendesk.
Or redirect all the login request to the SSO landing page, where you can have an option for them to select their type of account and show the login option for that type of account.
If you're this link: subdomain.zendesk.com/access/normal you will be able to only allow the user to login with username and password.
In any case, currently, this is not possible within Zendesk settings.
I've marked this conversation as product feedback for review, which means that your input will be aggregated as a part of our Voice of the Customer program that provides customer feedback to our product development teams.
In addition, I encourage you to create a new post in the General Product Feedback topic in our community to engage with other users who have similar needs and discuss possible workarounds. Conversations with a high level of engagement ultimately get flagged for product managers to review when they go through roadmap planning.
Specific examples, details about impact, and how you currently handle things are helpful for our product teams to understand the full scope of the need when working on solutions. You may also want to review the Product feedback guidelines and how to write an effective feedback post [https://support.zendesk.com/hc/en-us/articles/4413820079386-Giving-Product-Feedback-at-Zendesk-].
We truly value customer feedback and your voice and votes in the forums help influence future Zendesk functionality.
Greetings.
0
Naoki Tanaka
ご質問の投稿ありがとうございます。
該当の件ですが、特に推奨はございませんので利用者がアクセスできるサーバーに当該のスクリプトが動作するページを作成いただければと思います。
ご確認よろしくお願いいたします。
0
サインインしてコメントを残してください。