Salesforce SAML SSO完全ガイド：Salesforce管理者のための設定とベストプラクティス

背景と適用シナリオ

Salesforce管理者として、私たちは常にユーザーエクスペリエンスの向上とセキュリティの強化という2つの大きな課題に直面しています。現代の企業では、従業員は日々の業務でSalesforce、Office 365、Google Workspaceなど、数多くのクラウドアプリケーションを利用しています。アプリケーションごとに異なるIDとパスワードを管理することは、ユーザーにとって大きな負担であり、パスワードの使い回しや簡単なパスワードの設定といったセキュリティリスクの温床にもなりかねません。

この課題を解決する強力なソリューションが、Single Sign-On (SSO) (シングルサインオン) です。SSOを導入することで、ユーザーは一度の認証で複数の許可されたアプリケーションにアクセスできるようになります。これにより、ログインの利便性が飛躍的に向上し、IT部門はアクセス制御を一元管理できるため、セキュリティを大幅に強化できます。

このSSOを実現するための業界標準プロトコルの一つが、SAML (Security Assertion Markup Language) (セキュリティアサーションマークアップランゲージ) です。SAMLは、ID情報を安全に交換するためのXMLベースのオープンスタンダードであり、SalesforceはSAML 2.0を完全にサポートしています。

本記事では、Salesforce管理者の視点から、SAML SSOの基本的な仕組みから、Salesforceでの具体的な設定手順、注意点、そしてベストプラクティスまでを網羅的に解説します。この記事を読めば、あなたの組織でSAML SSOを自信を持って導入し、運用管理できるようになるでしょう。

原理の説明

SAML SSOの仕組みを理解するためには、まず2つの主要な登場人物を把握する必要があります。

Identity Provider (IdP) (IDプロバイダー)
ユーザーを認証し、その身元情報を証明する役割を担うシステムです。Azure Active Directory、Okta、Google Identity、ADFSなどが代表的なIdPです。IdPは組織の信頼できる認証ソースとなります。

Service Provider (SP) (サービスプロバイダー)
ユーザーがアクセスしたいサービスを提供するアプリケーションです。今回の文脈では、SalesforceがSPにあたります。

SAML SSOの認証フローには、主に「SP-Initiated (SP起因)」と「IdP-Initiated (IdP起因)」の2つのパターンがあります。

SP-Initiated フロー

これは、ユーザーが最初にSalesforceにアクセスしようとする最も一般的なフローです。

ユーザーはブラウザでSalesforceのログインURL（「私のドメイン」のURL）にアクセスします。
Salesforce (SP) は、このユーザーがSSO経由でログインする必要があると判断し、ユーザーのブラウザをIdPのログインページにリダイレクトします。このとき、SAMLリクエストがIdPに送られます。
IdPはユーザーに認証情報（ユーザー名、パスワード、多要素認証など）を要求し、認証を行います。
認証が成功すると、IdPはユーザー情報を含むXML形式のSAML Assertion (SAMLアサーション) を生成し、デジタル署名を付与します。
IdPは、このSAMLアサーションをユーザーのブラウザ経由でSalesforceに送り返します。
SalesforceはSAMLアサーションを受け取り、IdPの証明書を使ってデジタル署名を検証し、内容（発行者、対象者、ユーザーIDなど）が正当であるかを確認します。
検証が成功すれば、Salesforceはユーザーのセッションを作成し、ユーザーはSalesforceにログインした状態になります。

IdP-Initiated フロー

これは、ユーザーがIdPのポータルサイトなどからSalesforceにアクセスするフローです。

ユーザーはIdPのポータル（例：Oktaのダッシュボード）にログインします。
ユーザーがポータル上のSalesforceアプリアイコンをクリックします。
IdPはSAMLアサーションを生成し、ユーザーのブラウザに渡します。
ブラウザは、このSAMLアサーションをSalesforceの指定されたエンドポイント（ACS URL）に直接送信します。
Salesforceはアサーションを検証し、問題がなければユーザーをログインさせます。

どちらのフローにおいても、中心的な役割を果たすのがSAMLアサーションです。このアサーションには、「誰が (Subject)」「いつ (Conditions)」「何について (Audience)」「どのような権限で (Attributes)」認証されたか、といった情報が含まれており、IdPのデジタル署名によってその正当性が保証されています。管理者として、これらのコンポーネントが正しく設定されていることを確認することが、SSO導入成功の鍵となります。

設定の概要とコードの役割

