SSO・IDaaSLOCKED MSO

SAML認証の実装ガイド【仕様から設定まで完全解説】

公開日: 2026年3月11日

企業がクラウドサービスを導入する際、SAML（Security Assertion Markup Language）2.0 は事実上の認証標準となっています。Google Workspace、Microsoft 365、Salesforce、Slack など、ほぼ全ての主要 SaaS が SAML に対応しており、シングルサインオン (SSO)を実装する場合は、SAML の仕組みと設定方法を理解することが必須です。

本記事では、SAML 2.0 の基本的な仕組み、実装フロー、各ステップでの具体的な設定内容、LOCKED MSO による設定方法、そしてトラブルシューティング対策について、情シス担当者向けに詳しく解説します。

SAML 2.0 の基本概念と標準規格

SAML とは何か

SAML（Security Assertion Markup Language）は、OASIS（Organization for the Advancement of Structured Information Standards）が定める国際標準です。異なるシステム間で、ユーザー認証情報をセキュアに交換するためのプロトコルです。

SAML の重要な特徴：

XML形式：認証情報は XML 形式で表現され、人間が読める形式
署名・暗号化対応：認証情報に対して XML Digital Signature による署名、Assertion Encryption による暗号化が可能
メタデータ交換：SP（Service Provider）と IdP（Identity Provider）がメタデータを事前に交換することで、セキュリティ設定を標準化
エンタープライズ向け：大企業のセキュリティ要件を念頭に設計されており、金融機関、政府機関などで採用

SAML のバージョン：

SAML 2.0（2005年リリース）：現在の標準。大企業から中堅企業まで広く採用
SAML 3.0（提案段階）：次世代版として検討中だが、まだ採用企業は少ない

SAML が採用される理由は、セキュリティと相互運用性のバランスが取れており、大規模組織での運用に向いているためです。

SAML の登場人物：SP（Service Provider）と IdP（Identity Provider）

SAML による認証では、2つの主要なプレイヤーが登場します。

IdP（Identity Provider）：認証プロバイダー

ユーザーの認証を実施するシステム
ユーザーの ID、パスワード、多要素認証（MFA）を管理
認証後、SAML レスポンス（ユーザー情報含む）を SP に送信
企業側では LOCKED MSO などの IDaaS がこの役割を果たす

SP（Service Provider）：サービスプロバイダー

ユーザーが利用する実際のサービス・SaaS
IdP から受け取った SAML レスポンスを検証
検証後、ユーザーをサービスにログインさせる
Google Workspace、Salesforce、Slack などが SP の位置付け

SAML の 2 つの実装パターン

SAML には、認証フローの開始地点によって 2 つのパターンがあります。

パターン1：SP-initiated（SP側開始）

ユーザーが最初に Salesforce などの SP にアクセス → SP が IdP（LOCKED MSO）にリダイレクト → IdP で認証 → SP に戻ってセッション確立

利点：

ユーザーは普段のアクセス方法で問題ない
SP のログイン画面から SAML SSO に誘導可能

欠点：

IdP のポータル画面から直接ログインしたい場合、別途対応が必要

パターン2：IdP-initiated（IdP側開始）

ユーザーが LOCKED MSO のポータル画面にログイン → ポータルから Salesforce などのアプリケーションアイコンをクリック → IdP が自動的に SP に認証情報を送信 → SP にセッション確立

利点：

ユーザーは一度 IdP にログインすれば、複数アプリを簡単に利用可能
ワンクリックでアプリ起動できるユーザーフレンドリーな体験

欠点：

IdP が必ず稼働している必要がある

LOCKED MSO での実装：LOCKED MSO は両方のパターンに対応しており、企業のニーズに応じて選択できます。

RFPテンプレート（無料）

IDaaS導入RFPテンプレート

IDaaS導入の社内稟議に使えるRFPテンプレート。SSO、MFA、プロビジョニングなどの要件を網羅したフォーマットです。

無料でダウンロード

SAML 認証の具体的なフロー（6ステップ）

SAML による認証の全体フローを、具体的なステップで解説します。

ステップ1：ユーザーが SP（Salesforce など）にアクセス

ユーザーがブラウザで Salesforce の URL にアクセスします。この時点では、Salesforce はユーザーが認証されていないことを検知します。

裏側での処理：

Salesforce（SP）は、リクエストに含まれるユーザーセッションを確認
セッションがない、または有効期限切れの場合、ユーザーを IdP にリダイレクト

HTTP レベルでの処理：

