SAMLとフェデレーション

SAML（Security Assertion Markup Language）は、認証および認可データを交換する XML ベースの標準で、エンタープライズ SSO で広く使われています。

• 企業のアイデンティティプロバイダーが、多数のアプリケーションに対してユーザーを保証できるようにします。
• SAML 2.0 は OIDC より前から存在し、B2B やワークフォースアイデンティティの分野に深く定着しています。

SAML を理解することは、企業フェデレーションを防御するうえで不可欠です。信頼上の 1 つの欠陥によって、接続されているすべてのアプリが危険にさらされる可能性があるためです。

SAML フェデレーションには、主要な当事者が 2 つあります。

• アイデンティティプロバイダー（IdP）は、ユーザーを認証し、アサーションを発行します（Okta、Entra ID、Ping）。
• サービスプロバイダー（SP）は、IdP を信頼してアクセスを許可するアプリケーションです。

信頼関係は、署名証明書やエンドポイント URL などを含むメタデータを帯域外で交換することによって確立されます。

中核となる成果物はアサーションです。これは、IdP が subject を認証したことを示す XML ドキュメントです。

• Subject はユーザーを識別します（NameID）。
• Conditions は有効期間と意図された対象者を定義します。
• AuthnStatement は認証がどのように、いつ行われたかを記録します。
• AttributeStatement はロール、メールアドレス、グループのクレームを含みます。

最も一般的なパターンは、SP 起点の SSO です。

• ユーザーが SP にアクセスすると、SP は AuthnRequest を生成して IdP にリダイレクトします。
• IdP はユーザーを認証し、署名付きの Response を SP のアサーションコンシューマーサービス（ACS）に POST で返します。
• SP はアサーションを検証し、ローカルセッションを作成します。

SAML のセキュリティは、XML デジタル署名に基づいています。IdP は秘密鍵でアサーション（およびレスポンス）に署名し、SP は信頼済みの証明書で検証します。

• 外側のレスポンスだけではなく、アサーション自体に署名してください。
• メッセージに埋め込まれた証明書ではなく、メタデータから取得してピン留めした IdP 証明書に対して署名を検証してください。

SAML 攻撃の多くは、署名検証ロジックを標的にします。

XML Signature Wrapping は、SAML に対する署名攻撃の一種です。攻撃者は正しく署名された要素を残したまま、アプリケーションロジックが実際に読み取る 2 つ目の偽造アサーションを追加します。

• 署名は元のフラグメントに対しては引き続き検証に成功します。
• しかし、ビジネスロジックは注入された署名なしのアサーションを処理します。

対策として、堅牢化された SAML ライブラリを使用し、署名された要素が実際に使用される要素であることを検証して、複数または曖昧なアサーションを含むドキュメントを拒否してください。

アサーションは、意図された SP に紐付けられていなければなりません。SAML には、そのための明示的な制限があります。

• AudienceRestriction は、アサーションが有効となる SP の entity ID を指定します。
• SubjectConfirmation 内の Recipient は、ACS URL と一致しなければなりません。

SP はこれらを強制しなければなりません。対象者の確認を省略すると、あるアプリ向けに発行されたアサーションを別のアプリでリプレイできてしまいます。

アサーションは、短期間だけ有効な一度限りの資格情報です。SP はそれを強制しなければなりません。

• 厳密なクロックスキューを設定し、NotBefore と NotOnOrAfter を守ってください。
• アサーションの ID を追跡し、有効期間内の再利用を拒否してください。
• ACS エンドポイントでは TLS を必須にしてください。

リプレイの追跡を行わないと、傍受されたアサーションが有効期限前に再度送信される可能性があります。

フェデレーションにより、組織の境界を越えてSSOを拡張できます。プロトコル間の変換を行うハブやブローカーを介する場合もあります。

• 信頼関係の各リンクは潜在的な弱点となり、侵害されたIdPはすべてのユーザーになりすませます。
• アイデンティティブローカーはSAMLとOIDCを橋渡しできるため、クレームマッピングを慎重に行う必要があります。

属性マッピングには最小権限を適用し、予期しない新しいSP登録を監視してください。

監査で確認すべき、SAMLで繰り返し発生する失敗パターンは次のとおりです。

• 署名が検証されていない、またはレスポンスには署名されているがアサーションには署名されていない。
• XML Signature Wrappingに対して脆弱である。
• audience/recipientのチェックがない。
• リプレイ対策がない、または有効期間が長すぎる。
• SPでXML External Entity（XXE）解析が行われる。
• ピン留めしたメタデータではなく、メッセージに埋め込まれた証明書を信頼している。

どちらもSSOを提供しますが、設計は異なります。

• SAMLはXML、ブラウザーのPOST/リダイレクトバインディングを使用し、エンタープライズやワークフォースで広く使われ、ツールも成熟しています。
• OIDCはJSON/JWTを使用し、RESTとの親和性が高く、モバイルやSPAに適しています。

両方を運用している組織も多くあります。プロトコルによって攻撃対象領域が異なるため、防御側は各アプリが使用するプロトコルのアサーション検証ルールを把握しておく必要があります。

説明された攻撃に対する最も効果的な防御策を選択してください。

重要なポイント：

• SAMLはXMLベースのエンタープライズSSOであり、署名付きのアサーションを使ってIdPとSPの間を連携します。
• セキュリティは、ピン留めした証明書に対して正しくXML署名を検証できるかに左右されます。
• XML Signature Wrapping、リプレイ、XXEから防御してください。
• 必ずaudience/recipientの制限と有効期間を適用してください。
• フェデレーションは信頼関係を拡張しますが、IdPが侵害された場合の影響範囲も拡大します。