Salesforce 管理者向け SAML シングルサインオン (SSO) 完全ガイド

背景と応用シーン

現代の企業環境では、従業員は日々の業務で多数のクラウドアプリケーションを利用しています。Salesforce、Microsoft 365、Google Workspace、Slackなど、アプリケーションごとに異なるIDとパスワードを管理することは、ユーザーにとって大きな負担となるだけでなく、セキュリティ上のリスクも増大させます。パスワードの使い回しや簡単なパスワードの設定は、不正アクセスの温床となり得ます。

この課題を解決する技術が Single Sign-On (SSO)、日本語で「シングルサインオン」です。SSOを導入することで、ユーザーは一度の認証で、許可されたすべてのアプリケーションにシームレスにアクセスできるようになります。これにより、ユーザーの利便性が向上し、IT部門はアクセス管理を一元化できるため、セキュリティポリシーの徹底が容易になります。

SSOを実現するための標準規格の一つが SAML (Security Assertion Markup Language) です。SAMLは、異なるドメイン間でユーザー認証情報を安全に交換するためのXMLベースのオープンスタンダードであり、エンタープライズ環境で広く採用されています。Salesforce管理者としてSAMLを理解し、正しく設定することは、組織のセキュリティを強化し、ユーザーエクスペリエンスを向上させるための重要なスキルです。

応用シーン

企業ポータルからのシームレスなアクセス: 従業員が企業のイントラネットやID管理システム（Okta, Azure AD, OneLoginなど）にログインするだけで、再度パスワードを入力することなくSalesforceにアクセスできるようにします。
セキュリティの集中管理: 認証をIDプロバイダーに集約することで、多要素認証（MFA）やパスワードポリシー、アクセス元のIPアドレス制限などを一元的に管理・強制できます。
ユーザープロビジョニングの自動化: SAMLと連携する Just-In-Time (JIT) Provisioning を利用することで、ユーザーが初めてSSOでログインした際に、Salesforceに自動的にユーザーアカウントを作成または更新できます。これにより、手動でのアカウント作成・管理の手間が大幅に削減されます。

原理説明

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

Identity Provider (IdP): IDプロバイダー（アイデンティティプロバイダー）。ユーザーを認証し、その身元情報を証明する役割を担います。例として、Microsoft Azure Active Directory (Azure AD), Okta, Google Workspace, Active Directory Federation Services (ADFS) などが挙げられます。
Service Provider (SP): サービスプロバイダー。ユーザーがアクセスしようとしているサービスやアプリケーションです。この文脈では、SalesforceがSPとなります。
User (Principal): ユーザー。ブラウザを介してSP（Salesforce）にアクセスしようとする本人です。

SAMLの認証フローは、一般的に以下のようになります（SP-Initiated Flowの場合）：

1. ユーザーがSalesforceにアクセス: ユーザーがSalesforceのログインURLにアクセスします。
2. SalesforceからIdPへのリダイレクト: Salesforce (SP) はユーザーがまだ認証されていないことを確認し、ユーザーのブラウザをIdPのログインページにリダイレクトさせます。
3. IdPでの認証: ユーザーはIdPに対して認証情報（ユーザー名、パスワード、MFAなど）を入力します。ユーザーが既にIdPにログイン済みの場合は、このステップはスキップされます。
4. SAMLアサーションの生成: 認証が成功すると、IdPはユーザーの身元情報（ユーザーID、属性など）を含むXML形式のデジタル署名付き文書、SAML Assertion（SAMLアサーション）を生成します。
5. Salesforceへのアサーション送信: IdPはSAMLアサーションをユーザーのブラウザに送り返し、ブラウザはそれを自動的にSalesforceの Assertion Consumer Service (ACS) URL にPOST送信します。
6. アサーションの検証とログイン: Salesforce (SP) は受け取ったSAMLアサーションを検証します。具体的には、IdPの公開鍵証明書を使ってデジタル署名を検証し、発行者（Issuer）や対象者（Audience）が正しいかを確認します。検証が成功すると、Salesforceはユーザーのセッションを確立し、ログインを許可します。

このプロセスにより、Salesforceはユーザーのパスワードを直接扱うことなく、信頼できるIdPからの認証結果を基にユーザーを受け入れることができます。これがSAML SSOの基本的な仕組みです。

設定手順とSAMLアサーションの例

