Salesforce 管理者向け SAML シングルサインオン設定マスターガイド

背景と応用シナリオ

現代の企業環境では、従業員は日々の業務で多数のクラウドアプリケーションを利用しています。Salesforceもその中心的な存在の一つですが、アプリケーションごとに異なるIDとパスワードを管理することは、利用者にとっては大きな負担となり、管理者にとってはセキュリティリスクの温床となります。パスワードの使い回し、簡単なパスワードの設定、退職者のアカウント削除漏れなど、多くの問題を引き起こす可能性があります。

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

Salesforceでは、このSSOを実現するための業界標準プロトコルとして Security Assertion Markup Language (SAML) をサポートしています。SAMLは、ID情報を安全に交換するためのXMLベースのオープンスタンダードです。例えば、企業が既に Microsoft Azure AD や Okta、Google Workspace などの Identity Provider (IdP) (IDプロバイダー) を導入している場合、SAML連携を設定することで、ユーザーはいつもの会社のログイン情報を使ってSalesforceにシームレスにログインできるようになります。これにより、Salesforce専用のパスワードを覚える必要がなくなります。

本記事では、Salesforce 管理者の視点から、SAMLの基本的な仕組み、Salesforceでの設定方法、そして運用上の注意点について、実践的に解説していきます。

原理説明

SAML SSOの仕組みを理解するためには、登場する3つの主要な役割を把握することが重要です。

User (ユーザー): Salesforceにアクセスしようとしている本人です。
Identity Provider (IdP) (IDプロバイダー): ユーザーの本人確認（認証）を行い、身元情報を管理するシステムです。例：Azure AD, Okta, ADFS。ユーザーのパスワードを実際に検証するのはこのIdPです。
Service Provider (SP) (サービスプロバイダー): ユーザーが利用したいサービスを提供するアプリケーションです。このシナリオではSalesforceがSPとなります。

SAML認証のフローは、一般的に以下のステップで進行します（これはIdP-initiated Flowと呼ばれる典型的なパターンです）。

1. ユーザーがSalesforceへのアクセスを試みる: ユーザーがSalesforceのログインURLにアクセスするか、Salesforceへのリンクをクリックします。
2. Salesforce (SP)からIdPへのリダイレクト: Salesforceは、このユーザーがSSOで認証されるべきだと認識すると、ユーザーのブラウザをIdPのログインページにリダイレクトさせます。このとき、SAMLリクエストと呼ばれる情報が送られます。
3. IdPでのユーザー認証: IdPはユーザーに認証情報（ユーザー名、パスワード、多要素認証など）の入力を求めます。ユーザーが既にIdPにログイン済みの場合は、このステップはスキップされます。
4. SAML Assertionの生成: 認証が成功すると、IdPはSAML Assertion (SAMLアサーション) と呼ばれるXML形式の電子証明書を生成します。このアサーションには、「このユーザーは確かに本人であり、このような属性（例：ユーザーID、メールアドレス）を持っています」という情報が、IdPのデジタル署名付きで含まれています。
5. アサーションのSalesforceへの送信: IdPは、このSAMLアサーションをユーザーのブラウザ経由でSalesforceの特定のURL（Assertion Consumer Service URLと呼ばれます）に送信（HTTP POST）します。
6. Salesforceでのアサーション検証とログイン: Salesforceは受け取ったSAMLアサーションを検証します。まず、事前に交換しておいたIdPの公開証明書を使ってデジタル署名が正当であるかを確認します。次に、アサーションの内容（発行者、対象者、ユーザーIDなど）がSalesforceの設定と一致するかをチェックします。
7. ログイン成功: すべての検証が成功すると、Salesforceはユーザーに対応するセッションを作成し、ユーザーはSalesforceにログインした状態になります。

この一連の流れにより、Salesforceはユーザーのパスワードを一切知ることなく、信頼できるIdPからの「お墨付き（アサーション）」を基にユーザーを安全に受け入れることができるのです。

サンプルコード

Salesforce 管理者が直接コードを書くことは稀ですが、SAMLのトラブルシューティングを行う際には、SAMLアサーションのXML構造を理解していることが非常に役立ちます。IdPから送られてくるアサーションに問題がある場合、ログインエラーが発生するためです。以下は、Salesforceが受け取るSAML 2.0アサーションの典型的な構造例です。これは developer.salesforce.com のドキュメントで解説されている内容に基づいています。

