Salesforce SAML シングルサインオン（SSO）設定：管理者向け完全ガイド

日付:

執筆者：Salesforce 管理者

こんにちは！Salesforce 管理者の視点から、多くの企業で導入されている重要なセキュリティ機能、SAML を利用した Single Sign-On (SSO) (シングルサインオン) について、その基本から設定のポイント、運用上の注意点までを網羅的に解説します。日々のユーザー管理やセキュリティ強化に奮闘されている管理者仲間の一助となれば幸いです。

背景と応用シナリオ

企業の成長に伴い、利用するクラウドサービスは増加の一途をたどります。Salesforce、Microsoft 365、Google Workspace、その他多数のSaaS...。従業員はサービスごとにIDとパスワードを記憶し、管理者はそれぞれのサービスでユーザーの追加や削除、権限設定を行う必要があります。この状況は、いくつかの深刻な問題を引き起こします。

  • ユーザーエクスペリエンスの低下：多数のパスワードを覚える負担は大きく、ログインのたびに手間がかかります。結果として、パスワードの使い回しや付箋にメモするといった、セキュリティ上好ましくない行動を誘発します。
  • セキュリティリスクの増大：退職者のアカウント削除漏れは、情報漏洩の温床となります。また、サービスごとにパスワードポリシーが異なると、システム全体のセキュリティレベルを均一に保つことが困難になります。
  • 管理コストの増大：ユーザーの入社、異動、退職のたびに、管理者は各システムで手作業によるアカウント管理を行う必要があり、非常に非効率です。

これらの課題を解決する強力なソリューションが、Single Sign-On (SSO) です。SSOを導入することで、ユーザーは一度の認証で許可されたすべてのサービスにアクセスできるようになります。そして、そのSSOを実現するための標準規格の一つが SAML (Security Assertion Markup Language) (セキュリティ アサーション マークアップ ランゲージ) です。

Salesforce管理者としてSAML SSOを導入する主なシナリオは、社内のID管理システム（例：Azure Active Directory, Okta, Google Workspace）を認証の基盤とし、Salesforceへのログインを統合することです。これにより、ユーザーは使い慣れた会社の認証情報でSalesforceにシームレスにログインでき、管理者はID管理を一元化できるため、セキュリティと利便性を飛躍的に向上させることができます。

原理説明

SAMLの仕組みを理解するために、まずは登場人物と基本的な流れを把握しましょう。

主な登場人物

  • ユーザー (User)：Salesforceにアクセスしたい従業員です。
  • Service Provider (SP) (サービスプロバイダー)：ユーザーが利用したいサービス。この文脈では Salesforce が該当します。SPはユーザー認証を自分自身では行わず、信頼できるIdPに委任します。
  • Identity Provider (IdP) (ID プロバイダー)：ユーザーの認証情報を一元管理し、認証を行う主体です。Azure AD, Okta, ADFSなどが代表的なIdPです。IdPはユーザーを認証し、その結果を「アサーション」としてSPに渡します。

SAML認証のフロー

SAMLには主に2つの認証フローが存在します。

1. SP-Initiated (SP起点の) フロー

これは最も一般的なフローで、ユーザーが直接SalesforceのログインURLにアクセスした場合に発生します。

  1. ユーザーがSalesforceのログインページにアクセスします。
  2. Salesforce (SP) は、ユーザーが自組織のSSO対象であると判断し、未認証のリクエストをIdPにリダイレクトします（SAMLリクエストを生成）。
  3. ユーザーのブラウザはIdPのログインページに転送されます。ユーザーはIdPに対して認証情報（ユーザー名、パスワード、多要素認証など）を入力します。
  4. IdPは認証が成功したことを確認し、ユーザーの身元情報（ユーザー名、メールアドレスなど）を含む SAML Assertion (SAML アサーション) と呼ばれるXML形式のデジタル署名付きデータを生成します。
  5. IdPは、このSAMLアサーションをユーザーのブラウザ経由でSalesforce (SP) に送り返します。
  6. Salesforceは受け取ったSAMLアサーションの署名を検証し、内容が信頼できるIdPから送られてきたものであることを確認します。
  7. アサーション内の情報（通常は Federation ID (統合ID)）と一致するSalesforceユーザーを特定し、ログインセッションを確立します。ユーザーはSalesforceのホーム画面にリダイレクトされます。

