Claudeで複数IDプロバイダーをつなぐ — ドメイン分割と削除時の挙動

統括組織(parent organization)に、複数のIDプロバイダーを接続できるようになりました。しかも1つのドメインを、複数のIDプロバイダーに振り分けられます。ベータ提供で、対象は統括組織が集中管理(centralized management)に登録済みのEnterpriseプランとClaude Platformです。

これまでSSOは「1つの組織に1つのIdP」という前提で語られがちでした。買収した会社が別のIdPを使い続ける、IdPを段階的に乗り換える、といった場面で、この前提が足かせになっていました。ここでは、設定の流れ、サインイン画面の見え方、IdPを消したときに起きることを順に追います。

要点

要点

今回の変更で押さえる4点

• IdPは複数つなげられる

  IdPは、IDサービス上のSSOアプリ1つを指します。同じテナント内のSSOアプリ2つは、2つのIdPです。各IdPにはディレクトリ(SCIMで同期するユーザーとグループ)を最大1つ持たせられます。

• 1つのドメインを複数のIdPに分けられる

  split domainsと呼ばれる機能です。変わるのはサインインだけで、データの分離や、どの配下組織に入るかは決まりません。

• 誰にIdPを見せるかを選べる

  IdPごとに「SCIMディレクトリにいる人だけ」や「サインイン画面に出さない」を設定できます。

• IdPの削除は影響が大きい

  最後のSSOを失うと全ドメインのRequire SSOが外れます。最後のディレクトリを失うと、ディレクトリ同期を使っていた配下組織は招待制に切り替わります。

集中管理の登録手順そのものは、統括組織を管理コンソールに登録する手順の記事で扱っています。この機能は、登録後のコンソールで使うものです。

どんなときに複数のIdPを使うか

ヘルプセンターは、架空の企業Northwind Tradersを例に3つの使い方を挙げています。

3つ目は、既存のIdP切り替え手順(IdP切り替えとSSOリセットの7手順)と違い、旧IdPを残したまま新旧が併存する期間を作れる点が新しいところです。

IdPを追加してドメインにつなぐ手順

設定は統括組織のコンソールで行います。IdPの管理とドメインの管理は、統括組織のOwnerと管理者の担当です。配下組織の管理者は、自組織のグループとロールの対応づけを担当します。

手順

IdPの追加からロール対応づけまで

1. 1

   IdPに名前を付ける

   Identity providersタブで「Add identity provider」を選び、ユーザーが見て分かる名前を付けます。例は「Microsoft Entra」や「SubsidiaryCo Okta」です。

2. 2

   SSOとディレクトリ同期をつなぐ

   追加したIdPを開いて「Configure SSO」を選び、セットアップポータルでSAMLまたはOIDCのアプリを接続します。ディレクトリ同期を使うなら「Set up directory sync」でSCIMも接続します。

3. 3

   ドメインにIdPを割り当てる

   Domainsページで、必要ならドメインを検証します。SSO sign-in at列の鉛筆アイコンから、いま使っているIdPを外し、新しいIdPを選んで「Save」します。保存した瞬間に、そのドメイン全員のサインインが変わります。

4. 4

   Require SSOを設定する

   ドメインごとに、Require SSO for ClaudeとRequire SSO for Consoleを必要に応じて有効にします。SSOを必須にしたのにIdPが割り当たっていないドメインでは、ユーザーがサインインできなくなります。

5. 5

   配下組織でグループとロールを対応づける

   各配下組織の管理設定にあるUser provisioningで、SCIMディレクトリ同期かJIT(just-in-time)プロビジョニングを選び、Enable group mappingsを有効にします。ロールの「+」からグループを選び、どのIdP由来のグループかも指定します。Claude Enterpriseだけが使える席の種別の対応づけも、同じ操作です。

IdP名はサインイン画面に出ることがあります。ドメインのユーザーが2つ以上のIdPから選べるとき、ドメインを知っている人なら、アカウントがなくても名前を見られます。社内の呼称や取引先名を含めるかは、この前提で決める必要があります。

SSOアプリの作り方は、IdPごとの記事(Okta、Microsoft Entra ID)にあります。

ユーザーとグループはどう扱われるか

人はメールアドレスで識別されます。同じメールアドレスが2つのディレクトリにあれば、同じ1人です。

その人には、ロールの対応表に一致したロールのうち最も高いものが付きます。どちらのディレクトリが与えたロールかは問われません。片方のディレクトリから外れても、もう片方が付与しているロールは消えません。

JITプロビジョニングでは話が変わります。ロールは、最後にサインインに使ったIdPの対応づけから決まります。SCIMとJITの考え方は、SCIMとJITの違いの記事にあります。

見落としやすいのはグループの可視性です。グループの可用性機能がまだ使えない間は、Enterpriseの配下組織の管理者全員が、統括組織の下のすべてのIdPから同期されたグループを見られます。テスト用IdPのグループも含まれます。

1つのドメインを複数のIdPに分ける(split domains)

split domainsは、検証済みドメイン1つに複数のIdPを割り当てる機能です。サインイン画面で誰にどのIdPを見せるかも選べます。

ヘルプセンターの使い方の例は2つです。

• 1つのドメインで2つのリージョン: northwind.comを全員が使い、米国の社員はOkta、欧州の社員はMicrosoft Entraでサインインする。各IdPを「Only people in its SCIM directory」にすれば、自分のIdPだけが見える
• 本番前のIdP検証: 新しいIdPをnorthwind.comに「Hidden at sign-in」で足し、IdPのアプリダッシュボードのタイルからテストする。問題なければ表示に切り替え、旧IdPを外す

