Libertyの「自由」度 インフォテリア株式会社 吉松 史彰 2002/07/31

---

　かねてから報じられていたとおり、去る7月15日にLiberty Alliance Projectから「Liberty Alliance Version 1.0 Specification」が発表された。同プロジェクトは、オープンで相互運用可能な「federated network identity」の標準を開発し、配布し、発展させることを目的に設立された団体で、メンバー企業としてNTT、NTTドコモ、ソニーなどが名を連ねている。

　これによって、ユーザーは書籍販売サイトや旅行代理店サイト、アダルトからeラーニングまで、とにかくあらゆるサイトで要求されていた「ユーザー名とパスワードの入力」を1度で済ませることができるようになる（シングル・サインオン）。Webサイトの開発者にとっては、ユーザー認証機構を開発する必要がなくなるというメリットがあり、ユーザーにはパスワードを複数覚えなくてもいいというメリットがある。＠ITクラブに登録した電子メール・アドレスとパスワードの組み合わせと、まったく同じ組み合わせをそのほかのサイト（例えばAmazonでの書籍購入時）でも利用している読者はいないだろうか？ いますぐ変更を！ そうでないと、AmazonのWebサイト管理者があなたの名をかたって掲示板で発言してしまうかもしれないのだ。それを防ぐには、とにかくあらゆるWebサイトで、要求されるたびに違うパスワードを設定し、それをすべて覚えておかなくてはならない。しかし、Liberty Alliance仕様によって、現在はWebサイトごとにバラバラに開発され、運用されているユーザー認証の仕組み、認証後のアイデンティティの管理、認証時の付帯情報などを標準化し、Webサイト間でそれらを共有できるようになる（はずである）。

　同種のサービスは、すでにMicrosoftが「.NET Passport」という名前で公開している。Liberty Alliance Projectは、デスクトップに続いてインターネットさえもMicrosoftに独占されてしまうことを懸念した各社が、打倒Passportで団結して出来上がった団体である。.NET Passportは1999年にサービスインしており、すでに多数のユーザーと対応Webサイトを獲得しているが、ユーザーIDとパスワードの組みを管理しているのがMicrosoft 1社であることから、セキュリティ的にも感情的にも問題視されている経緯がある。Libertyは、Microsoftの支配から自由になり、各Webサイトが1つの仕様に対する多数の異なる実装を選択できるようにすることで、自社のWebサイトにアクセスしてくるユーザーに対して、自分のアイデンティティをゆだねる相手を選択する自由を提供しようとしている。現在、Entrust、Novell、RSA、Sun Microsystemsなどがこの仕様の実装を提供することを発表している。もちろん、これらの実装はすべて同じ仕様をベースにしているので、Sun Microsystemsの実装に対してログインしたユーザーが、Novellの実装をターゲットに作られたWebサイトにアクセスできなくなるということはない（はずである）。

　以上がビジネス的能書きである。ここからは、＠IT読者の過半数を占めるであろう、技術者向けに話題を移そう。Liberty Alliance Version 1.0 SpecificationはLiberty Allianceのホームページからダウンロードできる。いくつかのPDFファイルが用意されているが、ここで話題にしたいのは、「Liberty Protocols and Schemas Specification」（メッセージ仕様）と「Liberty Bindings and Profiles Specification」（バインディング仕様）である。大ざっぱにいうと、前者は仕様の実装者同士がやりとりするメッセージを、後者はそのメッセージを運ぶ方法を定義している。

　メッセージ仕様としては、RequestとResponseの対が定義されている。また、RequestとResponseのそれぞれに、Webサイトと認証サービス間で必要となる付属情報をやりとりするためのEnvelopeの形式が決められている。Envelopeの中には、本来のRequest／Responseのほかに、付属的なヘッダ情報を含むことができるようになっている。

　「ハァ？」と思った読者は正しい。この文章、どこかでお目にかかったことがないだろうか。そう、この説明はそっくりそのままSOAPのEnvelope仕様の説明である。つまり、Libertyのメッセージ仕様は、SOAP Message Construct仕様（SOAP 1.2 Part1のセクション5、SOAP 1.1のセクション4）をもう一度作ってしまったような内容なのである。Liberty Allianceは、RequestとResponseの対だけを定めればよかったのに、Envelope仕様まで決めてしまったのだ。

　バインディング仕様には、メッセージ仕様にのっとって作成されたメッセージをエンコードして運べるようにするときの決まり事が定義されている。バインディング仕様の中には「プロファイル」というセクションがあり、ここでメッセージをやりとりする方式ごとに、メッセージをどのようにエンコードして送信すればいいのかが定義されている。例えばWML対応のWAPデバイスとやりとりする場合に、メッセージ仕様にのっとったメッセージをWMLに乗せる方法や、URLにメッセージをエンコードする方法が決められている。また、Liberty Allianceの仕様はSAML（Secure Assertion Markup Language）の拡張仕様であり、SAML仕様にはSAMLメッセージをSOAPに乗せて運ぶ仕様が定義されているため、LibertyのメッセージをXMLの形でSOAPに乗せる仕様も決められている。XML／WML／URLという形態の違いはあるが、いずれもメッセージのエンコード方式として使っていることに違いはない。これらをHTTPプロトコルに乗せて運ぶ方法が、バインディング仕様として決められている。

