Security Assertion Markup Language、つまりSAMLは、ユーザーが認証済みであることをIDプロバイダーがサービスプロバイダーへ伝えるための標準的な方法を提供するため、企業のシングルサインオンで広く利用され続けています。サービスプロバイダーは、ユーザーの元の認証情報を管理しなくても、アクセス可否を判断できます。この分離は多数のクラウドアプリケーションを運用する組織には有用ですが、同時に、アサーションのやり取りが正確であることが極めて重要になります。改ざんされた、あるいは誤って解釈されたアサーションは、認証の迂回につながる可能性があるためです。
Trail of Bitsは、SAMLの中核的な弱点は過去に発生した単一の不具合だけではないと主張しています。このプロトコルはXMLを基盤としており、XMLには名前空間、属性、コメント、スキーマ、CDATAセクションなど、実装が一貫して解析しなければならない柔軟な構成要素があります。その安全性は、XML署名の検証、正規化、そして署名がどのデータを対象としているかについてIDプロバイダーとサービスプロバイダーの間で合意が取れていることに依存します。記事では、署名ラッピング攻撃、パーサーの差異、正規化の誤りが、同じメッセージの意味について二つの実装が食い違う典型例として繰り返し挙げられています。
この図は、XML署名検証と正規化の失敗に関する記事の説明を直接的に裏付けています。
プロトコルの欠陥と実装の欠陥を区別することは重要です。SAMLは幅広いメッセージ、バインディング、プロファイル定义了する一方、実際の導入環境ではその一部だけを利用するのが一般的です。その結果、ライブラリや設定コード内に、利用されていない仕様上の領域が残る可能性はありますが、それだけで導入済みの実装すべてに脆弱性があると証明されるわけではありません。製品がSAMLを安全にサポートするには、関連する導入ポリシーに従い、署名、対象者および受信者に関する制限、時刻条件、発行者の身元、そして正確にどの署名済みアサーションを対象とするかを検証する必要があります。提供された資料は、すべてのSAML製品がこれらの検証に失敗すると示すものではありません。
記事はまた、署名対象となるXMLアサーションの内部に署名要素を配置する、SAMLの封入署名も批判しています。これと対比されているのが、JSON Web Tokenで一般的に用いられる分離署名の構造ですが、別のトークン形式に移行しても検証上の問題が自動的に消えるわけではないことも認めています。OIDCはより大規模な仕様群と実装群に依存しており、提供された資料には、実環境での脆弱性発生率をSAMLと比較できる十分な一次資料が含まれていません。したがって、OIDCはカテゴリとして必ず安全だとする主張は、実証済みの結論ではなく、調査すべき一つの論点にとどまります。
この比較は、SAMLの封入署名とJWTの署名に関する記事の論点を視覚的に示しています。
運用者にとって、より有用な問いは、自社の導入環境が限定され、十分にテストされた設定と、保守されたライブラリを使っているかどうかです。Trail of Bitsは、予期しないメッセージ形式を拒否し、可能な限り不要なプロトコル機能を使わないことを提案しています。組織は、SAMLアサーションを受け入れるすべてのIDプロバイダー、サービスプロバイダー、カスタムコネクタ、レガシー統合を棚卸しし、それぞれが署名とパーサーの境界事例をどのように処理しているかも確認すべきです。移行プロジェクトでは、プロトコルの変更を安全な設定の代替手段とみなすのではなく、これらの統制を維持する必要があります。
OIDCは、特に認証コードフローとバックチャネル通信がアーキテクチャに適合する場合、新しいWeb統合の妥当な代替手段になり得ます。ただし、提供された証拠は、OIDCがあらゆるSAML導入パターンを同じように支えられることを示していません。普遍的な移行経路が確立されていることも示していません。IDプロバイダー開始型フロー、分離されたネットワークを前提とする環境、または特殊な企業要件を抱えるチームは、互換性を入念にテストする必要があります。移行中には両方のプロトコルをサポートせざるを得ない場合もありますが、サポートするプロトコルが増えるほど、設定と検証に必要な作業も増えます。
より広い教訓は、認証プロトコルが仕様と実装の両方を通じて経年変化し、リスクも蓄積するという点にあります。SAMLが長く使われ続けている事実は、相互運用性と導入上の価値が実在することを示しています。しかし、その複雑さが無害であるという意味ではありません。逆に、XMLや署名処理の失敗が繰り返し確認されているからといって、すべてのSAMLログインが安全ではないと主張することもできません。セキュリティチームは、SAMLをリスクを伴う依存関係として扱い、不要な柔軟性を減らし、ライブラリを最新の状態に保ち、実際に導入しているフローが既知のパーサー攻撃と署名攻撃に対してテスト済みであることを示す証拠を求めるべきです。