フィードの限定公開についてメモ

なんとなく、HTTPS+Basic認証で落ち着きそうな気配があるけど、ケースバイケースではあるのでちょっとメモ。


予測困難なURL

ランダムな文字列をフィードのURLにする事で、そのフィードの存在をある程度隠す事が出来る。URL自体が認証情報となるので、このURLが漏れた段階でアウト。
適当なタイミングでURLを変更し、古いURLを無効にする事で安全性の向上が図れる。
クライアント側で特別な実装を必要とせず、またサーバ側でも実装の負担は小さい。
フィードURLの管理次第で簡単に情報漏洩してしまうため、ごく軽微な被害(心理的にちょっと困る)で済むケースでのみ利用可能。

HTTPS+Basic認証

Webのアクセス制限として一般的な方法。
広く利用されているため、サーバとクライアント両者にとって実装の負担が小さい。
メリット/デメリットについては、一般のWebアクセス同様。
購読者(アクセス許可ユーザ)の数だけフィードへのアクセスのための認証情報が必要になるため、管理コストは高め。全ての購読者に対して同じ内容のフィードを配信する場合は、多少コストは下がる。
場合によって、ユーザ情報ごとに処理が必要な場合は難しい場面が登場するかも。

HTTPS+WSSE

AtomPPで利用されている認証方法。
一般的ではないため、クライアントとサーバ両者にとっての負担は小さくない。
これからフィードを配信するサービスがすでにユーザ認証機能を備えている場合、その認証情報と連携がとれるため、認証後に処理何かしらの処理を行いたい場合には有効かもしれない。
ただし、サービスを利用するための認証情報を外部サービス(アプリケーション)に教える必要がある事に注意。

HTTPS+認証API

認証のための外部サービスを利用する。
認証処理を実装する必要は無いが、クライアント側での認証の要求処理とサーバ側での認証結果に基づく応答処理は必要であるため、両者の負担は小さくない。
認証APIの実装次第で、クライアントが上手く実装出来るか決まる。
フィード配信側でのユーザ識別が難しいため、購読者ごとに内容を変えたフィードなどを配信する事は難しいかもしれない。

フィード自体の暗号化

PDFの様に文書暗号化技術を利用する。
"鍵"を持っていなければ複合出来ない。
サーバ側では安全な暗号化処理の実装が必要となり、クライアント側でもその複合化処理を実装しなければならない。
現実的に考えれば、個人環境での利用に限定される。Webアプリとして提供されているアグリゲータサービスでは、鍵の管理や暗号化/複合化処理の問題を解決する事は難しいかもしれない。
また、アイテムURLを暗号化文書(PDF)のURLとし、その暗号化/複合化は既存サービスを利用する。


どの方法を選ぶかは、ケースバイケース。購読者を制限したいだけであれば、何も考えず上2つを選べばいい。有名なフィードリーダーであれば、きっとBasic認証をサポートしている。ただし、ユーザ視点として共有型のリーダーサービスを利用している場合は注意が必要。登録したURLは原則として他のユーザーに漏れていると考えた方がいい。また、サーバに認証情報を教えているという事も考慮する必要がある。

課金フィードを提供したい場合、『フィード購読者の多くは共有型のリーダーサービスを利用している』事を頭に入れておく必要がある。このケースで考えると、情報が漏れて困るのは提供側。全ての購読者がセキュリティについて慎重だとは限らない。独自の認証処理とリーダーをセットにして提供する事が望ましいかもしれない。もしくは、フィードのアイテムURLを暗号化文書のURLにする事を考える。

SNSの更新情報など、利用者によって内容が異なる種類のデータをフィードで提供する場合は、認証処理後のユーザ別処理を簡単にする事も見据えて考える必要がある。既存の認証方法と情報を使い回す方が管理コストが低くなる可能性がある。ただし、独自の認証方式を導入すれば、クライアントが対応していない可能性が高くなる。Widgetなど独自のクライアントアプリケーションを提供出来ないのであれば、一般的なクライアントでの実装方法に合わせた選択をせざるを得ない。


と、意味が分からないメモを続けた訳だけど、勤め先でこの辺を導入しようとした場合はどれが妥当だろう。(フィード発行サービス)

まあ、フィードごとに1つの認証情報を用意するしか無いだろうね。Basic認証で。ああ、強制HTTPS通信も。配信処理の中で認証処理をサポートするのはサービスの形態的に現実的でない気がする。

仮に、複雑な処理が必要になってBasic認証では捌ききれない場合、それは『課金フィード』みたいな別サービスとして用意した方がすっきりしそう。フィード管理周りは今のサービスで統合出来る仕組みを作って、細かいところはそれぞれの別サービス側で実現した方が現実的かもしれない。

今のところこんな感じで理解してます。セキュアフィード。

プロフィール

このブログ記事について

このページは、koshigoeが2006年7月 2日 15:56に書いたブログ記事です。

ひとつ前のブログ記事は「カテゴリ整理」です。

次のブログ記事は「QuicksilverのSubversion Plugin」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。