Salesforce管理者として標準的なSAML SSOを設定する場合、通常、ApexコードやVisualforceコードを記述する必要はありません。設定はSalesforceの「設定」メニューからGUIベースで行います。IdPから提供されるメタデータファイル（Issuer、証明書、エンドポイントURLなどを含むXMLファイル）をインポートするか、手動で各値を入力することで設定は完了します。

ただし、より高度な要件、特にJust-in-Time (JIT) Provisioning (ジャストインタイムプロビジョニング) をカスタマイズする場合には、Apexコードが必要になることがあります。JITプロビジョニングとは、SAMLアサーションに含まれる情報を使って、初回ログイン時にSalesforceユーザーを自動的に作成したり、既存ユーザーの情報を更新したりする機能です。

標準のJITプロビジョニングでは、アサーションの属性をユーザーオブジェクトの項目に直接マッピングできますが、複雑なロジック（例：特定のプロファイルやロールを動的に割り当てる、カスタムオブジェクトにレコードを作成する）が必要な場合は、ApexでカスタムのJITハンドラクラスを作成します。

管理者としては、このようなカスタムハンドラを開発者と協力して実装し、SSO設定画面でそのApexクラス名を指定することになります。

Apex JIT ハンドラのサンプルコード

以下は、Salesforceの公式ドキュメントで提供されているJITハンドラのサンプルコードです。このコードは、ユーザーを自動作成し、特定のプロファイル、ロール、およびタイムゾーンを設定するロジックを示しています。

/*
 * このクラスは、SAML JIT シングルサインオンを処理するためのサンプルハンドラです。
 * ユーザーが存在しない場合にユーザーを作成し、存在する場合はユーザー情報を更新します。
 * updateUser と createUser の両方のメソッドで、ユーザーの属性をSAMLアサーションから設定します。
 */
global class SamlJitHandler implements Auth.SamlJitHandler {

    private class JitException extends Exception {}

    // ユーザー情報を更新するロジック
    global void updateUser(Id userId, Id portalId, Id siteId,
        String federationIdentifier, Map<String, String> attributes,
        String assertion) {
        
        User u = [SELECT Id, TimeZoneSidKey FROM User WHERE Id=:userId];
        
        // アサーションからタイムゾーンを取得し、ユーザーに設定
        if (attributes.containsKey('user_timezone')) {
            String tz = attributes.get('user_timezone');
            if (isValidTimezone(tz)) {
                u.TimeZoneSidKey = tz;
            }
        }
        update(u);
    }
    
    // ユーザーを新規作成するロジック
    global Id createUser(Id portalId, Id siteId, String federationIdentifier,
        Map<String, String> attributes, String assertion) {
            
        // 必須属性がアサーションに含まれているかチェック
        if (!attributes.containsKey('user_username')) {
            throw new JitException('Assertion missing username');
        }
        if (!attributes.containsKey('user_email')) {
            throw new JitException('Assertion missing email');
        }
        if (!attributes.containsKey('user_lastname')) {
            throw new JitException('Assertion missing lastname');
        }
        if (!attributes.containsKey('user_firstname')) {
            throw new JitException('Assertion missing firstname');
        }

        // プロファイルIDを名前で検索
        Profile p = [SELECT Id FROM Profile WHERE Name='Standard User'];

        // 新しいユーザーオブジェクトを作成
        User u = new User();
        u.Username = attributes.get('user_username');
        u.Email = attributes.get('user_email');
        u.LastName = attributes.get('user_lastname');
        u.FirstName = attributes.get('user_firstname');
        u.FederationIdentifier = federationIdentifier; // Federation IDを設定
        u.Alias = 'jit';
        u.CommunityNickname = 'jit';
        u.ProfileId = p.Id;
        u.LocaleSidKey = 'en_US';
        u.LanguageLocaleKey = 'en_US';
        u.EmailEncodingKey = 'UTF-8';

        // アサーションからタイムゾーンを取得して設定
        if (attributes.containsKey('user_timezone')) {
            String tz = attributes.get('user_timezone');
            if (isValidTimezone(tz)) {
                u.TimeZoneSidKey = tz;
            }
        }
        
        return u.Id;
    }
    
    // タイムゾーンが有効か検証するヘルパーメソッド
    private Boolean isValidTimezone(String tz) {
        Boolean isValid = false;
        List<TimeZone> validTimezones = TimeZone.getAvailableIDs();
        for (String validTz : validTimezones) {
            if (validTz.equals(tz)) {
                isValid = true;
                break;
            }
        }
        return isValid;
    }
}