ユーザーが https://salesforce.com/app にアクセス
   ↓
Salesforce が 302 リダイレクト応答を返す
Location: https://locked-idp.example.com/sso/saml/login?SAMLRequest=...

ステップ2：SAML リクエストが IdP に送信される

Salesforce から送信される SAML リクエストには、以下の情報が含まれます。

SAML リクエストの主要な要素：

SAMLRequest：Base64 エンコードされた XML
RelayState：リターン先 URL（認証後、元の画面に戻すため）
Issuer：Salesforce を識別する URI（例：urn:federation:MicrosoftOnline/salesforce.com）
AssertionConsumerServiceURL：認証後のレスポンスを受け取る URL（例：https://salesforce.com/saml/acs）
NameIDFormat：ユーザー識別子のフォーマット（urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress など）

LOCKED MSO での処理： LOCKED MSO は SAML リクエストを受け取り、リクエスト内容を検証します。

ステップ3：LOCKED MSO がユーザーに認証を要求

LOCKED MSO（IdP）はユーザーをログイン画面にリダイレクトします。

認証方式（設定に応じて）：

パスワード認証：LOCKED MSO 上のパスワードを入力
多要素認証（MFA）：
- SMS OTP：SMS で 6桁のコード受信
- OTP アプリ：Google Authenticator などで確認
- FIDO2 セキュリティキー：USB キー、NFC 認証
- 生体認証：指紋、顔（iOS/Android）
条件付き認証：ユーザー、デバイス、場所などの条件に応じて MFA を動的に要求

ユーザー体験：

LOCKED MSO のログイン画面を表示
ユーザーがメールアドレスとパスワード入力
MFA が有効な場合、追加認証を実施
認証成功

ステップ4：SAML レスポンスが生成される

認証に成功すると、LOCKED MSO（IdP）は SAML レスポンスを生成します。

SAML レスポンスの主要な要素：

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                ID="_8e8dc5f69a98cc4c1ff3427e5ce34606fd672f91e6"
                Version="2.0"
                IssueInstant="2024-03-06T10:15:00Z"
                Destination="https://salesforce.com/saml/acs">
  <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
    https://locked-idp.example.com
  </saml:Issuer>
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <!-- デジタル署名 -->
  </ds:Signature>
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </samlp:Status>
  <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
                  ID="_a9e1fe8345a6e5e6f0b6c8d1e2f3a4b5c6d7e8f9"
                  Version="2.0"
                  IssueInstant="2024-03-06T10:15:00Z">
    <saml:Issuer>https://locked-idp.example.com</saml:Issuer>
    <saml:Subject>
      <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
        user@example.com
      </saml:NameID>
      <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml:SubjectConfirmationData NotOnOrAfter="2024-03-06T10:20:00Z"
                                      Recipient="https://salesforce.com/saml/acs"/>
      </saml:SubjectConfirmation>
    </saml:Subject>
    <saml:AuthnStatement AuthnInstant="2024-03-06T10:15:00Z"
                         SessionIndex="_8e8dc5f69a98cc4c1ff3427e5ce34606fd672f91e6">
      <saml:AuthnContext>
        <saml:AuthnContextClassRef>
          urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
        </saml:AuthnContextClassRef>
      </saml:AuthnContext>
    </saml:AuthnStatement>
    <saml:AttributeStatement>
      <saml:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress">
        <saml:AttributeValue>user@example.com</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">
        <saml:AttributeValue>Taro</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">
        <saml:AttributeValue>Yamada</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute Name="department">
        <saml:AttributeValue>Sales</saml:AttributeValue>
      </saml:Attribute>
    </saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>

重要な要素の説明：

Signature：XML Digital Signature で、レスポンス全体の改ざんを検知
Issuer：IdP を識別（LOCKED MSO のメタデータに記載される URL）
NameID：ユーザーを一意に識別（メールアドレス、ユーザー ID など）
AuthnStatement：認証の日時、認証方式（パスワード、MFA など）
AttributeStatement：ユーザーの属性情報（メール、名前、部門など）
NotOnOrAfter：レスポンスの有効期限（デフォルト 5 分）

ステップ5：SAML レスポンスが SP に送信される

LOCKED MSO（IdP）は SAML レスポンスを SP（Salesforce）に返します。通常は POST メソッドで、ブラウザの自動ポストメカニズムを使用します。

HTML 形式のレスポンス：

