本コラムをずいぶん長いこと中断してしまって誠に申し訳ない限りである。この間に、大きなニュースとしてまずSolaris 9のリリースがあった。そして、つい先日には“Liberty Alliance”の活動の成果として、“Liberty Alliance Project version 1.0 Specification”が発表された。今回は、このLiberty発表に関して感じたことをまとめてみたい。
シングルサインオンとWeb Service
まず始めに、筆者はこれまで「シングルサインオン」の意味をやや勘違いしていたことを告白せねばなるまい。シングルサインオンとは、ユーザー認証を要する複数サイト間で認証情報を共有し、一度ログイン作業を行なえば、以降どのサイトにも自由に入れるようにすることだ、と紹介されている。このことは確かに理解していたが、この機能を実際にどう利用するのか、という点になると、筆者はあまりにも額面通りに受け取りすぎており、ちょっとピントがずれていたのである。
筆者が想像するシングルサインオンのイメージは、あくまでも現状のWebサイトを順次渡り歩く、いわゆるWebサーフィンから脱却できていなかった。たとえば筆者の場合、ユーザー認証を要するサイトとしては銀行やWebメールなどが比較的利用頻度の高いところだ。しかし、この両者の利用は別に何らリンクしていないため、銀行のサイトで残高照会や振り込みを行なった後、即座にWebメールをチェックするためにWebメールサイトに移動する可能性はそう高くない。もちろん、逆順でも状況は大差ないが。
しかも、異なるWebサイトを順次訪問する場合、新しいサイトに移動した際にそのサイトへのログイン作業を行なうのは、それほど苦でもない。もちろん、多数のユーザーIDとパスワードを管理する手間というのは確かにあるが、よく利用するサイトに関してはさすがに頭に入っているので、まぁ問題はないとも言える。もちろん、ユーザーIDを設定する際に、可能であれば極力同じIDを利用するようにする、という程度の工夫はするが、これとてもサイトごとに利用可能な文字種や設定可能な文字数が異なっていたり、既に他の人が使用していたりして設定できないといったことも多いため、思うようにはならないのが現状であり、面倒であることに変わりはない。とはいえ、“シングルサインオン”という特別な仕組みをわざわざ用意するに値するほどのこととまでは思っていなかった、というのが正直な感想であった。実際には、Webブラウザの側にサイトごとのID／パスワードデータベースのような機能を用意する方がよほど便利だろう、と思っていたのである。
もちろん、既に多くの方がご存じだろうが、シングルサインオンが目的としているのは、Webサーフィンの省力化ではない。本来の狙いは、「Web Service普及に向けたインフラ整備」なのである。
Web Serviceでは、複数のサイト間でサービスの呼び出し／リモート実行が可能になる。よく例に挙がる旅行予約サイトのイメージでは、たとえば航空券予約やダイヤの確認、ホテルの空室状況確認と予約、レンタカーの申し込み、といった機能をひとまとめに提供したい。このとき、Web Serviceを利用すれば、航空会社、ホテルチェーン、レンタカー会社がそれぞれ独自に用意した各種の情報検索／予約機能を旅行予約サイトから呼び出して利用できるようになる。もちろん、現状でも気の利いた旅行予約サイトでは同じ機能を提供しているのだが、これは旅行予約サイトが用意した専用アプリケーションであり、航空会社やホテルのサービスを直接呼んでいるわけではない。
さて、シングルサインオンとの関連だが、Web Serviceで複数のサービスをまとめて呼び出す際に効いてくる。先の旅行予約サイトの例では、航空会社、ホテルチェーン、レンタカー会社がそれぞれユーザー情報を持っているのが普通である。航空会社やホテルチェーンではマイレージサービスなどのために各会員に会員番号を設定して、利用状況に応じたサービスを提供しているし、レンタカー会社でも同様のサービスがある。ユーザーとしては、当然こうしたサービスを旅行予約サイトを経由して予約する場合でも通常通りに利用したいと思うだろう。しかし、Web Serviceで呼び出された各種のサービスがそれぞれユーザー認証を要求したら、かなり面倒なことになる。せっかく旅行予約サイトが1まとめの処理としてサービスを統合してくれても、ログインの手間が個別に発生するのでは台無しと言える。この状況を回避するのに、シングルサインオンが有効となるのである。
これで、シングルサインオンを巡る動きが明瞭に理解できるようになる。ついでに、“.Net Passport”と“Liberty Alliance”の根本的な哲学の違いも明らかになってくる。Libertyでは、企業が自由に認証主体となることができ、認証情報を共有するグループ(Libertyではこれを“Circle of Trust”と呼ぶ)を結成できる。つまり、先の旅行予約サイトのような「Web Serviceポータル」を考えた場合、ここにどのようなサービス提供者が参加するかを決定するのは、従来通りの企業間の連合／アライアンスの形成／業務提携といった手順で行なわれ、Libertyを利用した認証の仕組みもこの流れに自然に組み込まれることになる。Libertyを利用した認証では、どのような暗号メカニズムを利用し、どのような情報を相互に共有するか、といった基本的な設定をCircle of Trustの内部での合意に基づいて自由に決定できるので、その点も「Web Serviceポータル」構築には都合がよいだろう。この基本部分をMicrosoftが握る形になる.Net Passportよりも使いやすいと思う企業があるのは当然だし、Liberty Allianceにさまざまな業界の企業が参加した理由も分かるような気がする。
Directory Serverとは何か
ユーザー認証の基盤として、Directory Serverが注目されている。もちろん、前述のLiberty Allianceのシステムでも、基本となるユーザーデータベースにはLDAPを利用したDirectory Serverが利用されることが前提となっていることもその理由の1つだろう。
多くのコンピュータ利用者にとって、ユーザーデータベースとはOSに用意された基本的な機能だとイメージされるのではないだろうか。マルチユーザーシステムでは、何らかのユーザーデータベースが用意されるのが当然である。たとえば、UNIXでは古くから/etc/passwordファイルがユーザーデータベースとして機能してきた。Directory Serverは、ある意味では/etc/passwdファイルが持っている情報をデータベースに格納し、ネットワーク経由でのアクセスを可能にしたものであるとも言える。
実は、これだけのことならそう画期的な話でもない。単にユーザーデータベースをネットワーク対応にするだけなら、Sunの場合はNISの時代に既に実現できていた話だ。実際、筆者が把握している範囲では、Directory Serverを利用しても、単に「ログインのためのユーザー認証用データベース」としてのみ利用するのであれば、Directory ServerでもNISでもそう大きな違いはないように感じられる。目立つ違いは、Directory Serverではアクセスプロトコルとして標準のLDAPが利用されるため、NISよりも汎用性があり、プラットフォームに依存しない、という点だ。
実際問題、ユーザー管理をDirectory Serverベースに移行して便利だと感じられるのは、現状ではかなり大規模な組織に限られるのではないだろうか。そのことが、たびたび話題には上るものの、どうしても地味な印象が拭えない原因だとも思われる。筆者は自宅で作業をしている都合上、管理すべきユーザーは家族を含めても2人であり、アカウント数で言っても、せいぜいが10数個で足りる。手動で/etc/passwdファイルを編集しても全く苦にならない程度なので、わざわざDirectory Serverを導入しようという気は全くなかった。というわけで、Directory Server自体にほとんど関心を持ってはいなかったというところだ。
この状態が多少変化したのは、“Solaris 9”にDirectory Serverが統合され、OS標準の機能と位置づけられるようになったことの影響だ。最初から付いているものなら、せっかくだからちゃんと活用してみようかという気にもなる。Sunとしては、今後のLibertyの普及やSun ONEアーキテクチャの活用を睨み、少しでもDirectory Serverユーザーを増やしたいということで標準添付を決めたのだろうが、まさにその戦略にまんまと乗った形である。
で、詳しい人に話を聞いたりしてみると、実はDirectory Serverは単にユーザーIDの管理だけではなく、かなり汎用性の高いデータベースシステムであることが分かってきた。ちゃんと活用すれば、なかなか便利に使えそうなのである。
Directory Serverは、もちろんデータベースそのものだが、一般的に利用されているRDBMSと違っているのは、アクセス手段がSQLではなくLDAPであること、リレーション機能を前面に打ち出してはいないこと、読み込みに特化したチューニングが施されており、データの書き込みには時間が掛かること、などが挙げられるようだ。ただし、これらの特徴は、小規模な環境ではほとんどデメリットとは言えないようなものである。
かつて、「ワードプロセッサ」「スプレッドシート」「データベース」が三種の神器などと呼ばれ、PCアプリケーションの代表格とされた時代があった。マイコンがパソコンに変わる頃の話だと記憶する。その当時の筆者の発想としては、ワープロは使っていたし、スプレッドシートは使用頻度は低いものの使えば便利だということは認識していた。しかしながら、データベースとなると、個人で利用するためのデータベースをわざわざ手間をかけて構築する意義が見いだせず、ほとんど関心を持たなかったものだ。しかし、実際にコンピュータを利用するとなると、「データベース」と敢えて構えて考えるまでもなく、“データベース的なモノ”は日常的に利用している。ユーザーIDの管理もそうだし、LAN内のPCのIPアドレス割り当てを記録した/etc/hostsファイルのようなものから、ちょっとしたメモのようなテキストファイルまで、実は多くがデータベースとしての機能を発揮している。
Directory Serverでは、もともとの用途がそうであったため、ユーザー管理には便利なようにあらかじめ機能が揃っており、個人用データベースの用途としてもっとも重要と思われる住所録作成はごく簡単な作業でできそうだ。このほか、ネットワークの設定パラメータを記録したhostsファイルなどもすぐに利用可能だろう。現在では、個人用住所録は年賀状作成ソフトに吸収されてしまった感があり、個人向けの手頃なデータベースソフトはあまり目立たない商品となっているようだが、OS標準で備わっているとなると、ちょっといじってみたくもなるというものである。問題は、LDAPクライアントを簡単に作る環境が見あたらないとか、任意のデータを格納するためにスキーマを定義するのがあまり簡単ではなさそうだとかいう点で、個人向けデータベースとして利用するには少々敷居が高いように感じられるのだが、知的な余暇作業としてはこの程度の障害がある方がちょうど良いのかもしれない。もっとも、正式発売になったStar Suite 6.0にはリレーショナルデータベースも含まれているので、個人ユーザーであればこちらを利用する方が王道だという気もするのだが。
といったわけで、しばらく執筆を中断していた間に、さまざまなプロダクトも発表になり、特にSolaris 9がリリースされたことでSunユーザーの環境も変化の時期を迎えている。サーバ環境では、Web Serviceの実用化に向けた動きがさまざまな分野で進展しつつある。Libertyの仕様公開もそうだし、XML関連のJava APIも整備が進んでいる。しばらくは、中断中の遅れを取り戻す意味でも、こうした状況を少しずつ整理していきたいと思っている。