始める前の条件

条件は2つあります。統括組織の下にあるすべての組織が、SCIMディレクトリ同期か招待制のプロビジョニングを使っていること。そして、そのドメインでMicrosoft Loginがオフであることです。JITを使う組織が1つでもあるか、Microsoft Loginがオンのままだと、ドメインに2つ目のIdPは割り当てられません。Microsoft Loginを切る操作や、JITのままsplit domainsを使いたい相談は、アカウント担当への連絡が案内されています。

サインイン画面の見え方

2つ以上のIdPが提示される人には、メールアドレスの入力後に「Choose your identity provider」が出ます。IdPごとにボタンが並び、ラベルは設定した名前です。claude.ai、platform.claude.com、admin.claude.comで共通です。Claude DesktopとClaude Mobileも同じ選択画面です。提示されるIdPが1つだけの人は、そのまま遷移します。

誰にIdPを見せるかを決める2つの設定

IdPのページのSingle sign-onに、2つの設定があります。

「Only people in its SCIM directory」には例外と注意があります。

• 統括組織のOwnerと、各配下組織のプライマリオーナーは、ロックアウトを防ぐためディレクトリになくても使える。統括組織の管理者は例外にならない
• Claudeに登録したメールアドレスが、ディレクトリのものと一致している必要がある。大文字小文字は区別されないが、jane.doe@に対するj.doe@のような別名は一致しない
• ディレクトリにない人には、メールアドレスを入力してもIdPが出ない。ただしIdPのタイルや、Claude Desktopのワンクリックサインイン(MDM設定のloginSsoOrgDomainで指定)からは到達できる。ワンクリックの経路はディレクトリを確認しない。到達した人は、サインイン後に「Access managed by your organization」というページで拒否される
• サインインで特定のIdPを1つ名指しする設定が必要なときは、アカウント担当へ依頼します

Hidden at sign-inは、選んだ瞬間にすべてのサインイン画面から外れます。タイルから入った人には、Claudeがメールアドレスの確認を求めます。

ドメインを分けるときの注意点

もう1つの注意は情報の漏れ方です。「Only people in its SCIM directory」を有効にすると、サインイン画面にメールアドレスを入れるだけで、それがディレクトリの所属者かどうかを誰でも判別できます。社外の人でも、特定のアドレスがそのディレクトリに登録されているかを確かめられます。

JITとの関係もあります。ドメインに複数のIdPがある間は、組織がJITへ切り替えることも、JITを有効にしたまま統括組織へ参加することもできません。

IdPを削除する、SSOをオフにする

削除は、他の設定へ連鎖します。

IdPを削除すると、そのドメインへの振り分けとグループからロールへの対応づけが消え、ディレクトリは切断されます。ドメインのRequire SSOは、削除したIdPが最後のSSO接続済みIdPでない限り残ります。そのディレクトリだけを経由して所属していたユーザーは、残っているディレクトリの次回同期で外れます。

SSOが必須で、ほかにSSOが設定されたIdPがないドメインのユーザーは、別のIdPへ振り分け直すまでサインインできません。

セットアップポータルでIdPのSSOをオフにした場合は、動きが異なります。そのIdPに振り分けられていて、SSOが設定されたほかのIdPには振り分けられていないドメインでは、Require SSOが自動でオフになり、ユーザーはSSOなしでサインインできる状態になります。

最後の接続済みSSOまたはディレクトリを失うと、影響は組織全体に及びます。最後のSSOを失ったときは、JITプロビジョニングを使っていた組織も切り替わります。

後からディレクトリをつなぎ直しても、プロビジョニングの方式は自動では戻りません。配下組織の管理者が、SCIMディレクトリ同期かJITを選び直す必要があります。

統括組織唯一のIdPは削除できません。代わりにそのSSOまたはディレクトリ同期をオフにできます。

背景: 統括組織がIdPの置き場になった流れ

集中管理の登録を扱った記事で触れたとおり、登録後はSSO、ディレクトリ同期、ドメイン検証が配下組織から統括組織のコンソールへ移ります。今回の機能は、その移った先で複数のIdPを受けられるようにするものです。

ドメインを組織へ引き取る流れも、同じ統括組織側にあります。ユーザーに通知が届いたときの選択肢は、ドメインキャプチャ通知への対応の記事にあります。

高いロールが勝つ設計で、旧ディレクトリも棚卸しの対象になる

メールで人を同定し、複数のディレクトリのうち最も高いロールを採るという仕様には、運用上の含みがあります。IdPを統合したときに、古いディレクトリに残った高権限グループがそのまま効き続けるからです。段階移行では、旧IdPを消すまで、旧ディレクトリ側のグループ割り当ても棚卸しの対象になります。

もう1つはテスト用IdPです。グループの可用性が使えない間、テスト用IdPのグループもEnterpriseの配下組織の管理者に見えます。検証用のグループ名に、本番の組織構造を推測できる語を入れないほうが安全です。

ヘルプセンターの手順には、この棚卸しは含まれていません。

まとめ

• 買収先のIdPを残したい会社、IdPを段階的に移したい会社には、新旧を並べてつなげる構成が現実的な選択肢になりました
• 1つのドメインを複数のIdPに分けるには、JITの組織がなく、Microsoft Loginがオフであることが前提です
• IdPの削除とSSOのオフは別の操作で、最後のSSOを失うと全ドメインのRequire SSOが外れます
• 事前の条件確認は、SSOとSCIMの導入前に確認する3点と、JITとSCIMのプロビジョニング設定が参考になります