Salesforce SAML in Action
1.1K Views
December 16, 25
スライド概要
「急にSalesforceのSSO導入を任された！」そんな時に役立つ、SAMLによるSSO(シングルサインオン)の基礎から実践までを解説した資料です。単なる設定手順の羅列ではなく、導入後の運用を見据えた設計にも重点を置いています。
ユーザーIDの統合設計、証明書の更新管理、導入先のIdP担当者との調整ノウハウなど、実務でつまづきやすいポイントをカバー。着実にSSOプロジェクトを推進するための実践的アプローチをまとめました。
クラウド間連携系プロダクトマネージャー／アーキテクト。日本ITストラテジスト協会正会員(関東支部) 。情報処理安全確保支援士。 現在は Salesforce とマネーフォワードクラウドを繋ぐプロダクトとビジネスを育てています。 提示内容は個人の見解につき所属組織を代表するものではありません。
（ダウンロード不可）
関連スライド
Meta XR SDK(V66-74)でQuestアプリを開発
あうぜん
1.2M
各ページのテキスト
Salesforce SAML in Action 急に「SSOやって」と言われても大丈夫! SAMLによるSalesforce SSOの基礎と実践 2025.12.15 堀越 悠久史
自己紹介 堀越 悠久史 (ホリコシ ユウジ) https://www.salesforce.com/trailblazer/yuji-horikoshi X: https://x.com/yuji_horikoshi Salesforce歴8年目。x14 Salesforce Certifications. Salesforce認定システムアーキテクト Salesforce認定アプリケーションアーキテクト etc. SIer(電通総研)でSalesforce案件の導入とかを 7年ちょい、 2025年7月からはマネーフォワードに転職して AppExchangeを育て始めました。 ITストラテジスト・情報処理安全確保支援士。 湘南エリア住み。 Salesforce Architects Meetup Tokyo
Agenda 1 はじめに 2 SSO/SAMLの基礎 3 SalesforceのSSO導入設計 4 設定と導入の流れ 5 実践と「あるある」 Salesforce Architects Meetup Tokyo
01 Salesforce Architects Meetup Tokyo はじめに
狙いと前提 運用を見据えたSSO導入を着実にやるアプローチ • 狙い: SalesforceのSSO導入をちゃんとやるための 実践的アプローチ → 特に、相手先 IdPとの調整に向けた運用設計と計画が重要だったり • 前提: SalesforceがSP。相手先IdP(IDaaS含む)との連携を想定 • 対象外 : 証明書関連の知識や、具体的な設定操作（ Trailhead参照） Salesforce Architects Meetup Tokyo
02 SSO/SAMLの基礎 Salesforce Architects Meetup Tokyo
SSOのイメージ 信頼関係に基づく認証の委譲 • イメージ : 信頼している人からの「この人って ○○っていう人なんだけど良くしてやってよ」という 紹介プロトコル • メリット : サービスごとの認証をスキップし、煩雑 さを回避: シングルサインオン • 仕組み : SP、IdP（IDaaS）、認証クレーム、 開始フロー(IdP起点、SP起点)、証明書 SAMLは社長(＝組織)の一存による信頼なのでこのイメージ Salesforce Architects Meetup Tokyo
SAMLとソーシャルログインの違い SAML: Security Assertion Markup Language 企業向けSSO (SAML) • 組織の統制下 : IdP側でユーザーの SP利用可否を制御 • 主に業務アプリ : 社内システム連携が主 • ジャストインタイムのユーザープロビジョニング は任意(あまりやらないと思う ) ソーシャルログイン (OIDC) • 個人の所有 : ユーザー自身がアカウント管理。身分証明書の イメージ • 主にコンシューマ向け : GoogleやXアカウントで利用可能だし、 SPは個人情報の保有を最小限にとどめられる • ユーザープロビジョニングとセット Salesforce Architects Meetup Tokyo
IdPの例 • Entra ID (旧 Azure AD): Microsoft のいわゆる ActiveDirectory のクラウド版 • Okta : IDaaSとして、ID管理とSSOの専用サービスとして有名 • HENNGE One : 同上 • Google Workspace • Salesforce : IdPにもSPにもなれる ※他にもいっぱいあるはず Salesforce Architects Meetup Tokyo
開始フロー IdP起点か、SP起点か IdP起点 (IdP-initiated) ● ● ● ● ポータル(IdP)から利用アプリ (SP)を選択し てSPへ画面遷移 IdP側で作られた認証情報 (認証クレーム ) を、SP側で検証 ○ 検証にはIdP証明書が利用される 基本動作はこちら IdP証明書 ○ IdPが発行、SPで保持 Salesforce Architects Meetup Tokyo SP起点 (SP-initiated) ● ● ● SPのログイン画面や直リンクから開始 ○ 未ログインなら IdPへ遷移して認証 ○ 認証以降はIdP起点と同じ IdPへ画面遷移して認証要求する際、「要 求署名」の検証が行われる場合あり ○ 検証には、要求署名証明書 が利用 要求署名証明書 ○ SPが発行、IdPで保持
03 SalesforceのSSO導入設計 Salesforce Architects Meetup Tokyo
ユーザー識別の管理設計 キー項目の選定 IdP側で持つユーザー属性のどれかと Salesforceユーザーの「統合 ID」をマッピング。 (メールアドレス等は変更リスクがあるため、社員番号などの 不変な IDの使用がいいのでは？ ) ユーザープロビジョニング Salesforce側で事前にユーザー作成する運用が多いと思量。 ジャストインタイム（ JIT）のユーザープロビジョニングはライセンス費用の観点でやらないのでは？ 対象範囲の限定 統制強化のため、一般ユーザーには「ログインは SSOのみ」にする傾向。 それでもなお管理者は SSOから除外しID/PW+MFAを残す（締め出し防止）。 Salesforce Architects Meetup Tokyo
運用設計 証明書の更新運用 有効期限管理を忘れるとログイン不能に。セキュリティが許せば長期の有効期限にするのも手か。 一元管理リストへの追加を推奨。 異動・退職対応 SSOだけにしておけば IdP側のユーザーリストで無効化すればセキュア。 ただし、ライセンスの関係で Salesforce側のユーザー無効化フローも整備が必要。 例外対応 SSO障害時に備えた管理者用ログインルートの確保。 SSOだけにしておいても、その場で PWリセットしてログイン許可する運用もあり。 Salesforce Architects Meetup Tokyo
04 設定と導入の流れ Salesforce Architects Meetup Tokyo
導入ステップ 設定フロー 1 設計および検証の計画 前述の内容を相手方と協議 2 事前設定、SAMLメタデータ交換 設定するのと、 IdPからSAMLメタデータXMLを入手しSalesforceにアップロード 3 検証用ユーザー準備 検証用ユーザーを作成し「統合 ID」を設定 4 接続検証 → 本格準備 実際のログインフローを確認 Salesforce Architects Meetup Tokyo
関係する設定箇所 • シングルサインオン設定 : SAML自体の有効化、代理認証 (SSOだけにする場合などは設定 )の有効化 個々のシングルサインオンの設定 (ここでSAMLメタデータの登録や取得、要求署名証明書の準備 )、認証失敗時 の検証なども行う • 証明書と鍵の管理 : 要求署名証明書の管理はここ • ユーザーと権限セット : ユーザーの「統合 ID」を設定する。ログイン履歴も見る。 「シングルサインオンの有効化」権限セット付与 • 私のドメイン : ログイン画面に IdPへの遷移ボタンを出せるようにする Salesforce Architects Meetup Tokyo
SAML設定の全体イメージ IdP SP (Salesforce) SAMLメタデータ(証明書含む ) SSO全体設定 IdPごとの 連携設定 IdP 証明書 シングルサインオン設定 要求署名 証明書 証明書と鍵 (要求署名証明書。使わないかも) ログイン設定 (SSOのみにするか、 など) ポータルの 設定等 代理認証 Salesforce ログイン画面設定 (私のドメイン) 「シングルサインオ ンの有効化」 権限セット ユーザー管理 Salesforce Architects Meetup Tokyo ユーザー リスト 属性 統合ID ユーザー
05 実践と「あるある」 Salesforce Architects Meetup Tokyo
ありそうな導入スケジュール 相手方との調整を含めた日程感(たぶん最短コース) 予備はなんだかんだ言って必要。 設計・計画 Salesforce 事前設定 メタデータ 交換・後続設定 接続検証 接続検証 予備日 Day 1 Day 5 Day 7 Day 10 Day 14 Salesforce Architects Meetup Tokyo
あるある : 別組織と連携して推進するのが難儀 ● ● ● ● お客さんのID管理ポリシーの闇 をつつくことになる可能性 ○ 「共有IDでログインしていた」 →「運用は変えられない」 設定手順は空気を読み つつ策定 ○ 関連用語において日本語の定訳がなく、情報も最新に更新されていない場合も多い ■ 例) “IdP開始”／”IdP-initiated”／”IdPイニシエート”／”IdPを起点とする～ ” ○ Oktaなどはご丁寧に Salesforce上の設定手順のご案内もあるが、 Salesforceでの「代理認証」は「委 任認証」と書かれていたりする ○ 一般的にドキュメントの分かりにくさもある … 技術標準とはいえ、 SAMLにどこまで厳密に準拠しているかは相手サービス次第 ○ 要求署名検証に対応していないものは結構ありそう ○ さらに相手側担当者ともうまく会話が合わない可能性 がある(お互いにSAMLをすべて知ってるわけ ではなく、基礎的な内容と自担当サービスの設定手順を知ってるだけ )。 ○ 相手サービスの仕様や手順に「踏み込むか・踏み込まないか」の別の難しさがある たいていの場合、 IdPは本番環境しかない し、セキュリティを重視する顧客だと簡単に触れない ○ 一発で当てに行く必要性があってかなりドキドキする。計画と予備日、大事。 Salesforce Architects Meetup Tokyo