Salesforce管理者としてSAML SSOを設定する際、コーディングは不要ですが、設定画面の各項目が何を意味するのかを理解することが不可欠です。以下に、SalesforceをSPとして設定する際の主要なステップと、SAMLアサーションの例を示します。

SalesforceでのSSO設定手順

1. シングルサインオン設定の有効化: Salesforceの[設定]から、[クイック検索]ボックスに「シングルサインオン設定」と入力し、選択します。[編集]をクリックし、「SAML を有効化」にチェックを入れます。

2. SAMLシングルサインオン設定の作成: [新規]ボタンをクリックして、IdPから提供された情報を入力します。

名前: 任意の設定名（例: AzureAD SSO）。
発行者 (Issuer): IdPの一意識別子。IdPのメタデータファイルに記載されています。
ID プロバイダの証明書: IdPから提供された署名検証用の公開鍵証明書（.crtまたは.cerファイル）をアップロードします。
エンティティID: Salesforce組織の一意識別子。通常は[私のドメイン]のURL（例: `https://mydomain.my.salesforce.com`）です。
SAML ID種別: Salesforceユーザーをどのように識別するかを選択します。「統合IDは、UserオブジェクトのFederation ID項目に含まれます」を選択するのがベストプラクティスです。これにより、ユーザー名とは独立した不変のIDでユーザーをマッピングできます。
サービスプロバイダの起動要求バインディング: 「HTTP リダイレクト」を選択するのが一般的です。

3. メタデータのダウンロード: 設定を保存すると、SalesforceはSPとしてのメタデータを提供します。[メタデータをダウンロード]リンクをクリックしてXMLファイルを取得し、これをIdPの管理者に渡してIdP側で設定してもらいます。

4. ユーザーへの統合ID (Federation ID) の設定: 各ユーザーのユーザー詳細ページで、[統合ID]項目にIdPがSAMLアサーションで送信するユーザー識別子（例: 従業員番号やメールアドレス）を正確に入力します。この値がIdPから送られてくる値と完全に一致しないと、ログインに失敗します。

5. [私のドメイン]での認証設定: [設定] > [私のドメイン]に移動し、[認証設定]で[編集]をクリックします。作成したSAML設定を[認証サービス]として選択し、標準のログインページを非表示にすることもできます。

SAMLアサーションの構造例

IdPがSalesforceに送信するSAMLアサーションは、以下のようなXML構造をしています。この例は、Salesforceの公式ドキュメントで示されているJust-In-Timeプロビジョニングのサンプルです。管理者は、この構造を理解することで、IdP側の設定者と円滑にコミュニケーションを取ったり、エラーのトラブルシューティングを行ったりすることができます。

<?xml version="1.0" encoding="UTF-8"?>
<!--
SAML 2.0 Assertion for Just-In-Time Provisioning
-->
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="_2942b0848031572fe7a6859574d42d3a1294893579893" Version="2.0" IssueInstant="2011-03-18T16:39:39.893Z" Destination="https://login.salesforce.com?so=00D...GAQ" InResponseTo="a46872a048733.52c4cf7e">
  <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://www.example.com/idp</Issuer>
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </samlp:Status>
  <Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="_6f21203251a37c0871359d91a92549e51294893579893" Version="2.0" IssueInstant="2011-03-18T16:39:39.893Z">
    <Issuer>https://www.example.com/idp</Issuer>
    <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
      <!-- Signature details are omitted for brevity -->
    </Signature>
    <Subject>
      <!-- SubjectのNameIDがFederation IDとマッピングされる -->
      <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">testuser@example.com</NameID>
      <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <SubjectConfirmationData NotOnOrAfter="2011-03-18T16:44:39.893Z" Recipient="https://login.salesforce.com?so=00D...GAQ" InResponseTo="a46872a048733.52c4cf7e"/>
      </SubjectConfirmation>
    </Subject>
    <Conditions NotBefore="2011-03-18T16:39:09.893Z" NotOnOrAfter="2011-03-18T16:44:39.893Z">
      <AudienceRestriction>
        <!-- AudienceはSalesforceのエンティティIDと一致する必要がある -->
        <Audience>https://saml.salesforce.com</Audience>
      </AudienceRestriction>
    </Conditions>
    <AttributeStatement>
      <!-- JITプロビジョニング用の属性 -->
      <Attribute Name="User.Username"><AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">testuser@example.com.jit</AttributeValue></Attribute>
      <Attribute Name="User.LastName"><AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Test</AttributeValue></Attribute>
      <Attribute Name="User.FirstName"><AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">JIT</AttributeValue></Attribute>
      <Attribute Name="User.Email"><AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">testuser@example.com</AttributeValue></Attribute>
      <Attribute Name="User.ProfileId"><AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">00eD0000000j32x</AttributeValue></Attribute>
    </AttributeStatement>
  </Assertion>
