( 2 / 2 )

３．統合認証の幻想

　一見便利な統合認証システムであるが、実は思わぬ落とし穴があることに気をつけなければならない。グループウェアやe-Leaningといった一般的なアプリケーションサーバは、認証を、LDAPシステムをはじめとする外部のディレクトリサービスに依頼することはできる。では、ユーザーIDは外部のディレクトリサービスだけに存在していればよいのかといえば、残念ながらそうではない。たとえば、グループウェアの場合、ユーザーごとにスケジュールやToDo、ドキュメントの管理を独自のデータベースで行っている。つまり、外部のディレクトリサービスだけでなく、内部のデータベースにもユーザーIDをキーとしたレコードを登録しておく必要がある。統合認証システムを構築したとしても、アプリケーションサーバへのユーザー登録作業が無くなるわけではないことに留意しなければならない。
　では、統合認証システムは管理コストの低減につながらないのかといえばそうではない。パスワードが統一されていればパスワード忘却を訴えるユーザーは格段に減少し、それだけ窓口業務のコストを減らすことができる。また、パスワード変更を行うためのユーザーインターフェースを1種類に統合できるため、ユーザーへの利用教育といった面でもコストを低減することは可能だろう。
　Campusmate/CourseNavigでは、アカウント管理コストを低減するための施策として、Campusmate/ICAssist というアカウント管理を補助するソフトウェアとの連携をサポートしている。Campusmate/ICAssistと連携することで、中央のディレクトリサービスに新規登録されたユーザー情報を、自動的にCampusmate/CourseNavigに取り込むことができる。すなわち、管理者は1回だけユーザー登録作業を行えばよく、その他の作業を完全に自動化することが可能となる。

４．統合認証からSSOへ

　SSOとは「Single Sign On」のことである。SSOを実装したシステムは、一度認証されると、再認証することなく、他の全てのサブシステムを利用することができる。利用者から見れば、まさに理想的なシステムであるといえるだろう。
　誤解をされている方が多いが、IDとパスワードを統一するということは、かならずしもシングルサインオンとは同義ではない。シングルサインオンを実装するには、システム間の綿密な協調が必要であり、実のところ構築コストは膨大となる。特に、既に稼動しているシステムを含めたシングルサインオンシステムを構築する場合、既存システムの認証方法を完全に設計しなおす必要がある。新規に構築する場合でも、あらかじめ認証の規約を綿密にとりきめ、各システムの導入業者に対し規約に沿った設計、開発を指導しなければならない。
　冒頭でも述べたとおり、ここ数年、ポータルシステムの構築が「はやり」である。コンピュータを単なる道具ではなく、よき相談相手として活用すべく、ポータルシステムは進化しつつある。ポータルシステムの特徴は、複数のシステムへの共通の入り口になるということである。すなわち、ポータルシステムにログインすれば、権限を持ったサブシステムを自由に利用できる。こうした機能を実現しているのがシングルサインオンの機構である。
　Campusmate/CourseNavigは、富士通製ポータルシステムであるCampusmate/Potalとのシングルサインオンをサポートしている。Campusmate/Potalを共通の入り口として利用することで、Potalが提供する個人の時間割から、CourseNavigが提供する講義情報画面に直接移動するなど、密な連携も可能となっている。

５．さいごに

　いま、システムを構築するにあたり、統合認証は必須の要件となっている。また、要件を満たすパッケージも多くリリースされており、以前と比べれば統合認証環境を構築することは容易になった。しかしながら、そこから一歩すすんでシングルサインオン環境を構築しようとすると、すぐに大きな壁が現れる。この壁は、システム間の認証方式の違いであり、いずれも歩み寄ろうとしないメーカーのエゴである。こうした問題は、異なるメーカー間に限らず、残念ながら同一のメーカー内の製品であっても言えることである。
　富士通Campusmateシリーズでは、このナンセンスな壁を崩すべく、事務、図書、教育分野のパッケージの認証を統合し、完全なシングルサインオンを実現すべく、認証方式の統合を進めているところである。