パーソナルデータのmashupとクロスドメインJSONのセキュリティ（１）
もし誰かが自分の持っているデータをWebサービスとして公開したいとき、その形式はXMLになるのが今のところ主流だけれども、JSON形式で配信できるように*1しておくと、mashupする側は自前のサーバを用意することなくとも、異なるドメインからデータを利用することができる。この詳細についてはすでにいろいろ書いているので省略する。
これはmashupの可能性を飛躍的に拡大させると言えるのだけど、実はもっと重要なことがある。それはこの場合mashupするデータの伝送がユーザを中心に行われているということだ。
もちろん、よく言われる本当の意味での「ユーザ中心(user-centric)」は、ユーザが自分に関するデータ（パーソナルデータ≒identity）の利用を全て選択しコントロールできる、ということだろう。その意味ではべつにデータの送受信がユーザを経由しようがサーバ間で行われようが「ユーザ中心」のデータ制御は実現できる。逆に経路がユーザを通っていてもサーバ側にすべてデータの受け渡しを制御される場合もある*2。なのでここでは単にデータの伝送経路がユーザ中心である、ということのみを言っている。
では伝送経路がユーザ中心である場合の最大の特徴は何か。
それは「リクエスト実行者は常にユーザ」である点。つまりサービスにリクエストを行うための代理人（プロキシ）が存在しない。
そしてそれの何がすばらしいかというと、Webサービスに既存のWeb認証の仕組みをまったくそのまま流用できることだと言える。
もしプロキシサービスを経由しなければならないとすると、mashupする対象のサービスが認証を必要とする場合に、どのようにプロキシサービスに対してサービスアクセスを許すかということを考える必要がある。
とりあえず簡単に考え付く方法として、ユーザ自身の資格証明（ユーザ名／パスワード）をプロキシ側に渡しておく、という案があるが、これはいろいろ危ないし、まずもってそのための信用をすべてのmashupサービスがユーザから得られるとは限らない。
まともにやろうとすると、何らかのアクセスチケット受け渡しの仕組みが必要になってくる。これは標準仕様が定められているものからサービス独自方式のものまでいろいろなプロトコルがあるが、残念ながらどれもそれほど普及しているとは言いがたい。
翻って、ユーザがmashupの中心である場合を考えると、非常に話は簡単になる。リクエストを投げるのはユーザ自身であるため、各サービスはアクセス制御のためのユーザ認証について、既存のWebアプリで行っていた方法をそのまま用いることができる。それはcookieによるものであるかもしれないし、BASIC認証であるかもしれない。そして重要なことに、そのことはmashupを行おうとするサービスには直接関係しない。
とりあえず一つ簡単な利用イメージを提示しよう。
いま自分はあるオンラインのCRMサービスに重要な顧客のコンタクトリストを保管している。このリストには顧客の住所情報が含まれているが、できれば地図情報と同時に表示して一覧したい。そのCRMサービスがGoogle Mapsとのmashupをしていてくれればよいのだが、今のところ残念ながらそのようなサービスは行われていないようである。
そこで、ある第3者のサービスが、このコンタクトリストと地図情報とのmashupに対して商機を見出し、2つのmashupを行うアプリケーションサービスを作ろうと考えた。
ここで、CRMサービスがJSONでのコンタクトリスト提供を行うことを決断したと仮定する。そうすると実に簡単にこのアプリケーションサービスは実現できる。
まず、CRMサービス側は通常のWebアプリの場合と同様にユーザを（cookieなどで）認証し、ユーザの持つコンタクトリストのデータをHTMLではなくJSON形式で返すようなサービスエンドポイントを実装して提供する。次にmashupを行うアプリケーション側は、まずそのサービスエンドポイントに対してJSONデータをリクエストするようにユーザに要求する。そして得られたJSONデータをもとに住所情報のジオコーディングを行い*3、Google Mapsに緯度経度で顧客情報をプロットする。
以上、これだけで新たなmashupサービスが生まれていく。サービスを提供する側も、そのサービスを利用してmashupする側も、実装コストは驚くほど低い。
ここまで聞いた中で、この仕組みを「これはすごい」と思うか「これはひどい」と思うかに分かれると思う。「これはひどい」と思った人は結構正しい。実は今までの話にはセキュリティの観点がまったく抜けている。
上の例では「コンタクトリスト」というパーソナルデータを、何の許しもなく勝手に第3者が取得できてしまっている。もし悪意あるWebアプリを作っておいてユーザをそのWebサイトに誘導することに成功したなら、知らないうちにデータを抜き取ることなど簡単だ。
これはやはり上記のCRMサービス側が、データを公開する場合にはもう少し気を使ってやらなければならないということを意味している。つまり、リクエストを行うユーザ以外にも、mashupを行う第3者のアプリケーションについて認証しなければいけない。
そう聞くと、なんとなく「対象が逆になっただけでプロキシの場合と同じじゃない」と言われそうだが、実はそうでもない。とりあえず次回はもう少し実装的な話に落としていく。
