複数の Salesforce 組織で Experience Cloud サイトを運用していると、次のような要望が出てきます。

ユーザーが複数の Experience Cloud サイトを利用するため、1 回のログインで各サイトへアクセスできるようにしたい

この場合、考えるべきポイントは データ連携ではなく認証連携 です。

ユーザーが複数のサイトを使うからといって、Salesforce 組織間でデータ共有を設定すれば解決するわけではありません。必要なのは、ユーザーがどこで認証され、その認証結果を各 Experience Cloud サイトがどう信頼するか、というログイン設計です。

この記事では、複数の Experience Cloud 組織に対するログイン設定として、推奨される考え方と避けたい構成を整理します。

① 要望

前提は次のような構成です。

項目	内容
利用者	一部の外部ユーザーが複数の Experience Cloud サイトを利用する
Salesforce構成	複数の Salesforce 組織、または複数の Experience Cloud サイトが存在する
やりたいこと	1 回のログインで複数サイトへシームレスにアクセスできるようにしたい
方針	カスタム開発はできるだけ最小限にしたい

この要望に対しては、Salesforce の標準機能である SSO を使うのが基本です。

具体的には、次のどちらかを検討します。

SAML SSO を使って複数の Experience Cloud サイト間でログインを連携する
外部 ID プロバイダーを使って認証を一元化する

どちらも、ユーザーの認証結果を各 Experience Cloud サイトが信頼する構成です。

② 推奨設定

SAML SSO を使って複数サイト間でログインを連携する

Salesforce 公式ヘルプでは、複数の Salesforce 組織または Experience Cloud サイトを利用している場合、SAML SSO を設定してユーザーが組織やサイト間を移動しやすくする構成が説明されています。

この構成では、1 つの組織またはサイトが ID プロバイダー、他の組織またはサイトがサービスプロバイダーとして動作します。

IdP
  |
  | SAML Assertion
  v
Experience Cloud Site A
Experience Cloud Site B
Experience Cloud Site C

ユーザーは ID プロバイダー側で認証され、その認証結果を各 Experience Cloud サイトが受け取ります。

そのため、サイトごとに個別ログインを求めるのではなく、SSO によって複数サイトへのアクセスを連携できます。

実装時の主な設定は次のとおりです。

設定対象	主な設定内容
IDプロバイダー側	証明書、SAML メタデータ、接続アプリケーションまたは外部クライアントアプリケーション
サービスプロバイダー側	SAML Single Sign-On 設定、Entity ID、ACS URL、認証サービスの有効化
ユーザー識別	Federation ID やユーザー名など、各組織で同一ユーザーを紐づけるキー
ログイン画面	Experience Cloud サイトのログインページに SSO 認証サービスを追加

ポイントは、各 Experience Cloud サイトを単独のログイン先として考えるのではなく、SSO のサービスプロバイダーとして扱うことです。

外部 ID プロバイダーを使って認証を一元化する

企業として Microsoft Entra ID、Okta、Auth0 などの外部 ID プロバイダーを利用している場合は、外部 ID プロバイダーに認証を集約する構成が扱いやすいです。

この場合、各 Experience Cloud サイトはサービスプロバイダーとして構成し、ユーザー認証は外部 ID プロバイダーに任せます。

External IdP
  |
  | SAML / OpenID Connect
  v
Experience Cloud Site A
Experience Cloud Site B
Experience Cloud Site C

この構成のメリットは、認証ポリシーを Salesforce 組織ごとに分散させないことです。

たとえば、次のような管理を外部 ID プロバイダー側に寄せられます。

管理対象	外部IDプロバイダー側で管理しやすい内容
認証方式	パスワードポリシー、MFA、条件付きアクセス
ユーザーライフサイクル	入社、退職、取引終了、アカウント無効化
アクセス制御	グループ、属性、アプリ割り当て
監査	認証ログ、アクセスログ、サインインリスク

複数の Salesforce 組織や Experience Cloud サイトをまたぐ場合、認証の起点を外部 ID プロバイダーに集約すると、運用責任が明確になります。

どちらを選ぶべきか

