MENU

Microsoft Entra IDのフェデレーションメタデータXMLと公開証明書(Base64)を含めない設定と回避策

Azure

Microsoft Entra ID で SAML シングルサインオンを構成するとき、「フェデレーション メタデータXMLに公開証明書（Base64）が含まれてしまうがセキュリティ的に問題ないのか」「証明書を外した形で配布できないのか」という疑問をよく耳にします。本記事では、その仕組みと仕様、実務で取りうる選択肢や運用ポイントを、管理者目線で詳しく整理します。

目次

Microsoft Entra ID のフェデレーション メタデータXMLとは

まず前提として、「フェデレーション メタデータXML」が何者なのかを整理しておきます。Microsoft Entra ID（旧 Azure AD）は、WS-Federation / SAML 2.0 の仕様に基づいて、IdP（Identity Provider）としての情報を 1 つの XML ドキュメントにまとめたものを公開しています。

典型的なメタデータのエンドポイント URL は次のような形です。

https://login.microsoftonline.com/<TenantDomainName>/FederationMetadata/2007-06/FederationMetadata.xml

ここで <TenantDomainName> にはテナントのドメイン名（例: contoso.onmicrosoft.com）やテナント ID（GUID）が入ります。

この XML には、主に次のような情報が含まれます。

  • エンティティ ID（IdP を一意に識別する文字列）
  • SAML/WS-Fed のエンドポイント URL（シングルサインオン / シングルサインアウト）
  • サポートするプロトコルやバインディング情報
  • トークン署名に使用する公開証明書（X.509, Base64）

特に最後の「公開証明書」は、サービスプロバイダー（SP）が SAML トークンの署名を検証するための重要な材料であり、メタデータの本質的な構成要素です。Microsoft の公式ドキュメントでも、「トークンに署名するための公開証明書が KeyDescriptor 要素の中に公開されている」と説明されています。

要素役割XML 内の代表的な要素
エンティティ IDIdP を一意に識別する IDEntityDescriptor entityID="..."
エンドポイントSSO / SLO の接続先 URLSingleSignOnService / SingleLogoutService
公開証明書トークン署名を検証するための鍵情報KeyDescriptor > X509Certificate

なぜ公開証明書（Base64）がメタデータXMLに含まれるのか

SAML/WS-Fed の世界では、「IdP が発行したトークンの署名を SP が検証する」ことで、なりすましや改ざんを防ぎます。そのためには、SP 側が IdP の公開鍵を事前に知っている必要があります。

この公開鍵を SAML 仕様では X.509 証明書として表現し、メタデータ XML の中では次のような形で格納します。

&lt;md:KeyDescriptor use="signing"&gt;
  &lt;ds:KeyInfo&gt;
    &lt;ds:X509Data&gt;
      &lt;ds:X509Certificate&gt;
        MIIC...Base64...ABCD==
      &lt;/ds:X509Certificate&gt;
    &lt;/ds:X509Data&gt;
  &lt;/ds:KeyInfo&gt;
&lt;/md:KeyDescriptor&gt;

SP はこの公開証明書を取り込み、SAML レスポンスの署名検証に利用します。Microsoft Entra ID のフェデレーション メタデータも同じ仕様に従っていて、トークン署名用の公開証明書が Base64 で埋め込まれています。

加えて、証明書更新（ロールオーバー）のタイミングでは、新旧両方の証明書がメタデータに並んで掲載されることがあり、SP はどちらの証明書でも署名検証できるように実装しておくことが推奨されています。

公開証明書をメタデータXMLから「含めない」設定はできるのか？

結論：Entra ID 側の設定で除外することはできない

2025 年時点で、Microsoft Entra ID のポータルや API（Microsoft Graph など）には、

  • 「フェデレーション メタデータXMLから公開証明書要素を除外する」
  • 「KeyDescriptor 要素を出力しない」

といった設定項目は提供されていません。

公式ドキュメントも、「メタデータにはトークン署名に使用する証明書の公開部分が含まれる」という前提で説明が組み立てられており、これを無効化する方法は記載されていません。

また、Entra ID で SAML ベースのシングルサインオンを設定するとき、ポータルの「SAML 証明書（SAML Signing Certificate）」セクションに「フェデレーション メタデータXML」「App Federation Metadata Url」などのリンクが表示されますが、ここにも証明書の出力有無を切り替えるオプションは存在しません。