　ここで再び「ハァ？」と思った読者は正しい。Libertyの仕様はHTTPに依存している。SMTP、FTP、JabberなどのIMプロトコルなど、ほかの実用的なプロトコルに乗せることはこの仕様の範囲外だ。要するに、Libertyのバインディング仕様は、SOAP−HTTPバインディング仕様（SOAP 1.2 Part2のセクション7、SOAP 1.1のセクション6）をもう一度作ってしまったような内容なのである。

　要するにこういうことだ。Liberty Alliance Version 1.0 Specificationに準拠した認証サービス、またはその認証サービスを利用するWebサイトを構築する場合、トランスポート・プロトコルとしてHTTPを使わなければならない。HTTPに乗せて送受信するメッセージの構造は、現在では業界標準的な地位を占めているSOAPではなく、Libertyが独自に定義したプロプライエタリな構造を使わなければならない。メッセージ構造にのっとって作成される「コンテンツ」は、SAML仕様に準拠していなければならない。また、認証という重要なサービスを担うメッセージには、その完全性（Integrity）や秘匿性（Confidentiality）が欠かせないが、これらを実現するためには、必ずSSL 3.0（TLS 1.0）やIPSecを使わなければならない。ほかにも、HTTPのリダイレクトやクッキーに頼る部分など、あげつらったらきりがないのでここでやめておこう。

　Liberty Allianceが今回発表した仕様でカバーできる領域は、Microsoftの.NET Passportとあまり変わらない。従来型のブラウザで閲覧するタイプのWebサイトの認証システムとして使うことはできるだろう。だが、期待されていたようなXML Webサービスで利用できる認証サービスにはなっていない。確かにSOAPを仕様の一部に取り込んではいるが、SOAPを使う理由が何もない場所に無理に詰め込んだように見える。単にHTTPだけを使えばよかった場所で、無理にSOAP−HTTPバインディングを使ってしまっているのだ。SAMLのSOAPバインディングを使うためには避けられなかったのだろう。

　XML Webサービスの世界では、いま急速にHTTP離れが進んでいる。SOAPとHTTPがあまりに接近しすぎてしまったため、セキュリティやReliable Messaging（メッセージが相手に対してただ1度だけ、確実に、順序よく届くことを保証するメカニズム）のような仕組みまでHTTPをベースに実現しようとしてしまった点を反省し、現在ではメッセージの完全性、秘匿性、認証情報の伝播、ルーティングなど、メッセージに関する内容はすべてそのSOAPメッセージ自身に持たせるという「自己記述性」が重要なキーワードになっている。それが実現できれば、トランスポート・プロトコルは自由に選べる。

　メッセージにコンテンツ以外の付属情報を持たせる仕組みはSOAP 1.1ですでに用意されていた。SOAPヘッダである。だが、これまではこの機能を有効に使うことができるツールキットが存在しなかったため、軽視されていた経緯がある。しかし、現在ではWindows XPに搭載されているMSMQ 3.0をはじめとして、SOAPヘッダを有効活用できるアプリケーションが出始めている。ここで重要なことは、SOAPヘッダ仕様はその中身は定義していない点だ。IBM、Microsoft、VeriSignが共同でOASISに提出したWS-Security仕様は、そのSOAPヘッダに書き込む内容を規定するものだが、そのWS-Security仕様ですら書き方を支持するだけで、認証の仕組みとしてKerberosを使うのか、PKIベースのものにするのか、SAMLを利用するのか、XML署名や暗号化の仕様は何を使うのかは決めていない。何を使っているのかを示す場所を定義しているだけなのだ。これによって、開発者が必要な仕様を自分で選択して実装することができるようにしている。

　Liberty Alliance Version 1.0 Specificationは、Microsoft支配からの自由を重視するあまり、開発者から選択の自由を奪ってしまった。その結果生まれた仕様は、SOAPを盛り込んではいるものの、現在、XML Webサービスの適用を検討している各社の検討対象にはなりえない仕様になってしまった。だが、希望の灯も見えている。Liberty Allianceの中心的存在であるSun Microsystemsは、OASISの場ではWS-Securityを支持していると報じられている。MicrosoftもSun MicrosystemsもIBMも、そのほかすべてのベンダが、無用な政治的争いはわきにのけてユーザーと開発者に最善の仕様を開発し、提供してくれることを期待するとともに、私たち開発者も、仕様の策定過程にもっと積極的に参加しなくてはならないのだろう。

---

吉松 史彰（よしまつ ふみあき）
　インフォテリアにおいて、.NET FrameworkやXMLを活用したシステムの開発とコンサルティングを行っている。また、個人でも執筆や講演活動を通して.NET Frameworkの啓蒙活動をマイクロソフトに黙って勝手に行っている。

「Insider.NET - Opinion」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）