2. IdP-Initiated (IdP起点の) フロー

ユーザーがIdPのポータルサイト（例：Oktaのダッシュボード）からSalesforceのアイコンをクリックした場合などに発生します。

  1. ユーザーは既にIdPにログイン済みです。
  2. IdPのポータル上でSalesforceアプリケーションのアイコンをクリックします。
  3. IdPはSAMLアサーションを生成し、ユーザーのブラウザ経由でSalesforceに直接送信します。
  4. Salesforceはアサーションを検証し、該当するユーザーをログインさせます。

Just-in-Time (JIT) Provisioning

JITプロビジョニングは、SAMLの非常に強力な機能です。IdPからのSAMLアサーションにユーザー情報（プロファイル、ロール、連絡先情報など）を含めることで、Salesforceにまだ存在しないユーザーが初めてSSOログインを試みた際に、自動的にユーザーアカウントを作成したり、既存のユーザー情報を更新したりすることができます。これにより、管理者が手動でユーザーを作成する手間が大幅に削減され、IdP側の情報が常にSalesforceに同期される状態を保つことができます。

示例代码

SAMLの設定自体はSalesforceのUI上で行うため、Apexコードは不要です。しかし、管理者がトラブルシューティングを行う際に、IdPから送られてくるSAMLアサーションの中身を理解することは非常に重要です。特にJITプロビジョニングを利用する場合、どのような情報が送られているかを確認する必要があります。以下は、Salesforceの公式ドキュメントに記載されているJITプロビジョニングの標準的なSAMLアサーションの例です。

JITプロビジョニングのSAMLアサーション例

<?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=00D000000000001" ID="_234567890" IssueInstant="2023-11-20T12:00:00.000Z" Version="2.0">
  <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://www.example-idp.com/</saml2:Issuer>
  <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="_abcdef12345" IssueInstant="2023-11-20T12:00:00.000Z" Version="2.0">
    <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://www.example-idp.com/</saml2:Issuer>
    <saml2:Subject>
      <!-- NameID: SalesforceのユーザーのFederation IDと一致させる必要がある一意の識別子 -->
      <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">sso_user@example.com</saml2:NameID>
      <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml2:SubjectConfirmationData NotOnOrAfter="2023-11-20T12:05:00.000Z" Recipient="https://login.salesforce.com?so=00D000000000001"/>
      </saml2:SubjectConfirmation>
    </saml2:Subject>
    <saml2:Conditions NotBefore="2023-11-20T11:55:00.000Z" NotOnOrAfter="2023-11-20T12:05:00.000Z">
      <saml2:AudienceRestriction>
        <!-- Audience: このアサーションの対象となるSP（Salesforce）のエンティティID -->
        <saml2:Audience>https://saml.salesforce.com</saml2:Audience>
      </saml2:AudienceRestriction>
    </saml2:Conditions>
    <!-- JITプロビジョニング用の属性情報 -->
    <saml2:AttributeStatement>
      <saml2:Attribute Name="User.Username" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
        <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">newuser@example.com.sandbox</saml2:AttributeValue>
      </saml2:Attribute>
      <saml2:Attribute Name="User.Email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
        <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">newuser@example.com</saml2:AttributeValue>
      </saml2:Attribute>
      <saml2:Attribute Name="User.LastName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
        <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Sato</saml2:AttributeValue>
      </saml2:Attribute>
      <saml2:Attribute Name="User.FirstName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
        <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Taro</saml2:AttributeValue>
      </saml2:Attribute>
      <saml2:Attribute Name="User.ProfileId" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
        <!-- SalesforceのプロファイルIDを直接指定する -->
        <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">00e000000000123</saml2:AttributeValue>
      </saml2:Attribute>
    </saml2:AttributeStatement>
  </saml2:Assertion>
</saml2p:Response>

注釈：このXMLはSalesforceのヘルプページ「Just-in-Time Provisioning for SAML」の情報を基に構成されています。AttributeStatement 内の各 Attribute タグが、Salesforceのユーザーオブジェクトの項目に対応しており、JITプロビジョニングでユーザーを作成・更新する際のデータソースとなります。