項目可否備考
メタデータXMLから公開証明書を自動的に除外する設定不可Entra ID の仕様上、設定項目が存在しない
証明書の有効期限やロールオーバー設定可証明書の有効期間やロールオーバーは構成可能
メタデータXMLそのものを使用せず、手動で構成可SP 側が手動入力に対応していることが前提

実務で取りうる 3 つの選択肢

1. 既定どおり公開証明書を含めて配布する（推奨）

もっとも標準的でトラブルが少ないのは、Entra ID が出力するフェデレーション メタデータXMLをそのまま SP に渡す運用です。

多くの SaaS 製品や自社システムの SAML 構成画面では、次のような手順が推奨されています。

  • Microsoft Entra ID の「SAML ベースのシングルサインオン」画面を開く
  • 「フェデレーション メタデータXML」または「App Federation Metadata Url」をダウンロード / コピー
  • SP 側の「メタデータのインポート」機能に読み込ませる

この方法には次のようなメリットがあります。

  • SP 側がエンティティ ID、エンドポイント、証明書を自動で取得するため設定ミスが起きにくい
  • 証明書がロールオーバーされるとき、メタデータの更新だけで SP 側が追随できる設計を取りやすい
  • 「公開証明書」はそもそも公開前提の情報であり、秘匿する必要がない

一方で、「文書に鍵情報を載せない」という社内ポリシーがある場合には、メタデータ XML だけ浮いてしまうことがあります。その場合は、公開鍵と秘密鍵の違いを踏まえてポリシー側を見直すのが、本質的には一番筋が通っています。この点は後述の「セキュリティ観点」で詳しく整理します。

観点評価コメント
セキュリティ高SP が署名検証できる前提を維持できる
運用負荷低メタデータのインポートに任せられる
標準性非常に高いSAML の一般的なベストプラクティス

2. メタデータを使わず「手動で」SAML 連携を構成する

どうしてもメタデータ XML を渡したくない場合、SP の管理画面に対して次の情報を「手入力」する方法があります。

  • IdP のエンティティ ID
  • シングルサインオン URL（ログイン URL）
  • シングルログアウト URL（必要に応じて）
  • SAML のバインディング方式（多くは HTTP-Redirect / HTTP-POST）
  • トークン署名用公開証明書（必要な場合）

多くの SP は、「メタデータ XML の URL を入れる方法」または「これらの情報を個別に入力する方法」のどちらか、あるいは両方をサポートしています。

手動構成を選ぶ場合の注意点は次の通りです。

  • 証明書を別経路（メール、チケット、構成管理システム等）で共有する必要がある
  • 証明書を更新したときに、SP 側の設定も必ず手動で更新しなければならない
  • SP が「署名必須」「アサーション署名必須」の場合は、公開証明書を登録しないと連携が成立しない

メタデータ XML を一切使わないため、「XML に証明書が書いてあるのは避けたい」という要件は満たせますが、その代わりに運用の手間とヒューマンエラーのリスクが増えます。

3. XML を手作業で編集し、証明書要素を削除したファイルを配布する（非推奨）

技術的には、Entra ID からダウンロードしたフェデレーション メタデータ XML をテキストエディタで開き、

  • <KeyDescriptor> ... </KeyDescriptor> 要素丸ごと
  • あるいは <ds:X509Certificate>...</ds:X509Certificate> 部分

を削除してから SP に渡す、というやり方も不可能ではありません。

しかしこの方法には次のようなリスクがあります。

  • SP 側がメタデータのスキーマチェックを行っている場合、取り込みに失敗する可能性がある
  • 署名検証に使う鍵情報が無いため、アプリによっては SAML 連携自体が動作しない
  • 証明書ロールオーバー時に、新しい証明書を毎回 XML に手で追記・修正する必要がある
  • Entra ID の管理画面から再度ダウンロードすると、当然ながら証明書は再び含まれるため、恒久的な解決策にはならない

したがって、これはどうしても XML を第三者に渡す必要があり、その第三者には証明書を見せたくないといった特殊ケース以外では、おすすめできません。

観点評価コメント
セキュリティ中証明書を隠せるが、そもそも公開情報である
運用負荷高更新のたびに手編集が必要
サポート性低ベンダーサポートの対象外になるおそれ

セキュリティ観点で整理：公開証明書は「公開前提」の情報

公開鍵と秘密鍵の役割の違い

SAML の議論では、しばしば「証明書＝鍵＝秘密情報」という誤解が生じがちです。しかし実際には次のように役割が分かれています。

