WSSE (HTTP)

[13] WSSE は HTTP の認証の仕組みの一種です。 2000年代の中頃、いわゆる Web 2.0 時代に、 Web API の認証方式として広く用いられました。その後の OAuth の標準化と普及により、 WSSE は使われなくなりました。

代替

[32] OAuth の普及により、 WSSE が新たに使われることはなくなりました。既存の Web API も徐々に廃止されています。

[33] WSSE でのみ提供される Web API もほとんど残っていないと思われるので、クライアントライブラリーも WSSE に対応する必要は無さそうです。

プロトコル

[12] WSSE の解説の多くは仕様あるいは詳細として WS-Security 関連の仕様や解説記事を参照しているが、 HTTP の認証としての WSSE を本当に説明しているものは少ない。 WSSE は歴史的に WS-Security の認証方式を流用して Web API に適用したものであるが、実態として WS-* / SOAP とは関係ない。

[28] 当時は XML が Web の進化の方向性として信じられていたため、 XML を使ったシステム体系である WS-* との整合性が重視されていました。 (整合性といっても「似ている」程度のものですが...) Webアプリケーションのバックエンドとして WS-* を使っている時に、 WS-* と整合した WSSE を使うと一貫したセキュリティーが実現できる、とでも思われていたのでしょうが、現実にはほとんどの Webアプリケーションは WS-* など使う予定すらありませんでしたし、仮にそのような事例が存在したとしても、 HTTP認証と WS-* のセキュリティー機能が連動していたか (それによる利点があったか) は甚だ疑問であります。

[38] この辺の事情は当時の人々にとっては常識だったので、明解な説明がされていない。 XML 神話(バブル)が崩壊した今では意味がまったくわからなかろう。 (XML うぇーい! WS-* うぇーい! Web 2.0 うぇーい! 的なノリとテンションみたいなものなので、当時の人もどれだけちゃんと理解していたのかは怪しい。)

[10] おそらく >>8 が唯一仕様と呼べるレベルのもので、 >>9 がおそらく最初の実装リファレンス。 >>9 や >>14 の方が少し緩い。

[11] >>3 によれば >>8、>>9 の digest の計算方法は後に誤りと考えられるようになったが、 >>1 にあるように、未だに両方の実装が存在している。

[15] DifferentlyAbledClients - Atom Wiki (2012-02-14 22:15:19 +09:00 版) http://www.intertwingly.net/wiki/pie/DifferentlyAbledClients

[16] Atom とセットで使われてきたけど IETF の AtomPub は既存の HTTP の認証を使えばいいということになっている。

[29] 結果、現実に存在するプロトコルであるにも関わらず WSSE を明確に規定した仕様書は存在しませんでしたし、 >>11 のような問題が生じても何が正しいかを確定する音頭を取れる人(団体)もいませんでした。

セキュリティー

[19] WSSE では利用者名と合言葉の組を使いますが、クライアントも鯖も、この組を平文 (に復号可能な形) で保持しておく必要があります。

[20] 一般に利用者が指定した生のパスワードをサーバーで保存するのは悪手と考えられています。利用者が指定した生のパスワードを保持することを防ぐため、一方向ハッシュ関数を適用した結果や、鯖側で生成した合言葉とは関係のないトークンを合言葉として使う実装もあります。

HTTP 認証との関係

[35] challenge は HTTP認証の仕組みに則っていますが、 HTTP要求は独自の HTTPヘッダーだけを使っており、 HTTP認証の仕組みから外れています。

[36] そのため HTTPキャッシュとの関係を考慮しHTTP要求と HTTP応答に適切な Cache-Control: ヘッダーや Vary: ヘッダーを指定する必要があります。

[37] そうしなければ意図せず共有キャッシュに蓄積されて再利用されてしまうかもしれません。クライアントはサーバーが内部でキャッシュサーバーを使っているかわかりませんし、サーバーはクライアントがプロキシを使っているかわかりませんから、どちらも適切な指定を加えなければなりません。

[26] どうやら credentials を Authorization: ではなく独自のヘッダーで送っているのは、 CGI が Authorization: ヘッダーを CGIスクリプトに提供していなかったため >>25 のようです。

[25] New AtomAPI Implementation Release | BitWorking | Joe Gregorio (2015-02-21 01:29:03 +09:00 版) http://web.archive.org/web/20101213023745/http://bitworking.org/news/New_AtomAPI_Implementation_Release2

メモ

Web セキュリティー

[2] LWP::Authen::Wsse を使うとき,なぜ use LWP::Authen::Wsse しなくて良いのか - 理系学生日記 (2010-12-06 17:15:35 +09:00 版) http://d.hatena.ne.jp/kiririmode/20081004/p1

[5] 各サービスにおいてWSSE認証を厳密に確認するようになりました - Hatena Developer Blog ( (2013-07-18 05:18:02 +09:00 版)) http://developer.hatenastaff.com/entry/20110121/1295588374

[6] はてなサービスにおけるWSSE認証 - Hatena Developer Center ( (2013-07-18 05:18:19 +09:00 版)) http://developer.hatena.ne.jp/ja/documents/auth/apis/wsse

[4] Section 11.1. Data Feeds (2007-06-25 13:34:05 +09:00 版) http://82.157.70.109/mirrorbooks/buildingwebsites/0596102356/web2apps-CHP-11-SECT-1.html

Authorization: WSSE profile="cal"
X-WSSE: UsernameToken Username="cal",
        Created="2005-11-14T18:40:04-0800",
        Nonce="bf59559401b2d9e14964823a37836a76",
        PasswordDigest="WgUU6xmxOsGYqhNun9gJZ//C9ew="

[7]