「シングル・サインオン」へのファーストステップ：ディレクトリ統合（2）

ディレクトリとLDAPを理解する

　第1回「なぜ『シングル・サインオン』は必要なのか？」で解説したように、ユーザーIDやパスワードの認証管理に、ディレクトリやLDAP（Lightweight Directory Access Protocol）などの技術が使われています。そこで第2回は、「シングル・サインオン」へのファーストステップとして、それらに焦点をあてて解説します。LDAPが特に使われるようになった経緯から、LDAPの4つのモデルと、3つの機能、メリットやデメリットを解説し、具体的に利用できる製品までを紹介します。

データベースより自由度の高いディレクトリ

　ディレクトリとは、目的の情報を探し出す仕組みのことです。わたしたちの生活に当てはめれば、図書館の目録や電話帳、ショッピングセンターの案内板などがそれにあたります。そして私たちは、より情報を探しやすくするために、見出しをつけたり、項目で分類をしたりなどの工夫をしています。

　コンピュータシステムで利用するディレクトリの起源は、メインフレームがコンピュータの主流だった時代にさかのぼります。当時メインフレーム上には、登録されたユーザーの電話番号などを検索する電話帳ツールが提供されていました。これがシステム上で利用するディレクトリの起源であるといわれています。

　リレーショナルデータベースに代表されるデータベースとディレクトリは、混同されがちですが、概念が異なります。ディレクトリは広い意味でデータベースの一種です。例えば、IBMのディレクトリサーバのエンジンはDB2 UDBを使っています。

　データベースはさまざまな目的に使うため、自由にテーブル設計ができ、テーブル構造についての標準はありません（自由に設計できるのがデータベースですからテーブル構造を標準化するというのはデータベースと相反した考え方ですが……）。またデータベースは複数サイトから同一レコードに対してアクセスが発生する可能性があるため、各サイトからのアクセスとの調整をとり整合性を確保するための機能（2フェーズコミット）≪≫に代表されるように、関連する複数の処理を1つの処理単位としてまとめる機能（トランザクション機能）を備えるのが一般的です。

　一方、ディレクトリはあらゆる場所から誰もがいつでも検索できる機能に特化し、データの更新に関してはデータベースにあるような強力なトランザクション機能はありません。

　ディレクトリに分類される技術にはDNSやFinger、Radiusなどがありますが、ここでは、もっとも代表的なLDAPについて解説します。LDAPは本連載の主題であるディレクトリ統合とシングル・サインオンには不可欠な機能です。最近では、ユーザー認証の共通基盤としてLDAPを使用するものが増えてきました。また、多くのOSやWebサーバのログイン時のユーザーIDとパスワードのチェックにもLDAPが使用されています。

・LDAPが「シングル・サインオン」に利用される理由

　LDAPはX.500をベースにしています。X.500は、1980年代後半に開発されたPCで利用できる最初のオープンなディレクトリのシステムです。X.500はOSI（Open System Interconnect）ネットワークモデルをベースにしたディレクトリ接続のためのプロトコルでしたが、LDAPはそのX.500と、TCP/IPネットワークモデルをベースとするプロトコルです。

　LDAPの規格はIETFが中心に制定するRFCで規定されています。LDAPには初期に制定されたバージョン2と、現在の主流であるバージョン3（LDAP V3）があり、それぞれのバージョンを規定するRFCが複数存在します。

　LDAPでのデータの表現方法には一定の標準が規定されています。RFCでは属性やオブジェクトクラス（属性とエントリのひな型）の定義をLDAP V3として規定していますが、X.500の厳密すぎて使いにくかった部分が、LDAPでは自由度の高い設定になりました。これがシングルサインオンにLDAPが採用される理由の1つです。

LDAPの4つのモデル

　RFCで定義されているLDAPは、以下の4つのモデルで捉えることができます。

・情報モデル

　データの形式と情報の単位を定義します。LDAPで扱う情報の最小単位は「エントリ」で、リレーショナルデータベースの「行」に当たります。

　1つ1つのエントリには複数の属性（attribute）が含まれています。属性はリレーショナルデータベースでは「列」です。また属性には、「型」と「値」があり、例えば、姓（Sir Name=SN）という属性の型に対して高橋（Takahashi）という値が入ります（表1）。

　属性の型では、検索時の比較方法を情報フォーマットとして定義します。LDAPで使用される複数の属性は「オブジェクトクラス」と呼ばれています。