種類役割取り扱い
秘密鍵トークンに署名する / 証明書を発行するときの署名に使う最重要機密。IdP の管理者のみが保持
公開鍵署名されたトークンの検証に使うSP やクライアントに配布してよい
X.509 証明書公開鍵に所有者情報や有効期限を付与した「公開鍵の名刺」通常は広く公開してよい（公開鍵そのもの）

フェデレーション メタデータ XML に含まれているのは、このうち公開鍵を含んだ X.509 証明書です。秘密鍵は Entra ID 側にのみ保持され、XML に含まれることはありません。

そのため、公開証明書が XML に含まれていること自体は、機密性の観点では問題にならないケースが大半です。守るべきはあくまで秘密鍵の保護と証明書の適切なライフサイクル管理です。

「証明書を載せるな」という社内ルールへの向き合い方

もし社内の情報セキュリティポリシーや監査基準に、「鍵情報を文書に記載してはならない」という一文があり、それが原因でメタデータ XML が問題視されている場合、次のような説明・整理を行うと建設的です。

  • 当該 XML に含まれているのは「秘密鍵」ではなく公開鍵付き証明書であり、仕様上、SP に渡すことが前提である
  • 公開鍵は外部公開を前提とした情報であり、証明書検証や署名検証のために広く配布される性質のものである
  • 証明書を非公開にすることは、一般的にはセキュリティ強化にならず、むしろ SP 側が署名検証できなくなるリスクを増やす

このような背景を踏まえたうえで、ポリシーの文言を「秘密鍵やパスワード等の機密情報を文書に含めない」といった形に修正し、公開鍵や証明書を明示的に除外するのが理想です。

運用観点：証明書の有効期限とロールオーバー

Entra ID の SAML 証明書には有効期限があり、既定では数年単位（多くは 3 年）で自動生成されます。

有効期限が近づくと、Entra ID は新しい証明書を発行し、フェデレーション メタデータの中に新旧両方の証明書を掲載します。SP 側がこのメタデータを定期的に取得していれば、証明書ロールオーバーを無停止で乗り切ることが可能です。

一方、メタデータを使わない運用や、手編集した XML を配布する運用では、次のような追加作業が発生します。

  • 新しい証明書を発行するたびに、SP 側管理者へ事前連絡を行う
  • SP 側の設定画面で公開証明書を入れ替えてもらう
  • 切り替えのタイミングでサービス影響が出ないよう、タイムスケジュールを綿密に調整する

特に、24 時間 365 日稼働の業務システムや、多数のテナント・顧客が存在するマルチテナントサービスでは、手動運用のコストは非常に大きくなります。そのため、メタデータに証明書を含め、そのメタデータを SP 側で自動または半自動的に取り込む設計が、長期的にはもっとも安全で運用しやすい選択になります。

Entra ID ポータルでの確認ポイント

実際に Microsoft Entra 管理センターで設定を確認する際のポイントも整理しておきます。

  1. Microsoft Entra 管理センターにサインインする
  2. アプリケーション > エンタープライズ アプリケーション を開く
  3. 対象のギャラリー外 SAML アプリケーションを選択する
  4. シングル サインオン > SAML を選択する
  5. SAML 証明書（SAML Signing Certificate） セクションで、以下を確認する
    • フェデレーション メタデータXML（XML ファイルのダウンロード）
    • App Federation Metadata Url（SP に URL を渡す場合に使用）
    • 証明書（Base64） / 証明書（バイナリ） のダウンロードリンク
    • 証明書の有効期限とロールオーバーの状態

ここでダウンロードできる「フェデレーション メタデータXML」には、今回のテーマである公開証明書が含まれていることを確認できます。Entra ID の UI を見る限り、これを除外するオプションはありません。

XML 内で公開証明書がどのように記述されているか

イメージがしやすいよう、Entra ID が発行するメタデータに近い形のサンプルを示します（実際の値はダミーです）。

&lt;EntityDescriptor entityID="https://sts.windows.net/xxxx-xxxx-xxxx-xxxx/" ...&gt;
  &lt;IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"&gt;
    &lt;KeyDescriptor use="signing"&gt;
      &lt;ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"&gt;
        &lt;ds:X509Data&gt;
          &lt;ds:X509Certificate&gt;
            MIID...Base64 形式の公開証明書...ABCD==
          &lt;/ds:X509Certificate&gt;
        &lt;/ds:X509Data&gt;
      &lt;/ds:KeyInfo&gt;
    &lt;/KeyDescriptor&gt;
    ...
  &lt;/IDPSSODescriptor&gt;
