タグ「シングルサインオン」の検索結果が23件

タグ：シングルサインオンタグ条件を解除

【不具合対応】Keeper Automatorの動作不調に関するお詫び（2026年09月04日以降）
Keeper / 重要な変更・障害のお知らせ
gonohe　2026年9月29日 06:07 更新
第4報（2026年9月28日 14時）これまで本ページにてお知らせしておりました Keeper Automator Hosting の動作不調につきまして、2026年9月17日以降、安定してい動いていることを確認しています。一方で、Keeper 社による Automator のリリース作業の際に、一時的に動作が不安定となる事象がたびたび確認されております。そのため、引き続き稼働状況の監視を行ってまいります。万が一、再び自動承認が行われない事象が発生した場合は、速やかに復旧対応を実施するとともに、本ページにてお知らせいたします。お客様には長期間にわたりご迷惑とご不便をおかけしておりますことを、重ねてお詫び申し上げます。第3報 (2026年9月8日 10時)9月8日 7:37 以降、再びデバイスの承認が行われない状態となっております。復旧作業を随時実施するとともに、メーカーと恒久策について相談を進めております。お知らせできる新たな事項がございましたら、本ページにてお知らせいたします。引き続き、ご迷惑をお掛けしておりますことを重ねてお詫びいたします。第2報 (2026年9月7日 15時)下記にてお知らせしておりました Keeper Automator の不具合についてですが、9月6日〜7日の午前中にかけて再び不安定な状況となっていることを確認しました。メーカーの指示に従って Automator サービスの調整作業を行い、9月7日 12:05 以降は問題が沈静化している状況です。障害の原因究明とサービスの安定稼働に向けて引き続き取り組みを行っております。お知らせできる新たな事項がございましたら、本ページにてお知らせいたします。引き続き、ご迷惑をお掛けしておりますことを重ねてお詫びいたします。第1報 (2026年9月4日 18時)平素は格別のご高配を賜り、厚く御礼申し上げます。弊社が提供しております Keeper Automator Hosting におきまして、一時的に自動承認が正常に行われない事象が発生しておりました。弊社での観測では、US リージョンでは 15:54、JP リージョンでは 16:13 より停止を確認しております。現在は復旧作業を実施し、17:45 に復旧が完了いたしました。引き続き、エラーが発生していないか確認を進めております。お客様には多大なるご迷惑をおかけしたことを、深くお詫び申し上げます。発生事象の詳細対象サービスKeeper Automator Hosting発生日時弊社での観測となります。詳細は開発元に確認中です。USテナント：2026年09月04日 15:54 から17:45までJPテナント：2026年09月04日 16:13 から17:45まで事象本来、Keeper Automator により自動で実施されるべき新しいデバイス・ブラウザでのログイン承認が、管理者による手動承認を求められることがありました。現時点の対応本事象は既に解決しております。現在、原因について開発元に確認しております。
GMOトラスト・ログイン SSO
ZUNDA ID / ログイン・認証連携
飯塚亮騎　2026年7月28日 03:20 更新
ZUNDA IDの「ログイン方法設定」画面を開き、「SAMLプロバイダーを追加」ボタンをクリックしてください。表示されたダイアログに、このプロバイダーを識別するための任意の表示名（例：GMO）を入力します。ここで付けた名前は、ログイン画面や設定画面で表示されます。「作成」をクリックしてプロバイダー詳細画面へ進んでください。プロバイダー詳細画面は閉じず、開いたままにします。GMO トラスト・ログインの「アプリ登録」から、ZUNDA IDを登録します。ZUNDA IDを選択します。メタデータをダウンロードします。ダウンロードが完了したら、「登録」をクリックして作成ウィザードを終了します。作成したアプリをクリックして、作成したアプリの詳細設定を開きます。「メンバー追加」より現在操作中のユーザーアカウントをメンバーとして割り当てます。後で行うログインテストのために、現在操作中のユーザーアカウントがメンバーとして割り当てられている必要があります。テストに成功したら、メンバーを変更することができます。メンバーが割り当てられていることを確認します。ZUNDA IDのプロバイダー詳細画面に戻り、「メタデータXMLをインポート」ボタンをクリックして、先ほどダウンロードしたIdPメタデータXMLをインポートしてください。メタデータをインポートすることで、ZUNDA IDがGMOトラスト・ログインからのレスポンスを検証するために必要なSSO URL・エンティティID・IdP証明書などが一括で設定されます。表示されたダイアログで「ファイルから読み込む」をクリックし、先ほど保存したIdPメタデータXMLファイルを選択します。ファイルが読み込まれたことを確認し、「メタデータXMLをインポート」ボタンをクリックしてください。ファイルが不正な場合はエラーが表示されますので、その場合は再度GMOトラスト・ログインからIdPメタデータをダウンロードし、やり直してください。IdP Entity ID、SSO URL、IdP証明書などの項目がすべてインポートされていることを確認してください。これでZUNDA ID側のSAMLプロバイダー設定は完了です。テストボタンをクリックすると、GMOトラスト・ログインのログイン画面が開きます。ポップアップがブロックされている場合は、ブラウザのポップアップブロッカーを一時的に無効化してください。もしエラーが表示されたり、チェック項目が赤いマークになっている場合は、以下を確認してください。IdPメタデータXMLが正しくインポートされているかGMOトラスト・ログインの属性マッピング（First Name / Last Name）が正しく設定されているかGMOトラスト・ログインのサービスプロバイダー詳細（ACSのURL、エンティティID）が正しいかGMOトラスト・ログイン内でユーザーアカウントがアプリのメンバーとして正しく追加(権限が付与)されているかテストが成功したら、プロバイダー詳細画面に戻り、「状態」をONに切り替えることで、SAMLログインが有効になります。その後、ドメイン設定でこのプロバイダーをログイン方法として選択することで、実際のユーザーがSAML認証でログインできるようになります。
HENNGE SSO
ZUNDA ID / ログイン・認証連携
飯塚亮騎　2026年8月13日 02:12 更新
ZUNDA IDの「ログイン方法設定」画面を開き、「SAMLプロバイダーを追加」ボタンをクリックしてください。表示されたダイアログに、このプロバイダーを識別するための任意の表示名（例：HENNGE）を入力します。ここで付けた名前は、ログイン画面や設定画面で表示されます。「作成」をクリックしてプロバイダー詳細画面へ進んでください。プロバイダー詳細画面で、「メタデータURL(SP)」をダウンロードします。この画面は再び使用するので、開いたままにしてください。HENNGE One 管理画面の操作に移ります。「サービスプロバイダー設定」からサービスプロバイダーの追加を行います。「サービスプロバイダーの追加」をクリックします。「SAML(メタデータをアップロード)」を選択し、画面の指示に従って、ZUNDA ID よりダウンロードしたメタデータをアップロードしてください。メタデータをインポートすることで、HENNGE OneがZUNDA IDとの連携に必要なACS URL・SP Issureなどが一括で設定されます。任意のサービス名（例：ZUNDA ID）を入力します。ここで付けた名前は、ログイン画面や設定画面で表示されます。ここで、Name IDが「Email 属性」であることを確認してください。「保存」をクリックしてサービスプロバイダーを作成します。作成したサービスプロバイダーの表示名をクリックして、サービスプロバイダーの詳細設定を開いてください。メタデータメニューを開きます。「IdPメタデータ」をダウンロードします。ZUNDA IDのプロバイダー詳細画面に戻り、「メタデータXMLをインポート」ボタンをクリックして、先ほどダウンロードしたIdPメタデータXMLをインポートしてください。メタデータをインポートすることで、ZUNDA IDがHENNGE Oneからのレスポンスを検証するために必要なSSO URL・エンティティID・IdP証明書などが一括で設定されます。表示されたダイアログで「ファイルから読み込む」をクリックし、先ほど保存したIdPメタデータXMLファイルを選択します。ファイルが読み込まれたことを確認し、「メタデータXMLをインポート」ボタンをクリックしてください。ファイルが不正な場合はエラーが表示されますので、その場合は再度メタデータをダウンロードし、やり直してください。IdP Entity ID、SSO URL、IdP証明書などの項目がすべてインポートされていることを確認してください。これでZUNDA ID側のSAMLプロバイダー設定は完了です。次のステップで、実際にログインテストを行い、設定が正しく動作するか確認します。テストボタンをクリックすると、HENNGE Oneのログイン画面が開きます。ポップアップがブロックされている場合は、ブラウザのポップアッブロッカーを一時的に無効化してください。もしエラーが表示されたり、チェック項目が赤いマークになっている場合は、以下を確認してください。IdPメタデータXMLが正しくインポートされているかHENNGE Oneの属性マッピング（First Name / Last Name）が正しく設定されているかHENNGE Oneのサービスプロバイダー詳細（ACSのURL、エンティティID）が正しいかテストが成功したら、プロバイダー詳細画面に戻り、「状態」をONに切り替えることで、SAMLログインが有効になります。その後、ドメイン設定でこのプロバイダーをログイン方法として選択することで、実際のユーザーがSAML認証でログインできるようになります。
SAML認証ヘルプドキュメント
ZUNDA ID / ログイン・認証連携
daichi　2026年9月26日 12:48 更新
SAML認証についてSAML（Security Assertion Markup Language）は、異なるシステム間でユーザーの認証情報を安全にやり取りするための業界標準規格です。ZUNDA IDでは、ビルトインのログイン方式（Google認証、Microsoft認証、メール認証）に加えて、SAML 2.0に準拠した外部のIdP（Identity Provider／IDプロバイダー）を組み合わせてご利用いただけます。SAML認証を導入することで、組織で既に運用しているIdP（Google Workspace、Microsoft Entra ID、Oktaなど）と連携してZUNDA IDへシングルサインオン（SSO）でログインできるようになります。動作確認済みのIdP以下のIdPについては、弊社で動作確認を行っております。各IdPごとに固有の設定手順がありますので、ご利用のIdPに対応する下記ページの手順に従って設定を進めてください。Google WorkspaceMicrosoft Entra IDOktaSeciossLinkHENNGE SSOGMOトラスト・ログイン SSOCloudGate Uno (オンラインコミュニティサイト「くらげ広場」にて公開しております。CloudGate UNOの管理者または管理している部署の方でしたら登録可能ですので、お手数ですがご登録の上閲覧をお願い致します。)一覧にないIdPであっても、SAML 2.0に準拠したIdPであれば、ACSのURL、エンティティID、IdPメタデータなどの必要なパラメータを設定いただくことでご利用いただけます。その場合は、各IdPのドキュメントとZUNDA ID側の設定項目を照らし合わせながら設定してください。サポートされている機能ZUNDA IDのSAML認証では、以下の機能をサポートしています。各種ユーザー情報の取り込みIdPから送信されるSAMLアサーションをもとに、メールアドレス、名前（姓・名）、表示名を取り込むことができます。JIT（Just-In-Time）サインアップと組み合わせることで、ユーザーが初回ログインした際に自動的にZUNDA ID側にアカウントが作成されるため、事前にユーザーを一括登録する必要はありません。SP Initiated loginおよびIdP Initiated loginZUNDA IDのログイン画面からSAMLログインを開始する「SP Initiated login」と、IdP側のダッシュボード（Google Workspaceのアプリ一覧、Microsoft Myapps、Oktaのダッシュボードなど）からアプリを起動する「IdP Initiated login」の両方に対応しております。AuthnRequestへの署名ZUNDA IDからIdPへ送信する認証リクエスト（AuthnRequest）にデジタル署名を付与することで、リクエストの改ざんを検出できます。IdPが署名検証を要求する場合は、ZUNDA ID側で発行されるSP証明書をIdPに登録してください。IdP証明書およびIdP側でのSP証明書の検証IdPから送信されるSAMLレスポンスの署名を、登録されたIdP証明書で検証します。同様に、IdP側でもZUNDA IDから送信される署名を検証できます。これにより認証過程でのなりすましや改ざんを防止します。設定の全体的な流れSAML認証を導入する際は、以下の順序で進めることを強く推奨します。ログイン方法のリカバリー設定（最初に必ず実施）SAML認証の設定を始める前に、必ずリカバリーキーを発行・保管してください。設定不備やIdP側の障害でログインできなくなった場合の備えとなります。SAMLプロバイダーの作成と動作確認ご利用のIdPに応じた設定手順に従って、ZUNDA IDとIdPの双方で必要な設定を行い、ログインテストを実施してください。作成したSAMLプロバイダーをログイン方法として有効化テストが成功したら、ドメインに対してSAMLプロバイダーを紐づけることで、実際のユーザーログインに利用できるようになります。ログイン方法のリカバリー設定設定したログイン方法（SAML認証、Google認証、Microsoft認証など）が、IdP側の障害、設定ミス、証明書の失効などの理由で利用できなくなった場合、アカウントがロックアウトされてしまう可能性があります。これを防ぐため、SAML認証を有効化する前に、必ずリカバリーキーを発行し、安全な場所に保管してください。リカバリーキーはオフラインで発行でき、SAML認証が利用できない状態でも、リカバリーキーを使ってグローバル管理者権限を持つユーザーがZUNDA IDにログインし、設定を修正することができます。ログイン方法のリカバリー設定の設定方法のページを参照し、SAML認証の設定をする前に準備をすることをおすすめいたします。作成したSAMLプロバイダーをログイン方法として利用する方法SAMLプロバイダーの作成とテストが完了したら、それを実際のログイン方法として有効化する必要があります。ZUNDA IDではドメイン単位でログイン方法を紐づけることができるため、対象のドメインに対して作成したSAMLプロバイダーを設定してください。作成したSAMLプロバイダーをログイン方法として利用する方法のページを参照し、設定を進めてください。
Keeper のボルトにオフラインでアクセスする方法
Keeper / ログイン・認証連携
hanae　2026年7月31日 05:42 更新
Keeperでオフラインアクセスを行うための条件と事前の準備について説明します。はじめにKeeper のオフラインアクセス機能は、Keeper との通信が確保されていない場合や、Keeper の認証に用いているIdPの障害発生時といった緊急事態の際にも、Keeper のボルトにアクセスできる機能です。ただし、この機能を利用するためには事前の準備が必要となります。緊急時に備えて、あらかじめオフラインアクセスが可能な状態をご準備ください。利用条件利用可能なクライアントマスターパスワードWebボルト（Webブラウザ）デスクトップアプリモバイルアプリ生体認証デスクトップアプリモバイルアプリオフラインアクセスの前提条件オフラインアクセスは、端末内に保存された一時的なセッション情報を利用します。そのため、以下の操作を行うとオフラインアクセスができなくなります。ブラウザのキャッシュやCookieの削除PCのシャットダウンや再起動時に、ブラウザのセッションやキャッシュを自動削除する設定になっている環境では、本機能は利用できません。デスクトップアプリの初期化（アンインストール等）「オフラインアクセスの有効期間（タイマー）」の超過事前準備（マスターパスワードの場合）管理者側のポリシー設定[ログイン設定] > [SSOユーザーにマスターパスワードの作成とマスターパスワードでのログインを許可する] が有効。 [アカウント設定] > [オフラインアクセスを制限] が無効。クライアント（ユーザー）側の設定Keeper のアカウントの設定画面で、[全般] > [マスターパスワード]をセットアップします。マスターパスワードは管理者でもリセット不可能なため、併せてリカバリーフレーズのセットアップも行なってください。リカバリフレーズの設定はこちらを参照: リカバリーフレーズを設定する次に、[セキュリティ] > [オフラインアクセスを許可する]で、オフ以外を選択します。※オフラインアクセスの許可設定は、デバイス・クライアント単位で行う必要があります。ブラウザ・アプリの両方でオフラインアクセスを利用する場合、ブラウザ・アプリのそれぞれでオフラインアクセスを許可してください。マスターパスワードでログイン後、すぐにログアウトします。 ※この操作により、端末にオフライン用のログイン情報が安全にキャッシュされます。ログイン方法を法人SSOログイン→マスターパスワードに切り替え、ログインします。マスターパスワードでログイン後、すぐにログアウトします。以上で事前準備は完了です。オフラインアクセスの利用方法事前準備が全て完了すると、画面右下に「オフラインで作業ボタン」が表示されるので押します。マスターパスワードを入力し、ログインします。オフラインモードのままボルトにアクセス出来ていれば完了です。補足マスターパスワードの代わりに「生体認証ログイン」を利用してオフラインアクセスすることも可能です。条件を満たしていれば、ログイン画面で「オフラインで作業」が選択できるようになります。まとめオフラインアクセスを利用するための条件をまとめます。管理者側のポリシー設定「SSOユーザーのマスターパスワード」が有効になっている（ログイン設定）「オフラインアクセスの制限」が無効になっている（アカウント設定）ユーザー側の設定・状態マスターパスワードが構成（作成）されているセキュリティ設定で「オフラインアクセス」がオンになって同じデバイス・プラットフォームで、ログイン画面の「メールアドレスを記憶する」にチェックを入れて、少なくとも1回はオンラインでログインしているユーザーセッションがリセットされていない（例：デスクトップアプリの初期化、ブラウザのキャッシュ/Cookieの消去をしていないこと）端末での最終オンラインアクセスから、設定した「オフラインアクセスの有効期間（タイマー）」が経過していない
【解決済み】Keeper Automatorの動作不調に関するお詫びと暫定的な操作のご案内（2025年11月26日〜）
Keeper / 重要な変更・障害のお知らせ
masaruyokoi　2026年3月8日 08:05 更新
平素は格別のご高配を賜り、厚く御礼申し上げます。さて、現在、弊社が提供しております Keeper Automator Hosting におきまして、Keeper Automator のプログラムの不調により、間欠的に自動承認が正常に行われない事象が発生しておりました。お客様には多大なるご迷惑をおかけしたことを、深くお詫び申し上げます。本件は2026年1月21日に修正完了いたしました。発生事象の詳細対象サービスKeeper Automator Hosting発生日時2025年08月14日 9:40:33 から2026年1月20日まで事象本来、Keeper Automator により自動で実施されるべき新しいデバイス・ブラウザでのログイン承認が、管理者による手動承認を求められることがあります。この事象は1日に数十秒程度のサービス停止が数回起きていました。解消に向けた活動Keeper が提供しているKeeper Automatorの新しいバージョンが、実行環境では安定して動作しないことがわかりました。実行環境を変更することで問題解消をしています。
ZUNDA ID を利用した各サービスへのログイン方法
ZUNDA ID / ログイン・認証連携
飯塚亮騎　2026年9月15日 04:33 更新
ZUNDA ID を使用したサービスへのログインは、対象サービスの権限が含まれるグループにログインしたいユーザーアカウトが所属している必要があります。権限については[ロール設定] を確認してください。ZUNDA ID のマイページから各サービスにログインするZUNDA ID にログインしますマイページに使用できるサービスが表示されます。サービスをクリックすることでログインできます。使用したいサービスが表示されない場合は利用する権限がありません。ユーザーアカウント・グループ・ロールの関係についてを確認してください。対象のサービスから ZUNDA ID 経由でログインする対象サービスのログイン画面から ZUNDA ID を使ってログインすることができます。例: ITサポート by ZUNDA の場合[サインイン] をクリックします遷移先の ZUNDA ID のログイン画面に遷移します。画面の指示に従ってメールアドレスを入力し、ログインをしてください。ご不明な点などございましたら以下のシステムお問い合わせフォームよりお問い合わせください。https://ask.zunda.co.jp/id
ID基盤を使った SAML シングルサインオンをお勧めする理由
Keeper / ログイン・認証連携
hanae　2025年3月14日 06:13 更新
Keeper へのログイン方法について、ID基盤を使った SAML シングルサインオンをお勧めしています。 SAML シングルサインオンをお勧めする理由Keeper ログイン時にマスターパスワードレスログインが可能で、セキュリティリスクを軽減できます。SCIM によるプロビジョニングと、JIT(Just In Time)プロビジョニングにより、ユーザー管理工数を削減可能です。IdP で管理しているユーザーのグループ情報も Keeper にプッシュすることも可能(Entra ID、Okta に限る)です。IdP の条件付きアクセスと組み合わせることで高度なアクセス管理も可能です。
Keeper のユーザーステータスに関する不具合および、アカウント移管同意の仕様変更
Keeper / 重要な変更・障害のお知らせ
hanae　2026年3月8日 08:03 更新
Keeper パスワードマネージャーにおいて、ユーザーステータスの表示と挙動の不一致、およびアカウント移管の同意について仕様変更がありました。SSOログインのユーザーを作成する場合、これらの影響を考慮する必要があります。以下、ご確認お願いいたします。ユーザーステータスの表示と挙動の不一致概要以下の条件においてユーザーを作成した場合、管理コンソール上で確認できるユーザーステータスと、実際の挙動が一致しないという不具合が発生しています。【条件】SSOログインを想定かつ、アカウント移管が有効になっているロールが割り当たっている対象製品Keeper Managerd by ZUNDAKeeper EnterpriseKeeper Enterprise PlusKeeperKeeper Gold PackageKeeper Enterprise Base Plun (Keeper Enterprise)不具合発生前の仕様上に記載の条件において、ユーザーを作成した場合、ユーザーがログインを実施するまで、そのユーザーのステータスは「招待済み」と表示されていました。また、そのユーザーがログインを実施すると、アカウント移管同意のポップアップが表示され、同意(承認)をスルーすると、7日後にそのユーザーはブロックされ、ユーザーステータスは「ブロック済み」となりました(アカウント移管の同意の期限が7日ということ)。なお、「ブロック済み」になったユーザーは、管理者により「アカウント同意の延長」を実施いただくことで、再度ログインが可能になります。現在の仕様(不具合箇所)上に記載の条件において、ユーザーを作成した場合、作成後7日以内にログインを実施しないと、そのユーザーのステータスは「招待済み」「ブロック済み」となります。ただし、「ブロック済み」ステータスであっても、ログインは実施可能です。つまり、管理コンソール上で確認できるユーザーステータスと、実際の挙動が一致しておりません。こちらは、Keeper 社に報告済みとなります。解消まで少々お待ちください。なお、アカウント移管の同意の期日が変更になっているので、下段をご確認ください。アカウント移管の同意の仕様変更概要アカウント移管の同意期日が、7日から1日に変更になりました。対象製品全プラン今後の対応初めてのログイン時に、アカウント移管同意のポップアップが表示されますので、同意ボタンをクリックするようにユーザーに周知してください。その他なお、これらの不具合については Keeper 社から公式な情報が公開されていません。弊社は Keeper 社との対応履歴およびお客様とのやり取りに基づき、開示可能な情報のみを共有させていただいております。
Keeper へのログインをマスターパスワードから SSO ログインに変更する手続き
Keeper / ログイン・認証連携
hanae　2025年10月27日 02:24 更新
以下のような契約手続き・手順が必要です。契約手続きKeeper へのログインを、SSO ログインにするためには、以下のプランを契約している必要があります。EnterpriseEnterprise PlusEnterprise Base PlunGold Packageプランを変更(アップグレード)するためには、以下のURLよりお問い合わせください。※「契約変更」を選択してください。https://help.zunda.co.jp/hc/ja/requests/new 手順1. SSO ログイン用のノードを作成SSO ログイン用のノードを作成します。※参照: ノードの作成と設定 2. SSO ログイン用のロールを作成SSO ログイン用のノードを作成します。※参照: ロールの作成と設定ポリシーを設定します。この際、ポリシー＞ログイン設定＞SSOユーザーは「有効」にしてください。(後ほど、無効にします。)それ以外のポリシーの内容は、ログイン方法別ロール推奨設定の推奨設定＞SSOログインロールの推奨を確認してください。その後、「ノードとサブノードのデフォルトロールとして設定」にチェックを入れてください。3. プロビジョニングの設定Keeper と IdP のプロビジョニングの設定を行ってください。※参照: ユーザーの作成・追加方法＞IdPと連携し、プロビジョニングを行う方法 4. ロールの再割り当てとノードの移動※まずは、テスト用ユーザー1名で以下の作業を行い、正しく SSO ログインできることを確認した後、全ユーザーで同様の作業を行ってください。ユーザーに、2で作ったロールを割り当てを行います。その後、1で作ったノードにユーザーを移動します。ユーザーを選択＞ノード＞移動したいノードを選択します。そのユーザーが正しく、SSO ログインできることを確認してください。初回のみマスターパスワードログインが求められますが、それ以降は SSO ログインが可能になります。全ユーザーに対して同様の作業を行ってください。※一括でノードの移動は不可となります 5. 2で作成したロールのポリシー変更2で作成したロールの、ログイン設定＞SSOユーザーを「無効」にしてください。ただし、Keeper Adminロールは、引き続き、ログイン設定＞SSOユーザーを「有効」のロールを割り当ててください。※参照: ロールとは 6. マスターパスワードログイン用のロールをユーザーから外すマスターパスワードログイン用のロールをユーザーから外してください。注意点親ノードにマスターパスワードログイン用のユーザーを作成してください。例）it-admin@zunda.co.jpIdPのセッションが切れたときなどに、救済できるようにするため。デバイス承認が必須となります。Keeper へのログインが SSO ログインになると、デバイス認証が走ります。※参照: Keeper でデバイスの承認を行う管理者による承認が必要ですが、それを自動化することも可能です(Keeper Automator)。3,000円/月で ZUNDAの Keeper Automator Hosting サービスを受けることが可能です。※参照: Keeper Automator Hosting について弊社での設定を希望の場合、設定用のアカウントを1つ消費しますのでご留意ください。
Keeper に登録した Entra ID の SAML証明書を更新する
Keeper / ログイン・認証連携
masaruyokoi　2024年8月23日 16:36 更新
Entra ID ではシングルサインオンの SAML 署名証明書に有効期間があります (デフォルトは3年間) 。そのため、定期的に署名証明書を更新し、Keeper に登録する作業が必要です。期限内に更新することで、従業員はサービスの中断なく Keeper を継続して利用できます。準備この作業には、以下のユーザアカウントが必要です。Entra ID「アプリケーション管理者」の役割を持つユーザー (グローバル管理者でも可)Keeperルートノードにいるマスターパスワードログインユーザーで作業することを強く推奨します。設定対象の SSO ノードにいるユーザーで作業した場合、設定を誤った場合にアカウントから締め出される可能性があります。管理上の許可「ブリッジ／SSOを管理」のロールが付与されたユーザーデフォルトの "Keeper Administrator" ロールが付与されていれば充足します。シングルサインオンの動作確認用に、実際に SSO でログイン可能なユーザー更新手順Keeper Password Manager の管理画面の準備Keeper Password Managerの管理者コンソールにログインしておきます。Keeper の管理コンソールは、後ほどのEntraの画面とは別のブラウザ画面 (タブまたはウインドウ) を使ってください。この後にSAML IdPの設定を変更するとSAMLでログインできなくなります、管理画面のログイン状態を維持するために、管理画面を閉じないようにしてください。もし閉じてしまった場合は、Rootノードに管理者として作ったマスターパスワードを使うユーザを利用してください。 IdPでの新証明書の作成と metadata XML取得IdP側で新しい証明書を作成し、これとSAMLの設定を含んだ metadata XMLファイルを取得します。metadata XMLはEntra IDでは「フェデレーションXML」または「フェデレーション証明書XML」という名前になっております。新しいブラウザウィンドウかTabを開いて、Entra ID のエンタープライズアプリケーションの、Keeper Password Managerの項目へ移動してください。[管理] - [シングルサインオン] に移動します。「SAML証明書」の編集ボタンを押して、「SAML署名証明書」に移動します。「+新しい証明書」をクリックして、新しい証明書を作成します。作成したら、「保存」ボタンを押します。保存したら、新しく作った証明書の「フェデレーションXML」をダウンロードしてください。新証明書の metadata xmlをKeeperに反映Keeper Password Managerの管理画面に移動し、SAML IdP証明書を更新するノードの、「ユーザプロビジョニング」に進み、「SSO Connect® Cloud を使用したシングルサインオン」の編集に進んでください。ご注意: 　証明書更新を行うノードを、よくご確認ください。「SSO Connect® Cloud を使用したシングルサインオン」の編集画面では「SAMLメタデータ」の部分で、先程のEntra IDで取得した「フェデレーション証明書XML」をアップロードします。アップロードが出来ましたら、ページ上部の戻るボタンを押して「SSO Connect® Cloud を使用したシングルサインオン」の表示画面に戻って、証明書有効期限が新しい証明書の期限になっていることを確認してください。署名証明書の切替Keeper に XML のアップロードが完了したら、Entra ID にて新しい証明書をアクティブにします。ここではシングルサインオンの Test をしません。 [いいえ、後でtestします] をクリックします。Web ブラウザのプライベートウインドウを開き、Keeper の Web ボルトにてシングルサインオンが正常に動作することを確認してください。日本リージョン https://www.keepersecurity.jp/vault USリージョン https://www.keepersecurity.com/vaultその後、Entra IDのウィンドウにて、シングルサインオンのテストを実施してください。途中でうまく行かなくなったらもし証明書の更新中にうまく行かなくなったら、これらの対応をしてください。Keeper 側に設定してあるシングルサインオン設定は絶対に削除しないでください。記録へのアクセスを永久に失う可能性があります。１つ前のメタデータXMLをアクティブ化し、そのメタデータを登録し直してください。SAMLデバッグメッセージなどのご確認ください。これらの対応をしてもうまくいかない場合は、ZUNDA までお問い合わせください。
Microsoft 365 と任意の IdP をフェデレーションする手順
Microsoft 365 / アカウント・認証・権限
shao　2023年8月3日 00:48 更新
Microsoft 365 を任意の IdP (例: Google Workspace, Okta) を利用してログインするように構成できます。制限事項IdP 経由でログインする設定はドメイン単位で行います。当該ドメインのユーザにはパスワードが作成されないため、Azure AD Join のログインやリモートデスクトップ、AADDSなどのパスワード(ハッシュ)を利用したサービスは利用できません。設定には PowerShell の知識が必要です。設定手順新規設定Microsoft Graph モジュールをインストールしますInstall-Module Microsoft.Graph資格情報を取得しますConnect-MgGraph -Scopes "Directory.AccessAsUser.All", "Domain.ReadWrite.All"SSO に必要な情報を登録します。New-MgDomainFederationConfiguration ` -DomainId example.com ` -DisplayName example.com ` -IssuerUri https://accounts.google.com/o/saml2?idpid=XXXXXX ` -PreferredAuthenticationProtocol "SAMLP" ` -ActiveSignInUri https://accounts.google.com/o/saml2/idp?idpid=XXXXXX ` -SigningCertificate MIIDabcd........7890abfd ` -PassiveSignInUri https://accounts.google.com/o/saml2/idp?idpid=XXXXXX ` -SignOutUri https://accounts.google.com/o/saml2/idp?idpid=XXXXXX証明書の更新資格情報を取得しますConnect-MgGraph -Scopes "Directory.AccessAsUser.All", "Domain.ReadWrite.All"ドメインの一覧を取得しますGet-MgDomain前述の結果からドメインID (ドメイン名) を確認し、詳細情報を取得しますGet-MgDomainFederationConfiguration -DomainId example.com | fl新しい証明書を登録しますUpdate-MgDomainFederationConfiguration ` -DomainId example.com ` -InternalDomainFederationId '12345678-90ab-cdef-1234-567890abcdef' ` -SigningCertificate MIIDabcd........7890abfd
SCIM と JIT の設定について
Keeper / ユーザー・組織・権限管理
daichi　2026年4月17日 00:07 更新
Entra ID(旧: Azure Active Directory)や Okta などの IdP を活用してのユーザー・プロビジョニングには SCIM とジャストインタイム(以下、JIT)の2つの設定が Keeper にはあります。 SCIM と JIT の設定ですが、Keeper においては、「両方」ともに設定して頂くことをおすすめしております。SCIM のみを設定している場合、IdP と同期されたタイミングで自動で Keeper にユーザーが作成されますが、同期には時間がかかる場合があります(例えば、Entra ID の場合 SCIM では40分に1回同期されるようになっています)。そのため、アカウントを作成した直後のユーザーで、次回の同期タイミングが到来する前に Keeper にログインしようとした場合、SCIM だけではログインに失敗します。JIT と併用することで、こういったケースでもログインに成功します。一方、JIT による同期はアカウント作成時にしか行われません。SCIM と連携しておくことで、退職など Entra ID 側で外れたユーザーについて、Keeper 側でも自動的に凍結状態になります。またグループ(チーム)の所属情報も SCIM でしか同期できません。ぜひ、両方とも設定してください。注意点Keeper には、ノード(セキュリティ単位でユーザーをグループ化する方法)が存在します。SAML ログインとする場合は、最上位ノードの配下に、SSOログイン用のノードを作成してください。IdP の乗り換えを検討する場合や、IdP の構築についてご相談ある場合は、弊社までお問い合わせください。
Keeper SSO 証明書の更新について
Keeper / ログイン・認証連携
shao　2024年8月23日 22:28 更新
Keeper では 2022年 8月 7日にシングルサインオンに利用している証明書の更新を行いました。後述の通り、Azure Active Directory, Google Cloud Identity, Okta などを利用されている一般的な構成では影響がありませんが、一部の IdP (ADFS, Ping Identity) やシングルログアウト (SLO) 機能を利用されている場合は新しい証明書を IdP に登録する必要があります。対象以下にあてはまる環境でご利用いただいているお客様は、SAML SP シングルサインオン証明書 (以下SSO 証明書) の更新が必要です。 (A) 以下のすべてに該当するケースADFS (Active Directory Federation Service) または Ping Identity を IdP として連携しているKeeper Automator を利用していないSSO Connect® Cloud を利用している (オンプレミス版の SSO Connect は該当しません)(B) 以下のいずれかに該当するケースOkta でシングルログアウト (SLO) の構成をしているOkta の管理ポータルで、Keeper の "Sign On" タブを開き、 "Enable Single Logout" が有効になっている場合は該当しますSP-initiated SLO の構成をしている事象と対応対象 (A) の場合: シングルサインオン構成でのログインができなくなります対象 (B) の場合: Keeper からログアウトした際に IdP ではログイン状態が持続します証明書の更新ができていない場合は、【sales@zunda.co.jp】までご連絡ください。該当するお客様への対応「対象」のセクションをご確認いただき、影響が見込まれるお客様は弊社までご連絡ください。(アドバンスドサポートを契約されている場合は Slack 等のチャットでも構いません)事前に SSO を必要としない管理者アカウントで管理コンソールにログインできることを確認してください。また IdP の管理画面にログインできることも確認してください。新しい証明書は 2022年 8月 8日に利用可能となる予定ですが、時差等の都合で正確な日時がわかっておりません。利用可能になったタイミングで弊社より連絡いたしますのでお待ちください。管理コンソールの「管理者」セクションから、SSO設定を行っているノードを選択し、[プロビジョニング] タブから SSO Connect Cloud の設定を「表示」させます「SP認証エクスポート」を選択します入手した証明書の新しい期限は openssl コマンドで確認できます。openssl x509 -noout -text -in (ファイル名)新しい証明書を IdP に登録します。次回の更新次回の Keeper SSO 証明書の更新は、2032年 8月26日を予定しています。関連文章SSO Certificate Renewal 2022 - Release Notes
Keeper Automator Hosting について
Keeper / 契約・ライセンス・サポート
shao　2026年1月13日 03:29 更新
Keeper SSO Connect Cloud を利用して SAML シングルサインオン (SSO) を構成した際、新しいデバイスおよびブラウザでログインする際に求められる承認操作は Keeper Automator サービスを利用することで自動化できます。 ZUNDAでは、この Keeper Automator サービスをお客様に代わって構築、運用する「Keeper Automator Hosting」を提供しております。▲ Keeper Automator を利用すると、上記画面の表示が省略されるようになります。提供条件以下のプランのいずれかを契約されていることKeeper managed by ZUNDAEnterprise (年間契約)Enterprise Plus (年間契約)Keeper (カスタムプラン)Keeper - Enterprise Base Plan User LicensesKeeper - Gold Package BundleZUNDAのアドバンスドサポートをご契約いただいていることKeeper の SAML SSO (シングルサインオン) 設定が完了していることKeeper Automator を動作させる bot ユーザを作成します。契約条件により、有償ライセンスを1個消費します。契約条件については、営業までご確認をお願いいたします。基本構成 1ノードに対して1つの Automator を設定いたします。ノードの追加および、該当ノードへの Automator の設定は無償となりますが、該当ノードに100ユーザー以上のライセンス適用があることが条件となります。Automator を 3つ以上の設定をご要望の際は、構成や要件を確認の上、個別相談(案件ごとの可否判断)とさせていただきます。導入手順弊社にお申込みください (本ドキュメント末尾参照)弊社にて設定を行います設定が完了しましたら連絡いたします。動作を確認 (新しいデバイスでログインする際に、承認を求める画面が表示されなくなること) してください。お申し込みから利用が可能になるまで1週間程度かかります。価格無料でご利用いただけます。ただし、提供条件に記載のアドバンスドサポートをご契約いただく必要がありますお問い合わせ、お申込み弊社営業担当まで、メールまたは問い合わせフォームよりご依頼ください。
Keeper を使いはじめる (シングルサインオンを利用している組織)
Keeper / 導入・利用開始・アプリ配布
shao　2026年3月26日 08:01 更新
Keeper を使いはじめるには、Webブラウザに拡張機能をインストールし、組織のアカウントでログインする必要があります。注意Keeperから招待メールが届いた場合は以下の手順に従って操作してください。→ Keeper を使いはじめる (マスターパスワードを利用している組織)拡張機能のインストール拡張機能はWebブラウザ毎に用意されています。ご利用のWebブラウザにあわせてインストールしてください。Google ChromeMicrosoft Edge (Chromium版, v79以降)FirefoxSafari (macOSアプリをご利用ください)スマートフォン向けにはアプリ版のKeeper をインストールしますiOSAndroidブラウザでのログインログイン前に、Keeper Security 拡張機能を常に表示するように設定します。 Chrome では、拡張機能メニューを開き、ピンをクリックしてツールバーにKeeperのメニューを表示させます。Keeperのメニューをクリックし「ログイン」をクリックしますメールアドレスを入力し「次へ」をクリックします組織でシングルサインオンが設定されている場合は、自動的に組織のログイン画面に移動します。 ※一度ログアウトした場合や、デバイスの承認を受けて再ログインする場合に「法人SSOログイン」の表示が出ることがあります。組織名が入力されている場合はそのまま「接続」をクリックするか、「キャンセル」を押してメールアドレスを再度入力してください。(どちらの手順でも組織のログイン画面に遷移します) 初回ログイン直後は、どのチームにも所属してない状態になっています。管理者に連絡してチームへの割当てを依頼してください。ログイン時にデバイスの承認を求められた場合新しいデバイスやWebブラウザでログインした場合、以下のように「デバイスを承認してください」と表示されることがあります。この場合、「管理者承認をリクエスト」をクリックして管理者に承認操作を依頼してください。→ Keeper でデバイスの承認を行う (管理者向け)管理者に承認をしてもらったら、最初から操作する (ログインしなおす) ことでログインが正常に完了します。Keeper の iOS 版または Android 版を利用中であれば「Keeperプッシュ通知を送信」も利用できます。(自分で承認操作を行えます)
SeciossLink
ZUNDA ID / ログイン・認証連携
daichi　2026年5月27日 03:57 更新
このページについてSeciossLinkをIdPとして利用し、ZUNDA IDとSAML連携させるための手順を説明します。この設定を完了すると、SeciossLinkにサインインしているユーザーが、その認証情報を用いてZUNDA IDへシングルサインオンでログインできるようになります。設定に必要なもの事前に以下を揃えておいてください。SeciossLinkの管理者アカウントシングルサインオン設定を作成・編集できる権限を持つアカウントが必要です。ZUNDA IDの認証方法の管理権限を持つユーザーSAMLプロバイダーの作成と設定を行うため、ZUNDA IDの管理権限を持つユーザーが必要です。事前にリカバリーキーを発行・保管していること設定不備やIdP障害によるロックアウトを防ぐため、ログイン方法のリカバリー設定の設定方法を参照し、リカバリーキーを事前に発行してください。SeciossLink側の設定（サービスプロバイダー登録、ユーザーへの割り当て）SeciossLinkにZUNDA IDをサービスプロバイダーとして登録し、対象ユーザー（またはグループ、組織など）にサービスを割り当てる必要があります。詳細はSeciossLinkのマニュアルをご確認ください。設定手順ZUNDA IDとSeciossLinkの管理画面を交互に操作して設定を進めます。両方の画面を同時に開いておくとスムーズです。ZUNDA IDの「ログイン方法設定」画面を開き、「SAMLプロバイダーを追加」ボタンをクリックしてください表示されたダイアログに、このプロバイダーを識別するための任意の表示名（例：SeciossLink）を入力し、「作成」をクリックしてプロバイダー詳細画面へ進んでください。ここで付けた名前は、ログイン画面や設定画面で表示されます。SeciossLinkの管理コンソールへログインし、左サイドメニューから「シングルサインオン」→「SAML」を開き、画面右上の「登録」ボタンをクリックしてくださいZUNDA IDのプロバイダー詳細画面に戻り、「メタデータURL（SP）」の「ダウンロード」ボタンをクリックして、SP側のメタデータXMLを保存してくださいSPメタデータには、ACS URLやエンティティIDなど、SeciossLink側で必要となるZUNDA ID（SP）の情報が含まれています。このファイルをSeciossLink側へアップロードすることで、主要な設定を一括で反映させることができます。SeciossLinkのSAMLサービスプロバイダー登録画面を下にスクロールし、「メタデータ」セクションの「ファイルを選択」から先ほどダウンロードしたSPメタデータXMLファイルを選択し、「読み込む」ボタンをクリックしてください読み込みに成功すると、エンティティIDやAssertion Consumer Serviceなどの値が自動的に入力されます。画面上部に戻り、「サービスID」と「サービス名」を入力してくださいサービスIDzunda-id（任意の一意な識別子）サービス名ZUNDA IDエンティティIDとAssertion Consumer Serviceは、前手順でメタデータから自動入力されていることを確認してください。「IDの属性」を urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress に、「ユーザーIDの属性」を「メールアドレス」に変更してくださいZUNDA IDではNameIDフォーマットとしてemailAddressを期待しており、ユーザーの紐付けにメールアドレスを利用するため、この設定が必要です。「送信する属性」セクションで「姓」「名」「別名（表示名）」にチェックを入れ、それぞれの「属性名」にZUNDA IDが期待するスキーマURIを入力してください姓：http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname名：http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname表示名（別名）：http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameこの属性マッピングにより、SAMLログイン時にSeciossLinkからZUNDA IDへユーザーの姓・名・表示名が送信され、JITサインアップ時にZUNDA ID側に正しくユーザー名を取り込めるようになります。SP証明書の登録と署名検証の有効化（任意）必須ではありませんが、SeciossLink側にZUNDA IDのSP証明書を登録し、AuthnRequestの署名検証を有効化することで、リクエストが確かにSP（ZUNDA ID）から送信されたものであることをSeciossLinkが暗号学的に検証できるようになり、なりすましやリクエストの改ざんに対するセキュリティが高まります。SeciossLinkの登録画面をさらにスクロールし、「リクエストの署名検証」の「有効」にチェックを入れ、「署名の適用範囲」で「アサーションとレスポンス両方に適用」を選択してくださいZUNDA IDのプロバイダー詳細画面より、「SP証明書」セクションの「ダウンロード」ボタンをクリックして、プライマリーSP証明書ファイルをダウンロードしてくださいSeciossLinkの登録画面に戻り、「SP証明書」セクションの「ファイルを選択」をクリックし、先ほどダウンロードしたSP証明書ファイルをアップロードしてくださいここまで設定して、「保存」ボタンをクリックしてSeciossLink側の設定を保存してください。IdPメタデータの取得とインポートSeciossLinkからIdPメタデータをダウンロードし、ZUNDA ID側にインポートしてIdP側の設定値を一括で取り込みます。SeciossLinkで「シングルサインオン」→「SAML」を開き、画面右上の「設定」タブをクリックし、「Idpメタデータ」の「ダウンロード」ボタンをクリックしてIdPメタデータXMLを保存してくださいこのメタデータには、SeciossLinkのIdP Entity ID、SSO URL、IdP署名証明書などが含まれており、ZUNDA IDにインポートすることでIdP側の設定を一括で取り込めます。ZUNDA IDのプロバイダー詳細画面に戻り、「メタデータXMLをインポート」ボタンをクリックしてください表示されたダイアログから「ファイルから読み込む」をクリックし、先ほど保存したIdPメタデータXMLファイルを選択してください。読み込まれたことを確認したら、「メタデータXMLをインポート」ボタンをクリックしてください。IdP Entity ID、SSO URL、IdP証明書などの設定値がすべてインポートされたことを確認してください。テストをする設定が完了したら、プロバイダーを有効化する前に必ずログインテストを実施して、設定が正しいか、SeciossLinkユーザーの情報が正しく取り込めるかを確認してください。テストにSeciossLink側で対象サービスへのユーザー割り当てが必要なため、事前にテスト実行者のアカウントへ作成したサービスを割り当てておいてください。ZUNDA IDのSeciossLinkプロバイダー詳細画面より、「テスト」ボタンをクリックしてくださいテストボタンをクリックすると、ポップアップウィンドウでSeciossLinkのログイン画面が開きます。ポップアップがブロックされている場合は、ブラウザのポップアップブロッカーを一時的に無効化してください。SeciossLinkのログイン画面が表示されるので、テスト実行者のアカウントでSeciossLinkへログインしてくださいログインに成功すると、以下のように「SSOログインテストに成功しました」と表示され、NameID・メールアドレス・姓・名のチェック結果が緑のチェックになっていれば設定完了です（表示名は任意項目のため、未設定の場合はZUNDA ID側で自動設定されます）テストに失敗した場合は、以下を確認してください。SeciossLinkのIdPメタデータが正しくZUNDA IDにインポートされているかSeciossLink側で「送信する属性」のスキーマURIが正しく設定されているかテスト実行者のアカウントに作成したサービスが割り当てられているかテストが完了したら、プロバイダー詳細画面に戻り「状態」を ON に切り替えることで、SeciossLinkによるSAMLログインが有効になります。ログイン方法が利用できなくなった場合に備えて、ログイン方法のリカバリー設定の設定方法を事前に行っておくことを強く推奨します。設定完了後は作成したSAMLプロバイダーをログイン方法として利用する方法を参照し、ログイン方法として有効化してください。
Okta
ZUNDA ID / ログイン・認証連携
daichi　2026年8月18日 03:35 更新
このページについてOktaをIdPとして利用し、ZUNDA IDとSAML連携させるための手順を説明します。この設定を完了すると、Oktaにサインインしているユーザーが、その認証情報を用いてZUNDA IDへシングルサインオンでログインできるようになります。設定に必要なもの事前に以下を揃えておいてください。Oktaのアプリケーション統合を作成・管理できる権限を持つユーザーOkta管理者（Super Admin もしくは Application Admin）ロールが必要です。ZUNDA IDの認証方法の管理権限を持つユーザーSAMLプロバイダーの作成と設定を行うため、ZUNDA IDの管理権限を持つユーザーが必要です。事前にリカバリーキーを発行・保管していること設定不備やIdP障害によるロックアウトを防ぐため、ログイン方法のリカバリー設定の設定方法を参照し、リカバリーキーを事前に発行してください。設定手順ZUNDA IDとOkta Admin Consoleの両方を交互に操作して設定を進めます。両方の画面を同時に開いておくとスムーズです。ZUNDA IDの「ログイン方法設定」画面を開き、「SAMLプロバイダー」を追加してください表示名に任意の名前（例：Okta）を入力し、「作成」をクリックして次の画面に進めてください。表示されたプロバイダー詳細画面より、「メタデータURL（SP）」の「ダウンロード」ボタンをクリックして、SPのメタデータXMLをダウンロードしてくださいOkta Admin Console（<your-domain>-admin.okta.com）にログインし、左側メニューから「アプリケーション」→「アプリケーション」を開いて、「アプリ統合を作成」をクリックしてください「新しいアプリ統合を作成」ダイアログで、サインオン方式として「SAML 2.0」を選択し、「次へ」をクリックしてくださいOIDCではなくSAML 2.0を選択することで、後続のステップでSAMLパラメータを設定できる画面に進めます。一般設定でアプリ名に「ZUNDA ID」などわかりやすい名前を入力し、「次へ」をクリックしてくださいここで入力したアプリ名は、Oktaのダッシュボード上で表示されます。任意でアプリのロゴをアップロードしておくと、ユーザーがダッシュボードからアプリを起動する際に識別しやすくなります。「SAMLを構成」画面で以下のパラメータを入力してくださいこれらのパラメータは、ZUNDA ID側でSPとして公開している値と一致させる必要があります。シングルサインオンURLhttps://id.zunda.co.jp/auth/saml/acs オーディエンスURI（SPエンティティID）https://id.zunda.co.jp/saml/sp 名前IDのフォーマットEmailAddress アプリケーションのユーザー名メールアドレス上記の値は、先ほどZUNDA IDからダウンロードしたSPメタデータXMLにも記載されていますので、必要に応じて参照してください。入力が完了したら、画面下部の「次へ」をクリックしてください。フィードバック画面で「これは当社で作成した社内アプリです（This is an internal app that we have created）」にチェックを入れ、「終了」をクリックしてアプリ統合を作成してくださいこのチェックを入れることで、Oktaのアプリ統合審査プロセスをスキップし、すぐに自社内でアプリを利用できるようになります。作成されたアプリの「サインオン」タブを開き、「メタデータの詳細」セクションに表示されている「メタデータURL」をブラウザで開いて、表示されたXMLの内容をコピーするか、XMLファイルとして保存してくださいこのメタデータには、OktaのIdP証明書・SSO URL・エンティティIDなどが含まれており、ZUNDA ID側にインポートすることでIdP側の設定を一括で取り込めます。ZUNDA IDはメタデータURLを直接指定する方式には対応していないため、XMLの内容そのもの（テキスト）かファイルとして用意する必要があります。ZUNDA IDのプロバイダー詳細画面に戻り、「メタデータXMLをインポート」ボタンをクリックしてください表示されたダイアログから「ファイルから読み込む」をクリックし、先ほど保存したOktaのメタデータXMLファイルを選択してください。プレビューにIdP Entity IDやSSO URLが表示されることを確認したら、「メタデータXMLをインポート」ボタンをクリックしてください。SP証明書の登録必須ではありませんが、Okta側にZUNDA IDのSP証明書を登録し、AuthnRequestの署名検証を有効化することで、リクエストが確かにSP（ZUNDA ID）から送信されたものであることをOktaが暗号学的に検証できるようになり、なりすましやリクエストの改ざんに対するセキュリティが高まります。ZUNDA IDのOktaプロバイダー詳細画面より、「SP証明書」セクションの「ダウンロード」ボタンをクリックして、SP証明書ファイルを保存してくださいOkta側に戻り、作成したアプリの「サインオン」タブから「SAMLの設定」の「編集」をクリックしてください「SAMLの設定」を編集することで、署名証明書のアップロードや属性ステートメントの追加など、追加の設定を行えるようになります。「一般設定」画面はもとのままで「次へ」をクリックしてください「SAMLを構成」画面を下にスクロールし、「署名証明書」の「ファイルの参照」をクリックして、先ほどZUNDA IDからダウンロードしたSP証明書をアップロードしてくださいアップロードした証明書は、Oktaが受信するAuthnRequestの署名検証に使用されます。これにより、Okta側でリクエストの正当性を確認できるようになります。証明書がアップロードされ、画面上に証明書の情報（発行者・有効期限など）が表示されることを確認したら、「次へ」をクリックしてください。フィードバック画面で「これは当社で作成した社内アプリです」にチェックを入れ、「終了」をクリックして保存してくださいこれで署名検証の設定は完了です。続いて、ユーザー属性の連携を設定します。属性ステートメントの設定SAMLログイン時にOktaからZUNDA IDへ送信するユーザー属性（姓・名・表示名）を設定します。この設定を行わないと、JITサインアップ時にZUNDA ID側でユーザー名を正しく取り込めません。アプリの「一般」タブを開き、「属性ステートメント」セクションの「式を追加する」をクリックしてくださいここで設定する属性ステートメントは、ユーザーがSAMLログインした際にOktaからZUNDA IDへ送信されるユーザー情報（姓・名・表示名）のマッピング定義です。これにより、JITサインアップ時にZUNDA ID側へ正しくユーザー情報が連携されます。以下の3つの属性（姓・名・表示名）を追加してください。「名前のフォーマット」はいずれも「URI Reference」を選択し、「名前」と「式」はZUNDA IDが期待するスキーマと一致させる必要があります。名（givenname）名前：http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname式：user.profile.firstName 姓（surname）名前：http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname式：user.profile.lastName 表示名（name）名前：http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name式：user.profile.displayNameすべての属性が追加されたことを確認してください。user.profile.displayNameはOktaのデフォルトプロファイルに含まれないことがあります。その場合は「Directory」→「Profile Editor」からOktaユーザーのプロファイルにdisplayName属性を追加するか、user.firstName + " " + user.lastNameのような式で代用してください。テストをするここまでの設定が正しく行われているかを、SSOテスト機能で確認します。テストはOkta側へのユーザー割り当てが必要なため、事前にOkta Admin Consoleの「アサインメント」タブから、テスト実行者のアカウントを作成したアプリへ割り当てておいてください。ZUNDA IDのOktaプロバイダー詳細画面より、「テスト」ボタンをクリックしてください別ウィンドウ（またはタブ）でOktaのログイン画面が開きます。テスト実行者のアカウントでOktaへログインを完了させてください。SAMLログインに成功すると、以下のように「SSOログインテストに成功しました」と表示され、NameID・メールアドレス・姓・名のチェック結果が緑のチェックになっていれば設定完了です（表示名は任意項目のため、未設定の場合はZUNDA ID側で自動設定されます）テストに失敗した場合は、以下を確認してください。Oktaのメタデータが正しくZUNDA IDにインポートされているかZUNDA IDからダウンロードしたSP証明書がOkta側にアップロードされているか属性ステートメント（givenname・surname・name）の「名前」と「式」が一致しているかテスト実行者のOktaアカウントが、作成したアプリに割り当てられているかテストが完了したら、プロバイダー詳細画面に戻り「状態」を ON に切り替えることで、OktaによるSAMLログインが有効になります。状態をONにする前に、IdP Initiated loginを利用する場合はOkta側のアプリ設定（「サインオン」タブの「Application Username」やアサインメント）も意図どおりになっているかを再確認しておくと安全です。ログイン方法が利用できなくなった場合に備えて、ログイン方法のリカバリー設定の設定方法を事前に行っておくことを強く推奨します。設定完了後は作成したSAMLプロバイダーをログイン方法として利用する方法を参照し、ログイン方法として有効化してください。
Microsoft Entra ID
ZUNDA ID / ログイン・認証連携
daichi　2026年8月18日 03:37 更新
このページについてMicrosoft Entra ID（旧Azure AD）をIdPとして利用し、ZUNDA IDとSAML連携させるための手順を説明します。この設定を完了すると、Microsoft Entra IDにサインインしているユーザーが、その認証情報を用いてZUNDA IDへシングルサインオンでログインできるようになります。設定に必要なもの事前に以下を揃えておいてください。Microsoft Entra IDのエンタープライズアプリケーションを管理できる権限を持つユーザーエンタープライズアプリケーション管理者、アプリケーション管理者、クラウドアプリケーション管理者、またはグローバル管理者のいずれかのロールが必要です。ZUNDA IDの認証方法の管理権限を持つユーザーSAMLプロバイダーの作成と設定を行うため、ZUNDA IDの管理権限を持つユーザーが必要です。事前にリカバリーキーを発行・保管していること設定不備やIdP障害によるロックアウトを防ぐため、ログイン方法のリカバリー設定の設定方法を参照し、リカバリーキーを事前に発行してください。設定手順ZUNDA IDとMicrosoft Entra 管理センターの両方を交互に操作して設定を進めます。両方の画面を同時に開いておくとスムーズです。ZUNDA IDの「ログイン方法設定」画面を開き、「SAMLプロバイダーを追加」ボタンをクリックしてください表示されたダイアログに、このプロバイダーを識別するための任意の表示名（例：Microsoft Entra ID）を入力し、「作成」をクリックしてプロバイダー詳細画面へ進んでください。ここで付けた名前は、ログイン画面や設定画面で表示されます。Microsoft Entra 管理センター（entra.microsoft.com）にログインし、「エンタープライズアプリケーション」から「新しいアプリケーション」を作成する画面を開いてください「独自のアプリケーションの作成」をクリックして表示された画面に以下の設定をしてくださいMicrosoft EntraのアプリギャラリーにはZUNDA IDは掲載されていないため、「ギャラリー以外のアプリケーションを統合」を選択する必要があります。作成するアプリの名前ZUNDA IDアプリケーションでどのような操作を行いたいですか？ギャラリーに見つからないその他のアプリケーションを統合します（ギャラリー以外）選択したことを確認して、作成ボタンをクリックしてください。アプリケーションが作成されると詳細画面が表示されます。左メニューから「シングルサインオン」を選択し、「シングルサインオン方式の選択」画面で「SAML」をクリックしてくださいZUNDA IDのプロバイダー詳細画面に戻り、「メタデータXML（SP）」のダウンロードボタンをクリックして、SP側のメタデータXMLを保存してくださいSPメタデータには、ACS URLやエンティティIDなど、Microsoft Entra ID側で必要となるZUNDA ID（SP）の情報が含まれています。このファイルをMicrosoft Entra側へアップロードすることで、SPの設定を一括で反映させることができます。Microsoft Entra 管理センターのSAMLシングルサインオン設定画面に戻り、「メタデータファイルをアップロードする」をクリックし、先ほどダウンロードしたSPメタデータXMLファイルをアップロードしてください設定値が自動入力されていることを確認し、「保存」をクリックしてくださいメタデータファイルから「識別子」と「応答URL」が自動で入力されます。これらはそれぞれZUNDA IDのエンティティIDとACS URLに対応します。保存されたことを確認し、❌ボタンをクリックして「基本的なSAML構成」パネルを閉じてください。Microsoft Entra 管理センターの「SAMLによるシングルサインオンのセットアップ」画面をスクロールし「SAML証明書」セクションを見つけ、「フェデレーションメタデータ XML」のダウンロードリンクをクリックしてXMLファイルを保存してくださいこのフェデレーションメタデータには、Microsoft Entra IDのIdP証明書とSSO URLが含まれており、ZUNDA IDにインポートすることでIdP側の設定を一括で取り込めます。ZUNDA IDのプロバイダー詳細画面に戻り、「メタデータXMLをインポート」ボタンをクリックしてください表示されたダイアログから「ファイルから読み込む」をクリックし、先ほどダウンロードしたフェデレーションメタデータXMLファイルを選択してください。読み込まれたことを確認したら、「メタデータXMLをインポート」ボタンをクリックしてください。IdP Entity ID、SSO URL、IdP証明書などの設定値がすべてインポートされたことを確認してください。これでZUNDA ID側のSAMLプロバイダー設定は一旦完了ですが、次のステップでMicrosoft Entra ID側の属性マッピングを調整します。Microsoft Entra 管理センターに戻り、「属性とクレーム」セクションの「編集」をクリックしてくださいMicrosoft Entra IDのデフォルトでは、nameクレームにユーザーのプリンシパル名（メールアドレス形式）がセットされています。しかしZUNDA IDではこれを「表示名」として表示してしまうため、より適切なdisplayNameアトリビュートへマッピングし直します。ZUNDA IDでは表示名としてdisplayNameを利用しますが、Microsoft Entra IDの初期設定ではnameクレームにuser.userprincipalnameがマッピングされています。ユーザーの表示名を正しく取り込むために、http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameのクレームをクリックして編集画面を開いてください。編集画面で「ソース属性」をuser.userprincipalnameからuser.displaynameに変更し、「保存」をクリックしてください。一覧に戻り、nameクレームの値がuser.displaynameに変更されていることを確認したら、❌ボタンをクリックして画面を閉じてください。これでMicrosoft Entra ID側の設定はすべて完了です。SP証明書の登録必須ではありませんが、Microsoft Entra ID側にZUNDA IDのSP証明書を登録し、SAMLリクエストの署名検証を有効化することで、リクエストが確かにZUNDA IDから送信されたものであることを暗号学的に検証できるようになり、なりすましに対するセキュリティを高められます。ZUNDA IDのMicrosoft Entra IDプロバイダー詳細画面の「SP証明書」セクションより、プライマリー証明書の「ダウンロード」ボタンをクリックして、SP証明書ファイル（.cer）を保存してくださいMicrosoft Entra 管理センターのSAMLシングルサインオン設定画面に戻り、「SAML証明書」セクションまでスクロールしてください「検証証明書 (オプション)」の「編集」をクリックしてください「検証証明書」パネルが開くので、フォルダアイコンから先ほどダウンロードしたSP証明書ファイル（.cer）を選択し、「OK」をクリックしてください証明書の拇印とキーIDが一覧に表示されたことを確認したら、「検証証明書を必須とする」にチェックを入れ、「保存」をクリックして証明書の登録を完了してくださいこれでMicrosoft Entra IDは、ZUNDA IDから送信されるSAMLリクエストの署名を検証するようになります。SP証明書を差し替えた場合は、同じ手順でMicrosoft Entra ID側の検証証明書も更新してください。ログインテスト設定が完了したら、プロバイダーを有効化する前に必ずログインテストを実施して、設定が正しいか、Microsoft Entra IDユーザーの情報が正しく取り込めるかを確認してください。ZUNDA IDのMicrosoft Entra IDプロバイダー詳細画面より、「テスト」ボタンをクリックしてくださいテストボタンをクリックすると、ポップアップウィンドウでMicrosoftのログイン画面が開きます。ポップアップがブロックされている場合は、ブラウザのポップアップブロッカーを一時的に無効化してください。Microsoftで認証を完了させると、以下のように「SSOログインテストに成功しました」と表示され、NameID・メールアドレス・姓・名・表示名のチェック結果がすべて緑のチェックになっていれば設定完了ですもしエラーが表示されたり、チェック項目が赤いマークになっている場合は、以下を確認してください。フェデレーションメタデータXMLが正しくインポートされているかnameクレームのソース属性がuser.displaynameに変更されているかテストに使用したユーザーに姓名や表示名がMicrosoft Entra ID側で設定されているかテストが成功したら、プロバイダー詳細画面に戻り、「状態」をONに切り替えることで、Microsoft Entra IDによるSAMLログインが有効になります。その後、ドメイン設定でこのプロバイダーをログイン方法として選択することで、実際のユーザーがSAML認証でログインできるようになります。ログイン方法が利用できなくなった場合に備えて、ログイン方法のリカバリー設定の設定方法を事前に行っておくことを強く推奨します。設定完了後は作成したSAMLプロバイダーをログイン方法として利用する方法を参照し、ログイン方法として有効化してください。
Google Workspace
ZUNDA ID / ログイン・認証連携
daichi　2026年8月18日 03:38 更新
このページについてGoogle WorkspaceをIdPとして利用し、ZUNDA IDとSAML連携させるための手順を説明します。この設定を完了すると、Google Workspaceにサインインしているユーザーが、その認証情報を用いてZUNDA IDへシングルサインオンでログインできるようになります。設定に必要なもの事前に以下を揃えておいてください。Google Workspaceのアプリを管理できる権限を持つユーザーカスタムSAMLアプリの作成・設定を行うため、管理者権限を持つGoogleアカウントが必要です。ZUNDA IDの認証方法の管理権限を持つユーザーSAMLプロバイダーの作成と設定を行うため、ZUNDA IDの管理権限を持つユーザーが必要です。事前にリカバリーキーを発行・保管していること設定不備やIdP障害によるロックアウトを防ぐため、ログイン方法のリカバリー設定の設定方法を参照し、リカバリーキーを事前に発行してください。設定手順ZUNDA IDとGoogle Workspaceの両方を交互に操作して設定を進めます。両方の画面を同時に開いておくとスムーズです。ZUNDA IDの「ログイン方法設定」画面を開き、「SAMLプロバイダーを追加」ボタンをクリックしてください表示されたダイアログに、このプロバイダーを識別するための任意の表示名（例：Google Workspace）を入力し、「作成」をクリックしてプロバイダー詳細画面へ進んでください。ここで付けた名前は、ログイン画面や設定画面で表示されます。Google Workspaceの管理コンソールを開き、「Webとモバイルアプリ」から「カスタムSAMLアプリ」を追加してくださいGoogle Workspaceの管理コンソール（admin.google.com）にログインし、「アプリ」→「Webとモバイルアプリ」と進み、「アプリを追加」から「カスタムSAMLアプリを追加」を選択してください。アプリ名には「ZUNDA ID」などのわかりやすい名前を入力してください。この名前はGoogle Workspaceユーザーのアプリ一覧に表示されるため、ユーザーが識別しやすい名前にしてください。必要に応じてアイコンをアップロードした上で、「続行」でウィザードを進めます。Google IDプロバイダの詳細画面が表示されたら、「IdPメタデータ」をダウンロードして保存してくださいIdPメタデータには、SSO URL、エンティティID、公開鍵証明書など、ZUNDA ID側で必要となる情報がXML形式で含まれています。このファイルは後の手順でZUNDA IDにインポートするため、一時的にアクセスしやすい場所に保存しておいてください。「次へ」をクリックするとサービスプロバイダ（SP）の詳細設定画面が表示されますので、以下のパラメータを入力してくださいここで設定する値は、Google WorkspaceがZUNDA IDに対して認証レスポンスを送信する際の宛先や識別子になります。誘導されるままに設定してください。ACSのURLhttps://id.zunda.co.jp/auth/saml/acs エンティティIDhttps://id.zunda.co.jp/saml/sp 名前IDの形式EMAIL 名前IDBasic Information > Primary email「次へ」をクリックすると属性のマッピング画面が表示されますので、以下の属性を追加してくださいここで、Google Workspaceユーザーの名前・姓の情報をZUNDA ID側へ届けるためのマッピングを設定します。「ディレクトリ属性」には「First Name」・「Last Name」を、「App属性」には以下のURLを入力してください。First Namehttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname Last Namehttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname全てのマッピングを入力したら、「完了」をクリックして作成ウィザードを終了してください。アプリが作成され、この時点でGoogle Workspace側のセットアップは一旦完了となります。ZUNDA IDのプロバイダー詳細画面に戻り、「メタデータXMLをインポート」ボタンをクリックして、先ほどGoogle WorkspaceからダウンロードしたIdPメタデータXMLをインポートしてくださいIdPメタデータをインポートすることで、ZUNDA IDがGoogle Workspaceからのレスポンスを検証するために必要なSSO URL・エンティティID・IdP証明書などが一括で設定されます。表示されたダイアログで「ファイルから読み込む」をクリックし、先ほど保存したIdPメタデータXMLファイルを選択してください。ファイルが読み込まれたことを確認し、「メタデータXMLをインポート」ボタンをクリックしてください。ファイルが不正な場合はエラーが表示されますので、その場合は再度Google Workspace側でIdPメタデータをダウンロードしてやり直してください。IdP Entity ID、SSO URL、IdP証明書などの項目がすべてインポートされていることを確認してください。これでZUNDA ID側のSAMLプロバイダー設定は完了です。次のステップで、実際にログインテストを行い、設定が正しく動作するかを確認します。ログインテスト設定が完了したら、プロバイダーを有効化する前に必ずログインテストを実施して、設定が正しいか、Google Workspaceユーザーの情報が正しく取り込めるかを確認してください。ZUNDA IDのGoogle Workspaceプロバイダー詳細画面より、「テスト」ボタンをクリックしてくださいテストボタンをクリックすると、ポップアップウィンドウでGoogleのログイン画面が開きます。ポップアップがブロックされている場合は、ブラウザのポップアップブロッカーを一時的に無効化してください。Google Workspaceで認証を完了させると、「SSOログインテストに成功しました」と表示されます。NameID・メールアドレス・姓・名のチェック結果がすべて緑のチェックになっていれば設定完了ですもしエラーが表示されたり、チェック項目が赤いマークになっている場合は、以下を確認してください。IdPメタデータXMLが正しくインポートされているかGoogle Workspace側の属性マッピング（First Name / Last Name）が正しく設定されているかGoogle Workspace側のサービスプロバイダー詳細（ACSのURL、エンティティID）が正しいかテストが成功したら、プロバイダー詳細画面に戻り、「状態」をONに切り替えることで、Google WorkspaceによるSAMLログインが有効になります。その後、ドメイン設定でこのプロバイダーをログイン方法として選択することで、実際のユーザーがSAML認証でログインできるようになります。ログイン方法が利用できなくなった場合に備えて、<>ログイン方法のリカバリー設定の設定方法を事前に行っておくことを強く推奨します。設定完了後は作成したSAMLプロバイダーをログイン方法として利用する方法を参照し、ログイン方法として有効化してください。
ドメイン設定
ZUNDA ID / ログイン・認証連携
飯塚亮騎　2026年9月26日 12:09 更新
組織に設定されたドメイン毎にログイン方法を設定できます。なお、ドメインの追加・削除は権限に関わらずユーザー側の操作では操作できません。ZUNDA にて対応いたしますのでお問い合わせフォームよりご連絡ください。https://ask.zunda.co.jp/id/domain-managementこの設定の閲覧には以下の権限が必要です。[認証方法の管理] > [認証方法の閲覧]この設定を変更するには以下の権限が必要です。[認証方法の管理] > [認証方法の編集] ドメイン設定の閲覧メニューの [ドメイン設定] を押下すると組織に登録されているドメインの一覧が表示されます。詳細を確認したいドメイン名の [ ⋮ ] → [詳細を見る] をクリックすることでドメインの設定を確認できます。ドメイン設定の編集ドメイン毎にログイン方法を設定できます。画像の例では @example.com のメールアドレスでログインする際の認証方法として、Email , Google, Microsoft のいずれかを選択してください。通常、エンドユーザーの混乱を防ぐため１つのドメインに対して１つの認証方法を紐づけることを強く推奨します。なお、この画面で Google や Microsoft の認証方法が表示されない場合は、ログイン方法設定で設定が必要です。※Google, Microsoft を利用した認証は対象のドメインが対応している必要があります。詳しくは組織のシステム管理者にお問い合わせください。※また Microsoft による認証は、初回認証時にテナント毎にアプリケーションの許可が必要です。組織のシステム管理者様にて初回のアプリケーションの許可の設定をお願いいたします。ドメイン設定の編集は、一覧画面から[ ⋮ ] → [編集] か、ドメインの詳細から [編集] をクリックすると編集画面に遷移します。編集を [保存] をクリックすることで編集が適用されます。上記でチェックを入れた認証方法は、以下の画像のようにログイン画面に表示されます。ドメインの設定は以上です。ご不明な点などございましたら以下のシステムお問い合わせフォームよりお問い合わせください。https://ask.zunda.co.jp/id
フェデレーション先のメールアドレスの変更を反映する
Microsoft 365 / アカウント・認証・権限
shao　2023年3月24日 08:17 更新
Azure AD の認証を外部のIdP (例えば Google Cloud Identity) で行っている状態で、対象のユーザーに割り当てられている外部IdP のメールアドレスが変更された場合、Azure AD で保持している Immutable ID を新しいメールアドレスに手動で変更するがあります。なお UserPrincipalName (UPN) は自動的に変更が同期され、新しいメールアドレスになります。以下の操作は UserPrincipalName が同期されてから行ってください。概要Windows PowerShell を用いますユーザーを Federated ドメインからデフォルトドメイン (onmicrosoft.com) に移動します新しい ImmutableId をセットしますユーザーを Federated ドメインに移動します手順以下のシナリオを例に説明します。組織のデフォルトドメイン: consoto.onmicrosoft.comFederated ドメイン: consoto.comユーザー名 (旧): john@consoto.comユーザー名 (新): a.john@consoto.com操作手順Windows PowerShell で認証をします。このコマンドを実行すると Microsoft アカウントの認証画面が表示されますので、特権管理者権限でログインしてください。Connect-MsolService対象となるユーザーをデフォルトドメインに退避しますSet-MsolUserPrincipalName -UserPrincipalName "a.john@consoto.com" -NewUserPrincipalName "a.john@consoto.onmicrosoft.com"ユーザーに ImmutableId をセットしますSet-MsolUser -UserPrincipalName "a.john@consoto.onmicrosoft.com" -ImmutableId "a.john@consoto.com"対象となるユーザーを元のドメインに戻しますSet-MsolUserPrincipalName -UserPrincipalName "a.john@consoto.onmicrosoft.com" -NewUserPrincipalName "a.john@consoto.com"ヒントユーザーの情報は以下のコマンドで表示できます。随時確認しながら進めてください。Get-MsolUser -UserPrincipalName "a.john@consoto.com" | Select *
作成したSAMLプロバイダーをログイン方法として利用する方法
ZUNDA ID / ログイン・認証連携
daichi　2026年5月27日 03:57 更新
このページについてこのページでは、作成したSAMLプロバイダーを実際のログイン方法として有効化する手順を説明します。SAMLプロバイダーの作成とログインテストが成功していることを前提としています。ZUNDA IDでは、ドメイン単位でログイン方法を紐づけることができます。たとえば、@example.comのドメインに属するユーザーにはSAML認証だけを許可する、というように設定できます。この設定を行う前に、必ずログイン方法のリカバリー設定の設定方法を完了させてください。リカバリーキーなしで設定を進めると、万が一設定不備があった際にロックアウトされるリスクがあります。設定手順作成したSAMLプロバイダーの詳細画面を開き、「状態」をONに切り替えてプロバイダーを有効化してください状態がONの場合のみ、そのプロバイダーをログイン方法として選択できるようになります。テストが未実施のプロバイダーは、先に詳細画面の「テスト」ボタンからログインテストを実施し、成功を確認してから有効化してください。「ドメイン設定」画面を開き、ログイン方法を紐づけたいドメインを選択してくださいZUNDA IDでは、ドメインごとに利用可能なログイン方法を個別に設定します。複数のドメインを利用している場合は、SAML認証を適用したいドメインをそれぞれ選択して設定を行ってください。ドメイン詳細設定画面で、このドメインのユーザーに許可するログイン方法を選択してください作成したSAMLプロバイダーにチェックを入れることで、そのドメインのユーザーがSAML認証でログインできるようになります。複数のログイン方法（例：SAML認証とGoogle認証）を同時に許可することもできます。セキュリティ・ポリシー上、特定の認証方法のみに限定したい場合は、他のログイン方法のチェックを外してください。動作確認「保存」ボタンをクリックしたら、実際にそのドメインに属するユーザーでログインできるかを確認してください。別のブラウザまたはシークレットウィンドウでZUNDA IDのログイン画面を開き、設定したSAML認証でログインできることを確認して作業は完了です。動作確認は、現在ログイン中の管理者セッションとは独立したセッションで行うことを推奨します。万が一設定不備があったとしても、現在の管理者セッションは保たれたままになり、迫加して設定を修正できるためです。