</samlp:Response>

注釈:

<Issuer>: アサーションを発行したIdPを識別します。SalesforceのSSO設定の「発行者」フィールドと一致する必要があります。
<Subject><NameID>: ユーザーの一意識別子です。Salesforceの「SAML ID種別」で指定した項目（通常はFederation ID）とこの値が照合されます。
<Audience>: このアサーションの対象となるSP、つまりSalesforceのエンティティIDを指します。SalesforceのSSO設定の「エンティティID」と一致する必要があります。
<AttributeStatement>: JITプロビジョニングを有効にしている場合、ユーザーの作成や更新に必要な追加情報（メール、姓名、プロファイルIDなど）がここに格納されます。

注意事項

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

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

管理者アカウントのロックアウト防止:
最も重要な注意事項です。SSOの設定に誤りがあったり、IdPがダウンしたりした場合に備え、少なくとも1つのシステム管理者アカウントはSSOをバイパスして標準のユーザー名とパスワードでログインできるように維持してください。具体的には、その管理者ユーザーにはFederation IDを設定せず、プロファイルレベルでSSOを強制しないようにします。テストは必ずシークレットウィンドウ（プライベートブラウジングモード）で行い、現在の管理者セッションを維持したまま動作確認をすることが推奨されます。

証明書の有効期限:
IdPからアップロードした証明書には有効期限があります。期限が切れると、SalesforceはSAMLアサーションの署名を検証できなくなり、すべてのSSOログインが失敗します。IdP側で証明書が更新されたら、速やかにSalesforceの設定も更新する必要があります。証明書の有効期限を監視するプロセスを確立してください。

エラー処理とトラブルシューティング:
ログインに失敗した場合、Salesforceの[設定]にある「SAML アサーション検証」ツールが非常に役立ちます。IdPから送信されたアサーションをこのツールに貼り付けると、Salesforceがどこで検証に失敗したか（例: 「Unable to map the subject to a Salesforce user」など）を具体的に示してくれます。一般的なエラー原因には、Federation IDの不一致、証明書の不一致、IssuerまたはEntity IDの誤りなどがあります。

JITプロビジョニングの制約:
JITは非常に便利ですが、ユーザーの無効化やライセンスの割り当て解除は自動で行いません。従業員が退職した場合は、IdP側でアクセス権を削除するとともに、Salesforce側でも手動または別の自動化プロセスでユーザーを無効化する必要があります。

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

SAML SSOは、Salesforceのセキュリティを強化し、ユーザーの利便性を劇的に向上させるための強力な機能です。管理者としてその仕組みと設定方法をマスターすることで、組織のID管理戦略に大きく貢献できます。

ベストプラクティス

Federation ID を使用する: ユーザーマッピングには、変更される可能性のあるSalesforceユーザー名ではなく、不変のFederation IDを使用してください。従業員番号など、組織内で一意な識別子が理想的です。
サンドボックスで徹底的にテストする: 本番環境に展開する前に、必ずFull SandboxまたはPartial SandboxでSSO設定を構築し、異なるプロファイルのテストユーザーでログインフローを徹底的にテストしてください。
「ブレークグラス」管理者アカウントを維持する: 緊急時に備え、SSOの影響を受けない管理者アカウントを必ず一つ確保し、その認証情報を安全に保管してください。
JITプロビジョニングを検討する: ユーザー管理の運用負荷を軽減するために、JITプロビジョニングの導入を積極的に検討してください。ただし、プロビジョニングされるユーザーのプロファイルやロールが適切に設定されるよう、IdP側で送信する属性を慎重に設計する必要があります。
定期的な証明書の確認: IdP証明書の有効期限をカレンダーに登録するなどして、失効前に計画的に更新するプロセスを確立してください。
明確なドキュメントを作成する: 設定内容、IdPの連絡先、トラブルシューティング手順などをまとめたドキュメントを作成し、他の管理者と共有しておくことで、属人化を防ぎ、インシデント発生時に迅速な対応が可能になります。

これらのプラクティスに従うことで、Salesforce管理者は、安全で安定したSSO環境を構築・維持することができるでしょう。

にゃんこのSalesforce日記

このブログを検索