Claude Ping Identity SSO設定 — PingOneのSAMLとSCIM手順
PingOneでClaudeのSAML SSOとSCIMを設定する手順と、PingFederateの考え方、メール属性をそろえる理由を手順でまとめます。
PingOneをIDプロバイダー(IdP)にしてClaudeのSSOを設定するには、PingOne側でSAMLアプリケーションを作り、Claudeの管理画面が表示するACS URLとEntity IDを手入力します。PingOneのIdPメタデータをダウンロードしてClaude側へ渡し、最後にメール属性を対応づければSAMLは完了です。
SCIMによる自動プロビジョニングは、この上に載せる別の工程です。使えるのはEnterpriseプランと条件を満たすConsole組織だけで、Teamプランで使えるのはJIT(初回ログイン時の自動追加)までです。
PingFederateを使っている組織には、PingOneのようなクリック単位の手順はありません。Claudeのヘルプにあるのは考え方の概略だけです。この記事では、PingOneの手順を中心に、PingFederateでどこまで言えるかも切り分けます。
前提条件と、先に開いておく画面
用意するものは4つです。
- Claude Team・Enterprise、またはConsole組織(Consoleは親組織が必要)
- ClaudeでのOwnerまたはPrimary Owner権限(Team・Enterprise)、またはAdmin権限(Console)
- PingOneのEnvironment Admin、またはPingFederateのAdmin権限
- Claudeの管理設定でドメイン検証が済んでいること
ドメイン検証とSSO設定フロー全体はClaudeのSSO設定手順で扱っています。検証が終わっていない場合は、先にそちらを済ませます。
ACS URL・Entity ID・SCIMの認証情報は、サポートに問い合わせて受け取る値ではありません。Claude側のセットアップフロー(WorkOSの画面)に表示されます。
- TeamとEnterprise:
claude.ai/admin-settings/identity - Console組織:
platform.claude.com/settings/identity
Pingの手順ページはこの2つのURLを案内しています。一方、SSO設定の総合ガイドは同じ設定画面を「Organization and access」と呼び、Teamの例では claude.ai/admin-settings/organization を挙げています。画面名やURLが手元と違って見えるときは、管理設定のIdentity and access(Organization and access)に入り、Authenticationセクションの「Setup SSO」(設定済みなら「Manage SSO」)を探します。
セットアップフローを開始したら閉じずに残し、Pingの管理コンソールと並べて作業します。値の取り直しが減ります。
PingOneでSAML接続を作る
PingOneでは、SAMLの接続を作ってから、SCIMとユーザーの割り当てに進みます。まずSAMLから設定します。
PingOneのSAML設定
- 1
アプリケーション接続を作る
PingOne管理コンソールで「Connections → Applications → + Add Application」を開き、「SAML Application」を選びます。名前を「Claude」にして「Configure」を押します。
- 2
SP情報を手入力する
設定方法は「Manually Enter」を選びます。Claude側のセットアップフローに表示されたACS URLとEntity IDを入力します。
- 3
IdPメタデータをClaudeに渡す
PingOneのIdPメタデータをダウンロードし、Claude側のセットアップフローで求められたときにアップロードします。
- 4
メールの属性を対応づける
「Attribute Mappings」で、
emailをPingOneの「Email Address」属性にマッピングします。
「Manually Enter」を選ぶ点が、メタデータXMLを読み込ませる方式と違うところです。ClaudeからPingOneへはACS URLとEntity IDの2つを文字列で渡し、PingOneからClaudeへはメタデータファイルで返す、という往復になります。
ここで最後に置いた属性マッピングが、後で効いてきます。SAMLの email に何を割り当てたかを、次のSCIM設定でもう一度使うからです。
PingOneでSCIMを有効にする
SCIMはEnterpriseプランと、対象のConsole組織だけが使えます。Teamプランの場合はこの工程を飛ばし、JITで進めます。JITとSCIMのどちらを選ぶかの比較はJIT/SCIMプロビジョニングの設定手順にあります。
PingOneのSCIM設定と割り当て
- 1
プロビジョニングを有効にする
アプリケーション設定の「Provisioning」タブを開き、「Outbound Provisioning」を有効にします。Claude側のセットアップフローに表示されたSCIMエンドポイントURLとアクセストークンを入力します。
- 2
SCIMのメール属性を合わせる
emails[primary].valueを、PingOneの「Email Address」属性にマッピングします。SAMLで使った属性と同じものです。 - 3
ユーザー集団を割り当てる
「Populations」で、Claudeを使わせるユーザー集団(population)を割り当てます。
- 4
有効化して保存する
アプリケーションを有効にして「Save」を押します。
一連の流れでPingOne固有なのは、ユーザーの割り当てが「Populations」で行われる点です。他のIdPでよくあるグループ割り当てではなく、PingOneのユーザー集団を単位にします。
なぜSAMLとSCIMで同じ属性を使うのか
Pingの手順ページは、SCIMの項に「SAMLとSCIMは同一の属性ソースを使うこと」という注意を置いています。理由は、ClaudeがメールアドレスをプライマリIDとして、SSOログインとプロビジョニング済みの席を突き合わせるためです。SCIMで届いたメールと、SAMLのアサーションで届いたメールが、1文字でも違えばログインは通りません。
Pingの製品は属性の設定が多層になっています。ディレクトリ、IdPアダプタ、SPコネクタ、アプリケーションの各層でマッピングでき、SCIMとSAMLが別々の経路を通ってしまう余地があります。
メールが食い違うときの典型例
PingOneのusername
testuser1 のような短い名前や、メール形式でない値が入っていることがあります。SCIM側のマッピングがこの属性を指していると、SAML側の「Email Address」と一致しません。
LDAPのsAMAccountNameやuid
社員番号や短い識別子が入っていることがあります。メールの代わりに誤って割り当てると、同じ食い違いになります。ディレクトリのmail属性に合わせます。
食い違った状態で運用を始めると、症状が複数の形で出ます。
- 「Account creation is blocked」と表示され、一致する席が見つからない
- 組織の作成が制限されていない場合、利用者が個人の無料アカウントに入ってしまう
- SSOのコールバックで、入力したメールと違うアドレスが表示される
- Claude Codeの認証フローでメール不一致のエラーが出る
診断と修復の手順はClaudeのSSO/SCIMメール不一致の直し方に詳しくあります。ここでは、Ping特有の直し方だけ押さえておきます。
マッピングを直したあとは、全件の再同期が必要です。差分同期では既存の記録は更新されません。PingOneでは、プロビジョニングを一度無効にして有効に戻し、全件を再送させる必要が出ることがあります。再送後は、プロビジョニングログのメールがSSOで送られる形式と一致しているかを見てから、利用者にログインし直してもらいます。
PingFederateの場合
PingFederateは、バージョンや構成によって画面が大きく変わります。ヘルプにあるのは次の4点の概略です。
- Claude側のセットアップフローにあるSPメタデータで、新しいSP Connectionを作る
- Attribute Contractに
emailを含める - Adapter Mappingで、
emailを利用者のプライマリメールのフィールドに対応づける - SCIMを使う場合(Enterpriseと対象のConsole組織のみ)は、セットアップフローのSCIMエンドポイントに向けたアウトバウンドのプロビジョニングチャネルを設定する
PingFederate固有の細かい手順は同ページに書かれておらず、Supportへの問い合わせが案内されています。
もう一つの難所は、メールが通る層の数です。LDAPからIdPアダプタ、アダプタ契約、SPコネクタ、アサーションと、メールは複数の層を通ります。どこか1層でも別の属性を参照していれば、誤った値がClaudeに届きます。
診断のコツは、2つの経路を別々にたどることです。
- SSO側: SP Connectionの「Attribute Contract Fulfillment」で、メールの取得元をLDAPやアダプタまでさかのぼる
- SCIM側: Claude向けのアウトバウンドプロビジョニングチャネルで、送出されるメールの取得元をたどる
- 両方が同じディレクトリ属性(多くはLDAPの
mail)に行き着くか、突き合わせる
SP Connectionの契約を直しても、SCIMのチャネルは自動では直りません。2つは別々に更新する必要があります。
動作確認
設定が終わったら、次の順で確かめます。
- Claude側のセットアップフローの最後にある「Test Single Sign-on」で、エラーなくログインできるか見る
- Enterpriseの場合は、PingOneで割り当てたユーザー集団が、Claudeのメンバー一覧またはDirectoryに現れているか見る
- テスト用アカウントで、claude.aiのSSOログインを試す。ブラウザのCookieが残っていると古い状態を引きずるので、claude.aiのCookieを消してから試す
- Claude Codeを使う利用者がいれば、
claude auth login --enterpriseを実行し、メールが席のメールと一致するか確かめる
Claude Codeでメール不一致が起きていた場合は、再認証で席のメールと一致するかを見ます。
claude auth login --enterprise不一致を直したあとの片づけ
マッピングを直しても、すでに作られたアカウントは自動では消えません。ヘルプには次の後始末が挙がっています。
- 組織の作成を制限していなかった間に、個人の無料アカウントを作ってしまった利用者がいる場合は、Supportに削除を依頼する
- 誤ったメールで作られた席(幽霊アカウント)は、Supportにプロビジョニング解除を依頼する
- 幽霊アカウントが契約席を使い切っていると、新しいログインは失敗する。この場合もSupportへ
- 幽霊アカウントの削除後、利用者の再招待や再プロビジョニングが要ることがある
再発の防止策は、ドメイン検証後に現れる「Restrict organization creation」です。SecurityセクションのトグルをオンにするとClaude・Consoleの新規組織の作成(個人アカウントを含む)を、検証済みドメインで止められます。
つまずきの早見表
| 症状 | 見直す箇所 |
|---|---|
| ログイン後に「Account creation is blocked」 | 見直す箇所SCIMとSAMLのメール属性が同じPingOne属性を指しているか |
| メールは直したのに席に入れない | 見直す箇所全件の再同期を実行したか。幽霊アカウントや個人の無料アカウントが残っていないか |
| PingFederateで直したのに再発する | 見直す箇所SP ConnectionとSCIMのチャネルを別々に更新したか |
| SCIMの項目が見当たらない | 見直す箇所プランがTeamではないか。Teamの場合はJITで進める |
| Teamでユーザーを外したい | 見直す箇所JITはメンバーを自動で外さない。Claudeで手動削除し、PingOneでも割り当てを外す |
最後の行は、JITの動きによるものです。PingOneでユーザー集団の割り当てを外すとログインはできなくなりますが、メンバー一覧と席はそのまま残ります。Claudeだけで削除した場合は、次にSSOでログインするとまた追加されます。
まとめ
PingOneの設定は、SAMLアプリの作成、メタデータの往復、メール属性の対応づけ、Enterpriseならさらにアウトバウンドプロビジョニングという流れで進みます。つまずきの大半は、メールの取得元がSAMLとSCIMで一致していないことから始まります。SCIMを足す前に、SAMLで選んだ属性を控えておくと、後の診断が速くなります。
PingFederateは、概略より先の手順をSupportと詰める前提で構えておくと安全です。IdPの選定段階ならClaudeのSSO設定、IdPはOkta・Google Workspace・Entra IDのどれかが判断材料になります。他のIdPとの手順の違いはClaude Okta SSO設定やClaude OneLogin SSO設定と見比べられます。