注釈：このコードは、Auth.SamlJitHandler インターフェースを実装しています。createUser メソッドは新しいユーザーを作成し、updateUser メソッドは既存のユーザーを更新します。管理者は、開発者がこのクラスを作成・デプロイした後、シングルサインオン設定の「カスタム SAML JIT ハンドラ」項目にクラス名（この場合は SamlJitHandler）を指定します。

注意事項

SAML SSOを導入・運用する際には、いくつかの重要な点に注意する必要があります。これらを怠ると、ユーザーがログインできなくなるなどの深刻な問題が発生する可能性があります。

権限 (Permissions)

SAML SSO設定を行うには、プロファイルまたは権限セットで「アプリケーションのカスタマイズ」および「シングルサインオン設定の管理」権限が必要です。

Federation ID (統合ID)

SAMLでユーザーを識別するための最も一般的な方法は、Federation ID を使用することです。これは、IdPのユーザーID（例：従業員番号やメールアドレス）とSalesforceユーザーを紐付けるための一意のキーです。組織内で一意でなければならず、大文字と小文字が区別されます。IdP側の設定とSalesforceのユーザーレコードで、この値が完全に一致していることを確認する必要があります。

証明書の有効期限 (Certificate Expiration)

IdPはSAMLアサーションに署名するためにデジタル証明書を使用します。この証明書には有効期限があります。証明書が期限切れになると、Salesforceは署名を検証できなくなり、すべてのSSOログインが失敗します。管理者は、IdPの証明書の有効期限を監視し、期限が切れる前にSalesforceの設定を更新するプロセスを確立しなければなりません。

私のドメイン (My Domain)

SalesforceでSSOを有効にするには、「私のドメイン」が設定され、組織全体にリリースされていることが必須要件です。

管理者アカウントのロックアウト防止

SSO設定に誤りがあった場合、全ユーザー（管理者自身を含む）がSalesforceにログインできなくなるリスクがあります。この「ロックアウト」を避けるため、SSOの影響を受けない、標準のユーザー名とパスワードでログインできるシステム管理者アカウントを最低一つは確保しておくことが極めて重要です。緊急時には、通常のログインURL（例：https://login.salesforce.com/?login のようにクエリパラメータを付与）から、この管理者アカウントでログインして問題を修正します。

テストの重要性

本番環境に展開する前に、必ずFull Sandboxなどのテスト環境でSSO設定を徹底的にテストしてください。SP-Initiated、IdP-Initiatedの両方のフロー、異なるプロファイルのユーザーでのログイン、JITプロビジョニングの動作（新規作成・更新）などを確認します。

まとめとベストプラクティス

SAMLによるSSOは、Salesforceのセキュリティとユーザビリティを劇的に向上させるための強力な機能です。正しく実装することで、ユーザーはパスワードの煩わしさから解放され、管理者は一元的なアクセスコントロールを実現できます。

最後に、SAML SSOを成功させるためのベストプラクティスをまとめます。

ユーザー識別子には Federation ID を使用する: Salesforceユーザー名は変更される可能性があるため、不変で一意な Federation ID を使うことが推奨されます。
JITプロビジョニングを積極的に活用する: ユーザーの入社・異動・退職に伴うアカウント管理を自動化し、管理者の手作業を大幅に削減します。
証明書の更新プロセスを計画する: 証明書の有効期限をカレンダーに登録し、更新手順を文書化しておきましょう。マルチ証明書機能を利用すれば、ダウンタイムなしでの更新も可能です。
エンドユーザーへの丁寧なコミュニケーション: ログイン方法の変更は、ユーザーにとって大きな変化です。新しいログインURL、手順、トラブルシューティング方法などを記載した明確なガイドを提供し、移行をスムーズに進めましょう。
SSOを強制する: SSOが安定稼働したら、プロファイルや権限セットでSSOユーザーのパスワードによる直接ログインを無効にし、セキュリティポリシーを徹底します。
ログイン履歴とデバッグログを監視する: SSOに関する問題が発生した場合、Salesforceの「ログイン履歴」やSAMLアサーション検証エラーのデバッグログが、原因究明の重要な手がかりとなります。

Salesforce管理者としてこれらのポイントを理解し、計画的にSAML SSOを導入・運用することで、組織のセキュリティ基盤を強化し、すべてのユーザーにとってより快適なSalesforce利用環境を提供できるはずです。

にゃんこのSalesforce日記

このブログを検索