　例えば、inetOrgPersonというオブジェクトクラスは人を表すものとして頻繁に使われ、姓、名、電話番号、住所、電子メールアドレスなどの属性を持っています。オブジェクトクラスを使用すれば、ベンダや製品が異なっても、データを取り出したり更新したりする際に形式の違いを意識する必要がありません（また、属性やオブジェクトクラスの定義をまとめたものをスキーマと呼ぶことがあります）。

・ネーミングモデル

　ディレクトリへのデータの格納方法を定義します。LDAPはOracleやDB2などのデータベースソフトウェアのように、ハードディスクやメモリ中へのデータの配置を定義していないので注意が必要です。

　ネーミングモデルに関してLDAPが定義しているのは、理論的なモデルのディレクトリツリー（図1）だけで、ハードディスクへ書き込む順番や形式は自由です。

図1　 LDAPのディレクトリツリー

　LDAPのディレクトリツリーはUNIXやWindowsのディレクトリの表現方法に似ていますが、以下のような細かい違いもあります。LDAPのディレクトリツリーには/（root）エントリは必須ではありません。また、UNIXやWindowsではフォルダやディレクトリそのものにはデータを持たせませんが、LDAP上のエントリはデータを持ちながらその下に階層を作ることができます。

　一番大きな違いはエントリの名前の呼び方です。UNIXやWindowsではrootを一番左に表記して、右に向かって階層を下るように絶対パスの名前を表記します。

　LDAPでは逆に右から左に向かって階層を下るようにエントリの名前を表記します。

　この例のcn=Satoshi Takahashi,ou=network,o=atmarkit,c=JPをDN（Distinguished Name）と呼びますが、DNはツリー構造をそのまま名前にするので、あるツリー中のエントリの名前は必ずユニークになるという特徴があります。

　また、ツリー状のデータ構造を持つLDAPのネーミングモデルは、組織に属している個人のデータを表現するのに向いています。違う組織に同姓同名の人がいてもツリーの階層で名前を表せば、名前のユニークネスを保証できます。

・ 機能モデル

　機能モデルは、LDAPのクライアント／サーバ間のプロトコルを規定しています。実際にデータをどのように操作するかを定義しているということです。ここで規定されるLDAPのプロトコルの一連の操作は、「検索、更新、認証」の3種類に大別され、「接続し、何らかの命令を送り、結果を受け取って切断する」ことで終了します（図2）。

図2　LDAPプロトコルの動作概要

　LDAPクライアントがサーバに接続する際には、まず認証を行い、その後の命令を受け付けるか否かを決めます。矢印の流れのとおり、クライアントとサーバは必ず1対の命令と命令の実行結果を送り合います。また、検索命令には多様な検索条件を付けることができ、ディレクトリとしての利便性を実現しています。

・ セキュリティモデル

　セキュリティモデルは、認証、アクセス制御から成り立っています。認証の方法はいくつかありますが、もっとも一般的なのはユーザーIDとパスワードによる認証方法です。エントリのDNで表現したユーザーIDとそのパスワードをサーバに送信すると、サーバはLDAPディレクトリ内のデータとマッチングさせて認証の成否を判断する仕組みです。

　現在のLDAPのRFCでは、LDAPサーバに接続するときの認証、それから接続するときの通信セッションの暗号化（SSLやTLSを用いる）は標準化されていますが、いったん接続した後の「どのデータに誰がアクセスするか」というアクセス制御は、まだ標準化されていません。現在は、製品によって独自の実装があり、アクセス制御の標準化が進められている段階です。

アプリケーションの認証におけるLDAPの３つの機能

　LDAPサーバ自体は単なる情報の入れ物ですので、LDAPの利用方法はLDAPクライアントの機能に依存します。

　LDAPクライアントとしてもっとも普及しているのはNetscape Navigator、Internet ExplorerなどのWebブラウザです。実際にWebブラウザのLDAP機能を使用する人は少ないかもしれませんが、Netscape Navigator、Internet Explorerともに、メールなどを送信するときに使用するアドレス帳に、PCの中のデータではなくLDAPサーバからデータを検索する機能を持っています。

　アプリケーションで認証を行う際に、LDAPクライアントから利用できる機能は、以下の3種類があります。

