複数の 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 になるのか を整理することが重要です。