Contents
前提条件と必要な権限
このセクションでは、Okta と Salesforce の SAML 連携を開始する前に確認すべき アカウント種別 と ドメイン設定 をまとめます。権限不足や My Domain が未有効の状態で作業を進めると、途中でエラーが頻発し、実装工数が大幅に増加します。まずは以下の要件を満たしていることを確認してください。
- 管理者ロール：Okta の全体管理者（Administrator）または Application Administrator、Salesforce のシステム管理者（System Administrator）。
- My Domain の有効化：Salesforce 側でカスタムドメインが発行・SSL 証明書が適用されていること。
対象ユーザーと権限
| 項目 | 必要なロール／権限 |
|---|---|
| Okta 側 | Okta Administrator（全体管理）または Application Administrator（Applications 設定が可能） |
| Salesforce 側 | System Administrator もしくは Identity 設定権限 が付与されたユーザー |
| ドメイン | My Domain が有効化され、CNAME と SSL の設定が完了していること |
ポイント：両プラットフォームで同一の管理者アカウントを使用すると、トラブルシューティングが容易になります。
Okta での SAML アプリ作成手順
この章では、Okta の最新 UI（2024 年リリース）を用いて Salesforce 用 SAML アプリ を作成する流れを解説します。アプリ作成 → 設定入力 → 証明書取得の 3 ステップに分けて実施してください。
アプリケーション追加
まずは Okta コンソールで新規アプリを登録します。Web アプリとして SAML 2.0 テンプレートを選択することで、SP‑Initiated フローが有効になります。
- Applications → Applications を開く
- 「Add Application」→「Create New App」をクリック
- カタログから SAML 2.0 → Web を選択し、次へ進む
※ UI の名称は Okta のバージョンにより若干異なる場合がありますが、手順は基本的に同一です。
SAML 設定項目入力
以下のテーブルに示す項目を SAML Settings 画面で入力します。プレースホルダーは実環境のドメインに置き換えてください。
| 項目 | 推奨設定例 |
|---|---|
| Issuer | https://{yourOktaDomain}.okta.com |
| Audience URI (SP Entity ID) | Salesforce の Entity ID（デフォルトは https://salesforce.com） |
| ACS URL | https://{myDomain}.my.salesforce.com?so=00Dxxxxxxxxxxxx |
| Single Logout URL | 任意（設定しない場合は空白でも可） |
| NameID format | EmailAddress もしくは Persistent |
| Attribute Statements | User.email → Email、User.username → Username 等 |
注意点：Issuer と ACS URL が一致していないと「Invalid SAML Response」エラーが発生します。
IdP 証明書の取得
設定完了後に Okta からダウンロードできる X.509 証明書を Salesforce にアップロードします。
- アプリ詳細画面の Sign On タブへ移動
- 「SAML 2.0 Signing Certificate」の Download ボタンで
.cer（DER）形式を取得 - ダウンロードした証明書は安全に保管し、期限切れ前にローテーションできるよう管理計画を立てます
Okta のドキュメントでは、2024 年以降もダウンロード形式は .cer が標準であることが確認されています【1】。
Salesforce 側の SSO 有効化と設定
Salesforce で Okta から送信された SAML アサーションを受け取るために Single Sign‑On Settings を作成します。公式ガイド（Salesforce Help – Okta integration）に沿って設定を行います。
Single Sign‑On Settings の新規作成
- 設定検索バーで Single Sign-On Settings を入力し、ページへ遷移
- 「New」ボタンをクリックし、以下の項目を入力
| 項目 | 入力例 |
|---|---|
| Name | Okta_SAML_SSO |
| Issuer (IdP Entity ID) | https://{yourOktaDomain}.okta.com |
| Entity ID (SP Entity ID) | https://salesforce.com（My Domain を使用する場合は https://{myDomain}.my.salesforce.com） |
| Identity Provider Login URL | https://{yourOktaDomain}.okta.com/app/{appId}/sso/saml |
| Certificate | 先ほど取得した X.509 証明書をアップロード |
ポイント：Issuer と Identity Provider Login URL は Okta コンソールに表示されている文字列をそのままコピーしてください。
必須項目の概要と推奨設定
| 項目 | 推奨値・解説 |
|---|---|
| Subject Type / NameID Format | EmailAddress（メール）または Persistent ID を Okta と同一に設定 |
| Authentication Context Class Reference | urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport（標準的な保護レベル） |
| RelayState (任意) | 特定ページへリダイレクトしたい場合に使用。設定しない場合は空白で可 |
NameID の不一致は最も頻出するエラーの一つですので、必ず Okta 側と合わせてください。
テストフロー・属性マッピング例・My Domain 活用
設定が完了したら 実際に SSO が機能するか を検証します。ここではテスト手順と属性マッピングの具体例、そして My Domain の活用ポイントを示します。
テスト手順
- ブラウザのシークレットモードで
https://{myDomain}.my.salesforce.comにアクセス - ログイン画面に表示される Okta ボタン（SAML アプリ名）をクリック
- Okta の認証画面でユーザー資格情報を入力し、認可が成功すると自動的に Salesforce にリダイレクト
シークレットモードはキャッシュや既存セッションの影響を排除できるため、実環境と同等のフローを検証できます。
属性マッピング例
| Okta属性 | Salesforce項目 |
|---|---|
User.email |
Email |
User.username |
Username |
User.firstName |
FirstName |
User.lastName |
LastName |
User.title (任意) |
Title |
備考：属性が正しくマッピングされていないと、Salesforce 側で必須項目が空白となりログイン後にエラーメッセージが表示されます。
My Domain の活用ポイント
- ブランド統一：ユーザーは自社ドメイン（例:
mycompany.my.salesforce.com）で認証画面に遷移でき、信頼性が向上します。 - セキュリティ強化：My Domain が有効だと、許可された IdP 以外からの SAML アサーションは自動的にブロックされます【2】。
一般的なエラーと対処法・セキュリティベストプラクティス
実装時に遭遇しやすいエラーと、運用で推奨される セキュリティ設定 をまとめました。問題が発生した際はまずエラーメッセージを Okta と Salesforce の両方で確認し、原因箇所を切り分けてください。
代表的エラーと対処法
| エラーメッセージ | 主な原因 | 推奨対策 |
|---|---|---|
| NameID 不一致 | NameID format が相違 | 両側で EmailAddress または Persistent を統一し、Okta の「Name ID Format」設定を再確認 |
| 証明書期限切れ | Signing Certificate の有効期限が過ぎている | Okta で新しい証明書を発行し、Salesforce に即時アップロード |
| ACS URL 誤り | My Domain と ACS URL が不一致 | 正確な https://{myDomain}.my.salesforce.com?... を Okta の ACS フィールドに設定 |
| Invalid Signature | 署名アルゴリズムや証明書ペアが不整合 | Okta の「Signature Algorithm」を RSA‑SHA256 に統一し、証明書の文字コード (UTF‑8) を確認 |
セキュリティベストプラクティス
| 設定項目 | 推奨設定 |
|---|---|
| 署名方式 | RSA‑SHA256（Okta と Salesforce の両方で同一） |
| アサーション暗号化 | 必要に応じて有効化し、機密属性の漏洩リスクを低減 |
| アサーション有効期間 | デフォルト 5 分から最大 10 分へ延長（過度な延長はリプレイ攻撃の危険） |
| JIT プロビジョニング | 必要項目（Email、Username 等）を属性マッピングに含める。Okta のベストプラクティスガイドでは、JIT を導入した組織でヒューマンエラーが平均 30% 減少したと報告されています【3】 |
| 証明書ローテーション | 6 ヶ月ごとに新証明書を発行し、旧証明書はリリース後 30 日以内に無効化 |
| ログ監視 | Okta System Log と Salesforce Event Monitoring を統合し、SSO 関連の失敗や異常アクセスをリアルタイムで検知 |
ポイント：暗号化と署名は併用することで、認証情報の改ざん・盗聴リスクを大幅に低減できます。
まとめ
- 前提条件：Okta と Salesforce の管理者権限、My Domain の有効化が必須です。
- Okta 側設定：アプリ追加 → SAML 設定入力（Issuer・ACS URL 等）→ Signing Certificate を取得し、安全に保管します。
- Salesforce 側設定：Single Sign‑On Settings で新規レコードを作成し、IdP 情報と証明書を登録します。
- テストと属性マッピング：My Domain 経由で SSO フローを検証し、
User.email → Email等の属性が正しく反映されているか確認してください。 - エラー対策・ベストプラクティス：NameID の統一、証明書ローテーション、RSA‑SHA256 署名、アサーション暗号化、JIT プロビジョニング活用を推奨します。
上記手順と注意点を守ることで、Okta と Salesforce 間の SAML 2.0 シングルサインオン構築がスムーズに完了し、運用リスクも最小化できます。実装後は社内ナレッジベースへ情報を共有し、定期的な証明書更新とログ監視で継続的なセキュリティ体制を維持してください。
参考文献
- Okta Documentation – Download Signing Certificate (2024).
- Salesforce Help – My Domain and SSO (2024).
- Okta Security Best Practices – Just‑in‑Time Provisioning Report, 2023.