Identity Federation

IDフェデレーション（Identity Federation）とは、異なる組織やセキュリティドメイン間で、ユーザーのID情報と認証結果を安全に共有・連携する仕組みです。フェデレーションにより、ユーザーは自組織のアカウントで他組織やクラウドサービスにアクセスでき、サービスごとに別々のアカウントを作成・管理する必要がなくなります。

フェデレーションの基盤となるのが信頼関係（Trust Relationship）です。IDプロバイダー（IdP）とサービスプロバイダー（SP）の間で事前に信頼関係を確立し、IdPが発行する認証トークン（SAMLアサーション、OIDCトークン等）をSPが検証して受け入れます。この仕組みにより、パスワードそのものを外部に渡すことなく、認証済みであるという事実のみを安全に伝達できます。

フェデレーションは現代のクラウドファースト環境において不可欠な技術であり、SAML 2.0やOpenID Connect（OIDC）が主要なプロトコルとして利用されています。しかし、信頼関係の設定ミスやトークンの取り扱い不備は、クロスドメインでの大規模な情報漏洩や不正アクセスに直結するため、慎重な設計と運用が求められます。

フェデレーションの基本概念と信頼モデル

フェデレーションでは、IDプロバイダー（IdP）がユーザーの認証を行い、サービスプロバイダー（SP）がIdPの発行したトークンに基づいてサービスへのアクセスを許可します。この分離により、SPは自前で認証基盤を構築する必要がなく、IdP側でのMFA導入やパスワードポリシーの強化が全連携先に波及します。

信頼関係は通常、メタデータ交換（証明書、エンドポイントURL、エンティティIDなど）によって確立されます。IdPとSP間で公開鍵証明書を交換し、トークンのデジタル署名を検証することで、なりすましや改ざんを防止します。

SAMLフェデレーション

SAML（Security Assertion Markup Language）2.0は、XMLベースのフェデレーション標準規格であり、エンタープライズ環境で最も広く採用されています。SAMLフェデレーションでは、IdPがXMLベースのSAMLアサーションを発行し、ユーザーの認証状態、属性情報（氏名、メールアドレス、所属グループ等）、認可情報を含めてSPに伝達します。

SAMLフェデレーションにはSP-Initiated（SP起点）とIdP-Initiated（IdP起点）の2つのフローがあります。SP-Initiatedフローでは、ユーザーがSPにアクセスすると未認証の場合にIdPにリダイレクトされ、認証後にSAMLレスポンスとともにSPに戻ります。IdP-Initiatedフローでは、ユーザーがIdPのポータルからSPを選択してアクセスします。

OIDCフェデレーション

OpenID Connect（OIDC）は、OAuth 2.0の上に構築された認証レイヤーであり、REST/JSONベースの軽量なフェデレーション標準です。SAMLがXMLベースで重量級であるのに対し、OIDCはJWT（JSON Web Token）を使用したコンパクトなトークン形式を採用しており、モバイルアプリやSPA（シングルページアプリケーション）との親和性が高い点が特徴です。

OIDCフェデレーションでは、IdPがIDトークン（JWTフォーマット）を発行し、ユーザーの認証情報とクレーム（属性情報）を含めます。SPはIDトークンの署名を検証し、issuer（発行者）やaudience（対象者）が正しいことを確認した上で、ユーザーのアクセスを許可します。

B2Bフェデレーション

B2Bフェデレーションは、取引先企業やパートナー組織との間でID連携を行う仕組みです。従来、外部パートナーがシステムにアクセスするためには、自社でゲストアカウントを発行・管理する必要がありましたが、B2Bフェデレーションにより、パートナーは自組織のアカウントのまま連携先のリソースにアクセスできます。

Microsoft Entra ID（旧Azure AD）のB2Bコラボレーションや、AWS IAMのクロスアカウントロールは、B2Bフェデレーションの代表的な実装例です。ただし、外部組織のセキュリティレベルは自社と異なる場合が多いため、条件付きアクセスポリシーやJust-In-Timeアクセスの適用が重要となります。

クロスドメインID連携の課題

フェデレーションでは異なるセキュリティドメイン間でID情報を共有するため、属性マッピングの不一致が大きな課題となります。例えば、IdP側の「社員番号」とSP側の「ユーザーID」の対応関係が曖昧な場合、誤ったアカウントに権限が付与されるリスクがあります。

また、ジャストインタイムプロビジョニング（JIT Provisioning）により、初回フェデレーションログイン時にSP側でアカウントを自動作成する場合、退職者のアカウント無効化（デプロビジョニング）がIdP側の操作だけでは完結しない問題があります。SCIM（System for Cross-domain Identity Management）との連携による自動化が推奨されます。

フェデレーション設定のセキュリティリスク

フェデレーション設定の不備は、深刻なセキュリティインシデントに直結します。代表的なリスクとして、署名検証の不備（SAMLアサーションやJWTの署名を検証しない、または弱い検証しか行わない）、Audience制限の欠如（トークンが意図しないSPで受け入れられる）、リプレイ攻撃への脆弱性（一度使用されたトークンの再利用を防止しない）があります。

特に危険なのがゴールデンSAML攻撃です。攻撃者がIdPのトークン署名鍵を窃取した場合、任意のユーザーになりすます有効なSAMLアサーションを無制限に生成でき、フェデレーションで連携されたすべてのサービスに不正アクセスが可能となります。

• 01
  トークン署名の厳格な検証：SAMLアサーションの署名やJWTの署名を必ず検証し、信頼するIdPの公開鍵のみを受け入れてください。署名アルゴリズムのダウングレード攻撃（SHA-1への強制変更やアルゴリズム「none」の受け入れなど）を防ぐため、許可するアルゴリズムを明示的にホワイトリスト化しましょう。
• 02
  AudienceとRecipientの厳密な制限：SAMLアサーションのAudience Restriction（対象SP制限）やJWTのaud（audience）クレームを必ず検証し、自社のエンティティID/クライアントIDと完全一致することを確認してください。他のSP向けに発行されたトークンを誤って受け入れるリスクを排除します。
• 03
  リプレイ攻撃の防止：SAMLアサーションのInResponseToとNotOnOrAfter条件、JWTのjti（JWT ID）とexp（有効期限）を検証し、使用済みトークンのIDをキャッシュに記録して再利用を防止してください。トークンの有効期間は必要最小限（数分〜十数分）に設定しましょう。
• 04
  IdP署名鍵の厳重な保護とローテーション：ゴールデンSAML攻撃を防止するため、IdPのトークン署名用秘密鍵をHSM（ハードウェアセキュリティモジュール）で保護し、定期的にローテーションしてください。鍵のローテーション時には、SP側のメタデータも速やかに更新する運用手順を確立しましょう。
• 05
  フェデレーション信頼関係の定期的な棚卸し：確立済みのフェデレーション信頼関係を定期的に棚卸しし、不要な連携先を削除してください。特にB2Bフェデレーションでは、取引終了したパートナー企業との信頼関係が残存していないか確認し、攻撃対象面を最小化しましょう。
• 06
  条件付きアクセスポリシーの適用：フェデレーション経由のアクセスに対して、接続元IPアドレス、デバイスコンプライアンス状態、MFA状態などに基づく条件付きアクセスポリシーを適用してください。外部IdPからのアクセスには、自社IdPからのアクセスよりも厳格なポリシーを設定することを推奨します。