SAMLはなぜ「壊れたデザインのフラクタル」と呼ばれるのか
SAML: A Fractal of Bad Design
SAMLは2002年にOASISの委員会が4つのXMLベース仕様を統合して生まれた認証プロトコルだ。XMLの複雑さ、正規化、エンベロープ署名などに起因する脆弱性が今も残り、XSW攻撃は2012年に指摘されてから10年以上経っても解消されていない。著者はDuoのAccess Gateway開発でSAMLに深く関わった経験から、OIDCのような現代的代替への移行を訴える。
SAMLの厄介な点は、理解するだけならほとんど簡単なのに、砂と骨の粉と灰の上に築かれていることだ。XML署名検証が信頼できると仮定すれば動く……しかしXML署名検証は深く呪われており、ほとんどの実装は誰も読まないlibxmlsecという厄介なCコードベースをラップしている。
HNでの議論
177- bawolff
私のお気に入りのSAMLホラー話は、かつてはデフォルトで、xmlsigの主要なC実装が指定された公開鍵で署名を検証するだけでなく、以下のことも行っていたというものだ：
- 攻撃者が制御するドキュメントで指定されたパスワードを使ったHMACに対して検証する。
- Web PKIを使って署名を検証する（つまり、攻撃者は自分の個人ドメインのTLS鍵でSAMLドキュメントに署名でき、それが常に有効と見なされる）。
正直、なぜSAMLを使っているサイトが常にハッキングされないのか分からない。絶対にひどい標準規格よりも悪いのは、絶対にひどい実装だけだ。
- jmbwell
これは「おお！マークアップ言語だ！マークアップ言語で何を解決できるだろう！」という産物だ。認証はマークアップする必要があるドキュメントやデータストリームではないのに。
記事はこれを正しくXMLと結びつけている。当時、XMLはまさにすべての釘に対するハンマーだった。
しかし、この問題はまだ終わっていないと思う。OIDCはGoogleその他のために多くの仮定を置いている。そして言及されたTailscaleは、「一線を守る」と言いつつも、GitHubアカウントを他と異なる扱いしなければならない時点で、すでにひび割れを露呈している。
我々に欠けているのは、プロバイダ非依存の方法だ。自分で管理するバックエンドを使って、ほとんどどこでもアカウントを作成してログインできるべきだ。それは可能だが、今日あるものではできない。
- cameronh90
SAMLは最悪だが、OIDCにはない、特定の狭いエンタープライズSSOユースケース向けの機能をまだ多く持っている。最も顕著なのはIdP主導フローだ。OIDCは製品間でサポートが一貫しない仕様の集合体である一方、SAMLの一般に実装されるサブセットは、その凡庸さにおいて多かれ少なかれ安定している。
OIDCはいずれSAMLを置き換えるだろうが、エンタープライズに売り込むなら両方をサポートすべきだ。どちらも、IdP間のSCIMの不一致に対処するのに費やす時間に比べれば見劣りするだろう。
- tehnoslow
記事への公正な批判は、SAMLの脆弱性を列挙しているが、OIDCについて同じ比較をしていないことだ。OIDCにも独自の問題がある：JWTアルゴリズム混同、noneアルゴリズム攻撃、オーディエンスチェックの欠如、JOSEライブラリのバグなどだ。
- arpinum
SAMLは記事が描くよりもさらに悪い。署名が実際に何に署名しているかを確認する必要があるといった問題がある。しかし私は未来に楽観的だ。一般的なXMLパースなど多くのことを行うライブラリに頼る代わりに、SAMLのサブセットと、上位約10社のプロバイダの方言だけをサポートできる。極端にニッチなプロバイダは、取引規模が割に合う場合にのみアドホックに追加できる。
- fire7000
「さらに、小委員会の委員会が会議を開くことは、「何でもあり」のプロトコル設計（例：ウォーターフォール手法、事前の大設計など）のレシピである。」
- 個人的には、何でもありは好きだ。
- pocksuppet
それは委員会による設計と呼ばれる。全員を一室に集めると、誰もトレードオフを取れない。なぜならそれが誰かのペットのユースケースを傷つけるからだ。だから実際には何も設計せず、設計が存在し得るフレームワークを構築するだけだ。
WireguardとOpenVPNを使ったことがある人なら違いが分かるだろう。OpenVPNは委員会による設計、Wireguardはビジョンを持つ誰かによる焦点を絞った意見の強い設計だ。OpenVPNはより多くのことをするが、あなたのユースケースがWireguardに合うものであれば、Wireguardの方がずっとうまくやる。
OSIスタック対IPでも同じことが見られる。OSIはアイデンティティを証明し、回線を確立し、セッション、異なる課金モデル、コレクトコール、サービス品質、そういったものすべてのためにこれらの層を発明した。IPはそれを見て言った：そんなノイズはくそくらえ - 我々はパケットを送る、届かなければまた送る、それで終わり。誰もOSIスタックを使わない。IPはOSIモデルに緩く適合するので今でも教えられているし、X.509はWebPKI証明書の定型文として再利用された。
XML対JSONももう一つだ。確かに、XMLが実際に設計されたマークアップテキストはJSONでは非常に醜いが、そのユースケースでさえXMLは複雑すぎる。
もしIP、Wireguard、JSONの人々がSSOシステムを設計したら、認証側にtelnetかHTTPで入り、そのログイン手順を実行し、依拠側にコピペできるトークンを取得し、依拠側は認証側に問い合わせてトークンが有効かどうかと署名した人のユーザー名を確認するだろう[…]
- sandeepkd
ここでは少数派かもしれないが、SAMLが輝く領域がある。
1. OIDC/OAuth2ではリクエストはサービスプロバイダから発信されなければならないが、ほとんどのエンタープライズIdPはIDP主導フローができるためシングルサインオンにSAMLを頼っている。
2. SAMLのセキュリティはペイロード自体に組み込まれており、MITM攻撃に対する安全性を提供する。HTTPSが理論的には同様の保証を提供するとしても、現実にはSSLオフロードはアプリケーションサーバーではなく別の場所で行われる。
投稿者はSAMLで発見された脆弱性のリストを提供したが、OIDC/OAuth2について同じものを提示しないなら、この種の比較は欠陥があると思う。
結局のところ、これらはツールであり、ツールの有効性はそれを理解して使うスキルセットに大きく依存する。