<html>
  <body onload="document.forms[0].submit()">
    <form method="POST" action="https://salesforce.com/saml/acs">
      <input type="hidden" name="SAMLResponse" value="PHNhbWxwOlJlc3BvbnNl..."/>
      <input type="hidden" name="RelayState" value="/app/dashboard"/>
      <noscript>
        <p>JavaScript is disabled. Click the button below to continue:</p>
        <input type="submit" value="Continue"/>
      </noscript>
    </form>
  </body>
</html>

仕組み：

HTML ページがロードされると、JavaScript の onload イベントで自動的にフォームを送信
SAMLResponse と RelayState が POST で SP に送信
JavaScript が有効でない場合は、ユーザーが手動で送信ボタンをクリック

ステップ6：SP がレスポンスを検証してセッション確立

Salesforce（SP）は SAML レスポンスを受け取り、以下の検証を実施します。

SP での検証処理：

署名検証：
- SAML レスポンスが LOCKED MSO の秘密鍵で署名されているかを確認
- LOCKED MSO のメタデータから公開鍵を取得
- 公開鍵を使用して署名を検証
- 署名が無効な場合、認証を拒否
Issuer 検証：
- Issuer が事前設定された IdP（LOCKED MSO）のものか確認
- 異なる IdP からのレスポンスは拒否
Destination 検証：
- Destination フィールドが自システムの ACS（Assertion Consumer Service）URL と一致するかを確認
- 異なる宛先の場合、リプレイ攻撃の可能性として拒否
NotOnOrAfter 検証：
- 現在時刻がレスポンスの有効期限を超えていないかを確認
- デフォルト 5 分以上古いレスポンスは拒否（リプレイ攻撃防止）
NameID 抽出：
- SAML レスポンスから NameID（ユーザー識別子）を抽出
- NameID 形式が設定と一致するかを確認
属性情報の抽出：
- メール、名前、部門などの属性を抽出
- Salesforce 上の対応するフィールドにマッピング

セッション確立：

すべての検証が成功した場合、Salesforce はユーザーセッションを作成
セッショントークン（Cookie）をブラウザに設定
RelayState で指定された URL（元のアクセス先）にリダイレクト
ユーザーは Salesforce にシングルサインオンで自動的にログイン

SAML メタデータの構造と交換プロセス

メタデータとは

SAML メタデータは、IdP と SP が相互に認証フローを実施するための設定情報を定義する XML ファイルです。メタデータ交換を事前に行うことで、セキュアな SAML 連携が可能になります。

IdP メタデータの主要要素：

<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
                  entityID="https://locked-idp.example.com">
  <IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <!-- 署名用の公開鍵 -->
    <KeyDescriptor use="signing">
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <X509Data>
          <X509Certificate>MIICajCCAdOgAwIBAgI...</X509Certificate>
        </X509Data>
      </KeyInfo>
    </KeyDescriptor>

    <!-- ユーザー認証を実施する URL -->
    <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
                         Location="https://locked-idp.example.com/sso/saml"/>

    <!-- サポートしている NameID フォーマット -->
    <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>
  </IDPSSODescriptor>
</EntityDescriptor>

重要な情報：

entityID：IdP を一意に識別する URI
X509Certificate：署名検証用の公開鍵（PKCS#8 または PEM 形式）
SingleSignOnService Location：SAML SSO を実施する URL

SP メタデータの主要要素：

<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
                  entityID="https://salesforce.com">
  <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <!-- SAML レスポンスを受け取る URL -->
    <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
                              Location="https://salesforce.com/saml/acs"
                              index="1"/>
  </SPSSODescriptor>
</EntityDescriptor>

メタデータ交換プロセス

手順：

Salesforce（SP）のメタデータを LOCKED MSO（IdP）に登録
- Salesforce のメタデータ URL（例：https://salesforce.com/metadata）をコピー
- LOCKED MSO の管理画面で、メタデータ URL を指定するか、メタデータ XML をアップロード
- LOCKED MSO がメタデータを検証し、SP の設定情報を取得
LOCKED MSO のメタデータを Salesforce に登録
- LOCKED MSO のメタデータ URL をコピー（例：https://locked-idp.example.com/saml/metadata）
- Salesforce 管理画面の SAML 設定で、IdP メタデータ URL を指定
- Salesforce がメタデータを自動取得・検証

メタデータ交換のメリット：

手動設定を最小化（メタデータ URL の指定のみ）
証明書の更新が自動的に反映される（メタデータが更新される場合）
セキュリティ設定が標準化される

LOCKED MSO での SAML SSO 設定手順

