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での議論
88- 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アルゴリズム攻撃、audienceチェックの欠如、そしてJOSEライブラリのバグです。
- arpinum
SAMLは記事が描写するよりもさらに悪いです。署名が実際に何に署名しているかを確認する必要があるといった問題があります。しかし私は未来に楽観的です。汎用XMLパースのような多くのことを行うライブラリに頼る代わりに、SAMLのサブセットと上位約10プロバイダーの方言だけをサポートすることができます。極端にニッチなプロバイダーは、取引規模がそれに見合う場合にのみ、アドホックに追加できます。