　1番目の認証機能は、ユーザーがLDAPクライアントに入力したユーザーIDとパスワードを用いてLDAPサーバに接続操作を行うと、LDAPサーバは認証を行いその結果を返します。LDAPサーバでの認証が成功したことを基に、アプリケーションは認証を「成功」と判断します（図3）。

図3　LDAPサーバの認証機能を利用する

　この方法では、LDAPユーザーがログインしてくるたびにLDAPサーバに接続を試みる必要があります。パフォーマンス的には認証のたびにLDAPサーバへの接続と切断を繰り返すことからあまり好ましくありません。

　2番目と3番目の検索機能と比較機能では、アプリケーションがあらかじめ管理者用のIDでLDAPサーバに接続しておきます。接続、切断をほとんど行わないため、パフォーマンス面で有利です。

　 この状態で、あるユーザーの認証を行う場合には、検索命令でユーザーIDに対応するパスワードを取ってきてアプリケーション上で確認をするか（図4）、比較命令でユーザーIDをキーにしてパスワードを送信しLDAPサーバにパスワードが合致するかを確認させます（図5）。

図4　LDAPの検索機能を用いてユーザーIDをキーにパスワードを取り出してチェックする

図5　LDAPの比較機能を用いてユーザーIDとパスワードが正しいかチェックする

　LDAPサーバにパスワードを格納するときには、平文のまま格納するか、暗号化するかをLDAPサーバの機能として選択できる場合があります。逆に、LDAPサーバの認証機能を呼び出す場合には、パスワードがどのように格納されているかを気にする必要はありません※1。

LDAP製品の各ベンダの特徴

　現在多くのベンダからLDAPサーバ製品が提供されています。その中で代表的なものをここで紹介します。

　IBM Directory Server、 Sun ONE Directory Server、OpenLDAPはLDAPのみをサポートする単機能サーバの位置付けです。Novell eDirectory、Microsoft Active DirectoryはNDSやADSIなどLDAP以外のプロトコルやAPIからの操作も可能な複合型のディレクトリ製品として位置付けられます。詳細は以下のとおりです。

属性やオブジェクトクラスが異なると参照できない

　LDAPの最大のメリットは、規格が統一化されていて、異なるベンダ、製品の組み合わせでも情報の検索、更新が行えることです。また、RFCで規定されているLDAPの標準スキーマは、インターネットにかかわる属性を持ったオブジェクトクラスなどを定義しているので、インターネットで情報検索をする際に使いやすいデータが定義できます。

・LDAPのデメリット

　一方、認証やシングル・サインオンのためにLDAPを使う際の課題は現在2つあります。

　LDAPにはRFCで定められているオブジェクトクラスが何通りかあります。また、LDAPは標準スキーマを拡張することを許可しているため、製品によっては独自のオブジェクトクラスになっている可能性があります。

　そこで、認証情報の格納庫（＝LDAPサーバ）を一元化し、複数のアプリケーション共通のディレクトリを参照する方法がありますが、ここで問題が発生する可能性もあります。

　あるユーザーの認証情報を格納するオブジェクトクラスの記述方法が統一されていないと、サーバでの参照ができません（図6）。「LDAPの機能」の節で認証方法のパターンを説明したように、検索や比較命令を使用する場合、指定する条件に異なるオブジェクトクラスを指定していると互換性の問題が発生します。

図6　オブジェクトクラスが異なるために検索ができない

　また、実際に頻繁に発生する問題に、アプリケーションからLDAPへユーザーIDの検索命令を出す際に、ユーザーIDをどこの属性の値にするかがアプリケーションごとに異なる可能性もあります（図7）（しかし、中には条件指定を変更できて、問題を回避できる場合があります）。

図7　異なる属性を検索条件に指定しているために検索がうまくいかない

　もう1つの大きな問題は、LDAPサーバ間でデータを複製する仕組みがまだ標準化されていないことです。例えば、異なるベンダのLDAPサーバが社内のネットワークに配置されている場合に、パスワードの変更を同期することができません（図8）。

図8　パスワード更新が反映されない

　また、プロトコル的に異なるベンダ間のLDAPサーバを接続できたとしても、パスワードの暗号化形式が異なる場合には、パスワードの同期は非常に難しくなります。

　これらのデメリットにあげたような互換性の問題を解決する決定的な策はまだありません。対策としては、LDAPを利用するアプリケーションがLDAPを操作する時のオブジェクトクラスの指定や属性の指定を変更できるように実装していくしかないでしょう。