ステップ1：アプリケーションの登録

LOCKED MSO 管理画面で、Salesforce などの SAML 対応 SaaS を登録します。

操作手順：

LOCKED MSO 管理画面にログイン
左メニューから「アプリケーション」を選択
「アプリケーション追加」ボタンをクリック
アプリケーション一覧から「Salesforce」を選択（またはカスタム SAML アプリを選択）
以下の情報を入力：
- アプリケーション名：任意の名前（例：「Salesforce」）
- 説明：オプション
- ロゴ：ポータルに表示するロゴ画像（オプション）
「登録」ボタンで確定

ステップ2：SAML メタデータの取得

LOCKED MSO のメタデータを Salesforce に登録する必要があります。

操作手順：

登録したアプリケーション「Salesforce」をクリック
「SAML 設定」タブを選択
「IdP メタデータ」セクションで、メタデータ URL または XML をコピー
- メタデータ URL：https://locked-idp.example.com/saml/app-name/metadata
- XML ダウンロード：メタデータを XML ファイルとしてダウンロード

ステップ3：Salesforce 側での SAML 設定

LOCKED MSO から取得したメタデータを Salesforce に登録します。

Salesforce での操作：

Salesforce 管理画面にログイン
「設定」→「セキュリティ」→「シングルサインオン設定」を選択
「編集」ボタンをクリック
以下の情報を入力：
- シングルサインオンプロトコル：SAML 2.0
- Identity Provider Metadata：LOCKED MSO のメタデータ XML をペーストするか、メタデータ URL を入力
「保存」ボタンで設定完了
設定後、Salesforce は自動的に LOCKED MSO のメタデータを検証・取得

ステップ4：属性マッピングの設定

SAML レスポンスに含まれるユーザー属性を、Salesforce 上のフィールドにマッピングします。

LOCKED MSO 管理画面での設定：

登録したアプリケーション「Salesforce」をクリック
「属性マッピング」タブを選択
LOCKED MSO の属性を Salesforce のフィールドにマッピング：

LOCKED MSO の属性	Salesforce フィールド	説明
Email	email	ユーザーのメールアドレス
FirstName	firstName	名前
LastName	lastName	姓
Department	department	部門
JobTitle	jobTitle	職位
Manager	manager	マネージャー

マッピングの例：

LOCKED MSO ユーザー属性「Email」→ Salesforce「email」フィールド
LOCKED MSO ユーザー属性「FirstName」→ Salesforce「firstName」フィールド

ステップ5：テストと検証

SAML SSO が正しく動作するかをテストします。

テスト手順：

LOCKED MSO の管理画面で、テストユーザーで試行ログイン
別のブラウザまたはプライベートウィンドウで、Salesforce の SAML SSO ログインをテスト
LOCKED MSO のログイン画面が表示されることを確認
テストユーザーでログイン
Salesforce に自動的にログインされることを確認
ユーザー属性（名前、メール、部門など）が正しく表示されていることを確認

トラブルシューティング：

エラーメッセージ	原因	対策
"Authentication failed"	メタデータ URL が誤っている、または署名検証失敗	メタデータ URL を再確認、LOCKED MSO の公開鍵が Salesforce に正しく登録されているか確認
"NameID mismatch"	SAML レスポンスの NameID フォーマットが設定と異なる	LOCKED MSO と Salesforce の NameID フォーマット設定を一致させる
"Assertion expired"	SAML レスポンスの有効期限を超えている	LOCKED MSO と Salesforce の時刻をNTP で同期確認
ユーザー属性が空白	属性マッピングが正しくない	LOCKED MSO の属性マッピング設定を確認、Salesforce のフィールド名が正確か確認

SAML のセキュリティベストプラクティス

1. XML Signature による改ざん検知

SAML レスポンスには必ず XML Digital Signature で署名を施し、改ざんを検知できるようにします。

実装のポイント：

IdP（LOCKED MSO）が秘密鍵で署名を生成
SP（Salesforce）が IdP の公開鍵で署名を検証
署名アルゴリズム：SHA-256 以上の強力なハッシュ関数を使用
LOCKED MSO はデフォルトで XML Signature に対応

2. TLS/HTTPS による通信暗号化

IdP と SP 間の通信、特に SAML レスポンス送信時は、必ず HTTPS（TLS 1.2 以上）を使用します。

実装のポイント：

全ての SAML 通信は HTTPS で実施
SSL/TLS 証明書は信頼された認証局（CA）から取得
LOCKED MSO は HTTPS のみサポート