実務では、次のように考えると整理しやすいです。

状況	推奨構成
既に企業標準の IdP がある	外部 ID プロバイダーを IdP とし、各 Experience Cloud サイトを SP にする
Salesforce 組織またはサイトを認証の起点にしたい	SAML SSO で 1 つの組織またはサイトを IdP、他を SP にする
将来的に Salesforce 以外のアプリも含めて認証統制したい	外部 ID プロバイダーに寄せる
Salesforce 組織間・サイト間だけの連携に閉じている	SAML SSO による組織間・サイト間連携を検討する

カスタム開発を最小限にするなら、まず標準の SAML SSO または認証プロバイダー設定で実現できるかを確認します。

③ 実装イメージ図

図にする場合は、次の要素を入れると分かりやすいです。

要素	表現する内容
ユーザー	複数の Experience Cloud サイトを利用する外部ユーザー
IdP	外部 ID プロバイダー、または認証ハブとなる Salesforce 組織／サイト
SP	各 Salesforce 組織の Experience Cloud サイト
矢印	SAML または OpenID Connect による認証連携
補足	各組織にユーザー、ライセンス、権限セット、プロファイルが必要であること

④ 推奨されない設定

Salesforce間でデータ共有を設定する

複数の Experience Cloud サイトにログインしたいという要望に対して、Salesforce 組織間のデータ共有を先に考えるのは適切ではありません。

データ共有は、レコードや業務データをどう連携するかの話です。

一方で、今回の要望はログインをどう連携するかの話です。

データ共有 = レコードをどう見せるか
SSO = ユーザーをどう認証するか

この 2 つは目的が異なります。

組織間データ連携を入れても、ユーザーが複数サイトへ 1 回のログインでアクセスできるようになるわけではありません。

Salesforceを認証専用ハブとして新設する

Salesforce を ID プロバイダーとして利用すること自体は可能です。

ただし、複数の Experience Cloud サイトのためだけに、認証専用の Salesforce 組織を新しく用意する構成は慎重に検討する必要があります。

理由は、認証専用ハブとなる Salesforce 組織にも、次のような運用が発生するためです。

観点	発生する運用
ユーザー管理	認証用ユーザーの作成、無効化、属性管理
ライセンス	認証ハブ側のユーザーライセンスや契約確認
セキュリティ	MFA、パスワードポリシー、証明書更新
保守	接続アプリケーション、証明書、SAML メタデータの管理
障害影響	認証ハブ停止時に複数サイトへ影響する

企業標準の外部 ID プロバイダーが既にある場合は、Salesforce 組織を認証専用ハブにするよりも、外部 ID プロバイダーへ認証を集約するほうが自然です。

ただし、既存の Salesforce 組織または Experience Cloud サイトを IdP として使う明確な理由がある場合は、Salesforce 標準の SAML SSO 構成として検討できます。

⑤ まとめ

複数の Experience Cloud 組織に対して 1 回のログインでアクセスしたい場合は、データ連携ではなく SSO を検討します。

推奨される考え方は次のとおりです。

要望	推奨設定
複数の Experience Cloud サイト間でログインを連携したい	SAML SSO を使う
認証を企業全体で統制したい	外部 ID プロバイダーを使う
カスタム開発を最小限にしたい	Salesforce 標準の SSO 設定、認証プロバイダー設定を使う
Salesforce以外のアプリも含めて認証管理したい	外部 ID プロバイダーに集約する

一方で、次の構成は今回の要望に対する直接的な解決策ではありません。

設定	推奨しない理由
Salesforce間でデータ共有を設定する	ログイン連携ではなくデータ連携の話であるため
Salesforceを認証専用ハブとして新設する	ライセンス、ユーザー管理、証明書管理、障害影響の運用負荷が増えるため

最終的には、次のように判断すると分かりやすいです。

ログインを統一したいなら SSO
認証を企業全体で統制したいなら外部 IdP
データを連携したいなら別途データ連携を検討

複数の Experience Cloud サイトをまたぐログイン設計では、まず 誰が IdP になり、どの Experience Cloud サイトが SP になるのか を整理することが重要です。

参考リンク