&lt;/EntityDescriptor&gt;

この ds:X509Certificate 部分が、ポータルの「証明書（Base64）」ダウンロードリンクから取得できる内容と実質的に同じものです。メタデータから証明書を削除するというのは、まさにこのブロックを削除する作業に相当します。

繰り返しになりますが、ここに含まれるのは公開鍵であり、秘密鍵ではないことがポイントです。

社内規程・監査向けの説明例

「なぜフェデレーション メタデータ XML に証明書が含まれているのか」を監査担当やセキュリティ部門に説明する際に使える、簡易な説明例を示します。

  • この XML は、Microsoft Entra ID（IdP）と外部サービス（SP）の間で信頼を確立するための標準的なメタデータです。
  • XML に含まれる証明書は、トークン署名を検証するための公開鍵であり、秘密鍵やパスワードなどの機密情報は一切含まれません。
  • 公開鍵を配布することで、SP 側が「Entra ID が発行したトークンである」ことを確認でき、むしろセキュリティを高める役割を果たします。
  • 多くの SaaS ベンダーや Microsoft 自身のドキュメントも、このメタデータを利用することを前提に設計されています。
  • もし証明書を XML から削除すると、SP 側が署名検証を行えず、セキュリティレベルの低下や接続エラーにつながる可能性があります。

このように、「公開情報を適切に公開している」というスタンスで説明すると、社内の理解を得やすくなります。

どの選択肢を選ぶべきかの判断材料

ここまでの内容を踏まえ、3 つの選択肢をざっくり比較すると次のようになります。

選択肢主なメリット主なデメリット向いているケース
既定どおりメタデータを利用（証明書を含める）標準的・自動化しやすい・ベンダーサポートを受けやすい社内ルール次第では説明コストが発生するほとんどの一般的な SAML 連携
メタデータを使わず手動構成「XML に証明書を含めない」という要件を満たせる更新時の手作業・設定ミスのリスクSP がメタデータに対応していない、または社内ルールで XML 配布が制限される場合
XML を手編集して証明書を削除第三者に証明書を見せたくない特殊ケースでのみ有効サポート外・運用負荷大・エラー原因になりやすい一時的で限定的な用途（非推奨）

実務的には、次のようなステップで判断するのがおすすめです。

  1. まずは「既定のメタデータXMLをそのまま利用する」前提で設計する
  2. 社内規程・監査の観点で懸念が出た場合は、「公開証明書である」点を丁寧に説明する
  3. それでも NG となる場合にのみ、SP 側の要件を確認したうえで「手動構成」に切り替える
  4. XML 手編集は最後の手段とし、影響範囲を極小に限定する

関連ドキュメント・参考情報

  • Microsoft Docs: Federation metadata – Microsoft identity platform（メタデータに含まれる情報と KeyDescriptor の説明）
  • Microsoft Docs: Tutorial – Manage federation certificates in Microsoft Entra ID（SAML 証明書とフェデレーション メタデータ XML の管理）
  • Microsoft Q&A: SAML Certificates の有効期限に関する説明（既定は 3 年で自動生成）
  • 各種 SaaS ベンダーのドキュメント（例：iManage、Qlik、他）における「Entra ID からフェデレーション メタデータ XML をダウンロードしてインポートする」手順

まとめ：基本方針は「証明書を含めたメタデータを使う」

Microsoft Entra ID のフェデレーション メタデータ XML に公開証明書（Base64）が含まれるのは、SAML/WS-Fed の仕様に沿った、ごく自然な挙動です。Entra ID 側に「証明書を XML から除外する」設定は存在せず、技術的に無理に削除すると、SP 側の署名検証を阻害したり、ロールオーバー時の運用負荷を増やしてしまいます。

したがって、実務的なベストプラクティスは、

  • 公開証明書は公開前提の情報であることを理解し、
  • メタデータ XML に証明書を含めたまま SP と連携する

というシンプルな方針です。そのうえで、どうしても社内ルール等との整合が取れない場合に限り、手動構成や限定的な手編集といった回避策を検討するとよいでしょう。

フェデレーション メタデータ XML を正しく理解し、公開証明書の扱いを整理しておくことで、Microsoft Entra ID と各種 SaaS / 自社システム間の SAML 連携を、より安全かつ安定して運用できるようになります。

Azure
Microsoft Entra ID SAML シングルサインオン フェデレーションメタデータ 公開証明書

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次