3. タイムスタンプ検証によるリプレイ攻撃防止

SAML レスポンスに NotOnOrAfter タイムスタンプを設定し、古いレスポンスの再利用を防止します。

実装のポイント：

デフォルト有効期限：5 分
必要に応じて短縮可能（例：1 分）
IdP と SP の時刻を NTP で同期

4. Assertion Encryption による暗号化

SAML Assertion を暗号化し、認証情報の漏洩を防止します（オプション）。

実装のポイント：

SP の公開鍵で Assertion を暗号化
SP が秘密鍵で復号
LOCKED MSO はオプションで Assertion 暗号化に対応

SAML 実装時の注意点とトラブルシューティング

注意点1：メタデータの定期更新

SAML メタデータ内の証明書には有効期限があります。期限切れ前に更新する必要があります。

対策：

メタデータの更新周期をモニタリング（通常 1～2年）
期限切れ 3ヶ月前に更新作業をスケジュール
可能であれば、メタデータ URL での自動更新を設定

注意点2：複数の IdP への対応（フェデレーション）

1 つの SP に対して複数の IdP（例：Okta と LOCKED MSO）から認証する場合、メタデータ管理が複雑化します。

対策：

Federation メタデータを使用
SAML メタデータ検出（Discovery）機能を活用

注意点3：モバイルアプリとの連携

モバイルアプリは HTTP リダイレクト（Redirect Binding）に対応していないことがあります。

対策：

POST Binding または SAML Bearer Token を使用
LOCKED MSO の API ベースの認証（REST API）を活用

まとめ：SAML は最強のエンタープライズ認証標準

SAML 2.0 は、OASIS 標準に基づき、セキュリティと相互運用性のバランスが取れた認証プロトコルです。企業が複数の SaaS を安全に統合管理するには、SAML の仕組みを理解し、正しく実装することが必須です。

LOCKED MSO は、SAML 2.0 に完全対応し、メタデータ交換から属性マッピング、トラブルシューティングまで、一元的にサポートしています。

次のステップ： LOCKED MSO の無料デモで、SAML SSO の実装、テスト、運用を体験してください。

LOCKEDの詳細を見る

SAML認証・SSO でお悩みなら、LOCKEDの無料デモをお試しください。

資料請求・デモ依頼はこちら →

SAML認証の実装ガイド【仕様から設定まで完全解説】

SAML 2.0 の基本概念と標準規格

SAML とは何か

SAML の登場人物：SP（Service Provider）と IdP（Identity Provider）

SAML の 2 つの実装パターン

IDaaS導入RFPテンプレート

SAML 認証の具体的なフロー（6ステップ）

ステップ1：ユーザーが SP（Salesforce など）にアクセス

ステップ2：SAML リクエストが IdP に送信される

ステップ3：LOCKED MSO がユーザーに認証を要求

ステップ4：SAML レスポンスが生成される

ステップ5：SAML レスポンスが SP に送信される

ステップ6：SP がレスポンスを検証してセッション確立

SAML メタデータの構造と交換プロセス

メタデータとは

メタデータ交換プロセス

LOCKED MSO での SAML SSO 設定手順

ステップ1：アプリケーションの登録

ステップ2：SAML メタデータの取得

ステップ3：Salesforce 側での SAML 設定

ステップ4：属性マッピングの設定

ステップ5：テストと検証

SAML のセキュリティベストプラクティス

1. XML Signature による改ざん検知

2. TLS/HTTPS による通信暗号化

3. タイムスタンプ検証によるリプレイ攻撃防止

4. Assertion Encryption による暗号化

SAML 実装時の注意点とトラブルシューティング

注意点1：メタデータの定期更新

注意点2：複数の IdP への対応（フェデレーション）

注意点3：モバイルアプリとの連携

まとめ：SAML は最強のエンタープライズ認証標準

参考リンク

関連記事

この課題、LOCKEDで解決できます

LOCKEDシリーズの詳細資料を無料でダウンロード

関連記事

SAML 2.0仕様書日本語詳解【RFC 7114準拠実装】

SAML統合ベストプラクティス【属性マッピングから運用まで】

SAML vs OAuth完全比較【プロトコル仕様から実装まで】

Azure AD SAML連携完全手順【証明書管理までの全手順】

OneLogin SAML設定ガイド【メタデータ取得から実装まで】

アクセス制御ルール完全ガイド【12項目で柔軟な権限管理実現】

まずは資料で詳細を確認