注意事項

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

権限

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

IDの一致：Federation ID

SAML認証が成功するためには、IdPがSAMLアサーションで送ってくるユーザー識別子と、Salesforce側のユーザー情報を紐付ける必要があります。この紐付けに最も一般的に使われるのが Federation ID (統合ID) です。SAMLアサーションの Subject 内にある NameID の値を、Salesforceの各ユーザーレコードの Federation ID 項目に設定する必要があります。この値は組織内で一意でなければなりません。多くの企業では、従業員のメールアドレスや社員番号を Federation ID として利用します。

証明書の管理

SAMLアサーションは、IdPが持つ秘密鍵でデジタル署名されています。Salesforceは、IdPから事前に受け取った公開鍵証明書を使って、この署名を検証します。この証明書には有効期限があり、期限が切れるとすべてのSSOログインが失敗します。管理者はIdPの証明書の有効期限を定期的に監視し、期限が切れる前に新しい証明書をIdPから入手してSalesforceにアップロードする必要があります。この作業を怠ると、全社的なアクセス障害につながる可能性があります。

緊急時のログイン方法

IdPの障害や設定ミスによりSSOが機能しなくなった場合に備え、システム管理者は必ず通常のユーザー名とパスワードでログインできる方法を確保しておくべきです。Salesforceの標準ログインページ (https://login.salesforce.com/) は、SSO設定後も引き続き利用可能です。SSOが強制されている場合でも、URLの末尾に ?login を追加 (例: https://yourdomain.my.salesforce.com/?login) することで、標準ログイン画面を表示できます。このURLは管理者のブックマーク必須です。

エラー処理とデバッグ

設定がうまくいかない場合、Salesforceの「SAML アサーション検証」ツールが非常に役立ちます。このツールは、[設定] > [ID] > [シングルサインオン設定] の中にあり、IdPから送られてきたSAMLアサーションを貼り付けることで、その内容をSalesforceがどのように解釈するか、どこに問題があるか（証明書が一致しない、発行者が違う、ユーザーが見つからないなど）を詳細に分析してくれます。エラーメッセージが出た際は、まずこのツールでアサーションを検証するのが定石です。

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

SAML SSOは、現代の企業システムにおいてセキュリティ、利便性、管理効率を向上させるための不可欠なテクノロジーです。Salesforce管理者としてこれを正しく導入・運用することで、ユーザーと管理者の双方に大きなメリットをもたらすことができます。

ベストプラクティス

  1. 必ず Sandbox でテストする：本番環境に適用する前に、Full Sandbox や Partial Sandbox でIdPとの接続を十分にテストし、JITプロビジョニングの動作やプロファイル割り当てが意図通りであることを確認してください。
  2. Federation ID の戦略を立てる：全社で一意で、かつ変更される可能性の低い値を Federation ID として採用する戦略を事前に立てましょう。メールアドレスは変更の可能性があるため、不変の社員番号などが望ましい場合もあります。
  3. ドキュメントを整備する：IdP側の設定担当者、証明書の有効期限、緊急連絡先、設定手順などを詳細に文書化し、他の管理者と共有しておきましょう。属人化は障害発生時のリスクを高めます。
    4. - ユーザーへの周知とトレーニング：ログイン方法が変更になることを事前にユーザーへ周知し、新しいログイン手順についての簡単なガイドを提供しましょう。これにより、導入後の問い合わせを減らすことができます。
  4. 証明書の更新プロセスを確立する：証明書の有効期限をカレンダーに登録し、期限の数ヶ月前には更新作業に着手するような社内プロセスを確立してください。
  5. API連携用ユーザーはSSO対象外に：外部システムとの連携に使用するAPI専用のユーザーは、SSOの対象外とし、通常のユーザー名とパスワードでログインできるようにしておくのが一般的です。これにより、IdPの障害時にもシステム間連携が停止するリスクを回避できます。

SAML SSOの設定は一度完了すれば安定して動作しますが、その裏側にある原理と、証明書管理のような運用上の注意点を理解しておくことが、長期的に安定したシステムを提供する上で管理者にとって非常に重要です。

コメント

コメントを投稿