<?xml version="1.0" encoding="UTF-8"?>
<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
                 Destination="https://login.salesforce.com?so=00Dxxxxxxxxxxxx"
                 ID="_c7336f83-5c3a-441c-8b5f-3d1b2b8d9b1a"
                 IssueInstant="2023-10-27T05:20:00.123Z"
                 Version="2.0">
  <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://your-idp.example.com/saml</saml2:Issuer>
  <!-- 
    Issuer: IdPの一意識別子。Salesforceの「発行者」設定と完全に一致する必要があります。
  -->
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <!-- デジタル署名ブロック。これによりアサーションの改ざんが防止されます -->
  </ds:Signature>
  <saml2p:Status>
    <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </saml2p:Status>
  <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
                   ID="_a1b2c3d4-e5f6-7890-1234-567890abcdef"
                   IssueInstant="2023-10-27T05:20:00.123Z"
                   Version="2.0">
    <saml2:Issuer>https://your-idp.example.com/saml</saml2:Issuer>
    <saml2:Subject>
      <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">sso.user@example.com</saml2:NameID>
      <!--
        NameID: ユーザーを特定する一意のID。
        Salesforceのユーザーオブジェクトの「統合ID (FederationIdentifier)」または「ユーザー名」と照合されます。
        ベストプラクティスは「統合ID」を使用することです。
      -->
      <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml2:SubjectConfirmationData NotOnOrAfter="2023-10-27T05:25:00.123Z"
                                       Recipient="https://login.salesforce.com?so=00Dxxxxxxxxxxxx"/>
      </saml2:SubjectConfirmation>
    </saml2:Subject>
    <saml2:Conditions NotBefore="2023-10-27T05:15:00.123Z"
                      NotOnOrAfter="2023-10-27T05:25:00.123Z">
      <saml2:AudienceRestriction>
        <saml2:Audience>https://saml.salesforce.com</saml2:Audience>
        <!--
          Audience: このアサーションの宛先。
          Salesforceの「エンティティID」と完全に一致する必要があります。
        -->
      </saml2:AudienceRestriction>
    </saml2:Conditions>
    <saml2:AttributeStatement>
      <!--
        AttributeStatement: Just-In-Time Provisioningで使用する追加属性。
        ユーザーのプロファイル、ロール、連絡先情報などを送信し、Salesforceのユーザーレコードを動的に作成・更新できます。
      -->
      <saml2:Attribute Name="User.Username" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
        <saml2:AttributeValue>sso.user@example.com.dev</saml2:AttributeValue>
      </saml2:Attribute>
      <saml2:Attribute Name="User.Email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
        <saml2:AttributeValue>sso.user@example.com</saml2:AttributeValue>
      </saml2:Attribute>
    </saml2:AttributeStatement>
  </saml2:Assertion>
</saml2p:Response>

注意事項

SAML SSOを導入・運用する際には、いくつかの重要な点に注意する必要があります。

権限と設定

SAML SSOの設定を行うには、Salesforce組織で「アプリケーションのカスタマイズ」および「IDとアクセス権の管理」権限が必要です。通常、システム管理者プロファイルにはこれらの権限が付与されています。設定はSalesforceの [設定] > [ID] > [シングルサインオン設定] から行います。

ユーザープロビジョニング

SSOでログインするためには、対応するユーザーレコードがSalesforceに存在している必要があります。ユーザーの作成・管理には2つの主要な方法があります。

事前プロビジョニング: Data Loaderやインポートウィザード、API連携などを利用して、事前にSalesforceにユーザーを作成しておく方法です。この場合、IdPから送られてくる `NameID` と一致する値を、各ユーザーの統合ID (FederationIdentifier) 項目に設定しておく必要があります。
Just-In-Time (JIT) プロビジョニング: ユーザーが初めてSSOでログインした際に、SAMLアサーション内の情報を使ってSalesforceユーザーを自動的に作成・更新する機能です。管理工数を大幅に削減できますが、アサーションに必要な属性（氏名、メール、プロファイルIDなど）がすべて含まれていることをIdP側と綿密に調整する必要があります。設定に不備があると、ユーザーが作成されずログインに失敗します。

証明書の管理

SAMLのセキュリティは、IdPがアサーションに署名するために使用するデジタル証明書に依存しています。この証明書には有効期限があり、通常1〜3年です。IdPの証明書が期限切れになると、Salesforceは署名を検証できなくなり、全ユーザーのSSOログインが突然停止します。 この事態を避けるため、IdPの管理者と連携し、証明書の有効期限を常に把握し、期限が切れる前にSalesforceの設定で新しい証明書に更新するプロセスを確立することが極めて重要です。

エラー処理とデバッグ

SSOでログインできないという問い合わせは、管理者にとって最も一般的なトラブルの一つです。その際には、以下のツールが役立ちます。

SAMLアサーション検証: Salesforceの [シングルサインオン設定] ページにある「SAML アサーション検証」ツールは非常に強力です。IdPから取得したSAMLアサーションのXMLを貼り付けると、Salesforceがそれをどのように解釈し、どこで検証に失敗したかを詳細に示してくれます。「属性 'Audience' の値が無効です」「ユーザーをマップできません」といった具体的なエラー原因を特定できます。
ログイン履歴: [設定] > [ID] > [ログイン履歴] を確認すると、SSOログインの試行履歴が記録されています。失敗したログインについては、「失敗: 無効なアサーション」などの理由が表示され、問題の切り分けに役立ちます。

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

SAMLによるSSOは、Salesforceのセキュリティを強化し、ユーザーの利便性を向上させるための不可欠な機能です。正しく設定・運用することで、ID管理を劇的に効率化できます。

最後に、Salesforce管理者としてSAML SSOを成功させるためのベストプラクティスをいくつか紹介します。

統合ID (FederationIdentifier) を使用する: ユーザーの照合には、変更される可能性のあるユーザー名ではなく、不変の従業員IDなどを格納した統合IDを使用してください。これにより、ユーザーのメールアドレスや姓名が変更されてもSSOが中断されることはありません。
本番適用前にSandboxで徹底的にテストする: 必ずFull SandboxやPartial SandboxでIdPとの接続テストを完了させてください。JITプロビジョニングの動作やプロファイルのマッピングなど、すべてのシナリオをテストしてから本番環境に展開します。
管理者用のバックドアを確保する: SSOの設定ミスやIdPの障害が発生した場合に備え、システム管理者だけは通常のSalesforceログインURL (login.salesforce.com) からユーザー名とパスワードでログインできるようにしておくことが賢明です。[私のドメイン] の設定で、この代替ログイン方法を無効にしないようにしてください。
ドキュメントを整備する: IdP側の担当者連絡先、証明書の有効期限、設定したエンティティIDや各種URLなど、SAML設定に関する情報を一元的に文書化しておきましょう。これにより、将来の担当者交代やトラブルシューティングがスムーズになります。

これらのポイントを押さえ、計画的にSAML SSOを導入することで、貴社のSalesforce環境をより安全で使いやすいものへと進化させることができるでしょう。

にゃんこのSalesforce日記

このブログを検索