LDAPアプリケーション入門：ディレクトリサービスの仕組みと活用（5）

　今回から2回にわたって、ディレクトリを社内でさらに活用していく観点から、LDAPプログラミングの概要と展開を説明していきます。また、プログラミングを理解する過程で、LDAPディレクトリの構造そのものへの理解も深められることでしょう。

LDAPプログラミングのススメ

　LDAPを使ったユーザー検索で最もニーズが高いのは、メールアドレスの検索や社員情報の検索でしょう。これはエンドユーザーに向けた社内サービスと言えます。しかし最も不満の残りやすいサービスとも言えます。例えばWindowsに標準で付いてくる「人の検索」やメーラーのアドレス帳といったアプリケーションでは、表示される項目が固定されているため必要とされる詳細な情報が表示されなかったり、日本語でうまく表示されない場合も多々あるからです。

　これらの原因は既成のアプリケーションをそのまま社内で流用しようとしているところにあります。もともとこれらはインターネット全般で利用される想定で作られており、業務に向いているとは限りません。また、社内固有のニーズもあることでしょう。

　それであれば、いっそのことLDAPアプリケーションを作ってしまいましょう。基本を覚えてしまえばそれほど難しいものではありません。むしろ、GUIプログラミングの方が難しいぐらいです。また、既存の内製アプリケーションをLDAP対応にしたいなど、LDAPディレクトリのさらなる推進はこれからのシステム展開にも大きなメリットをもたらしてくれることでしょう。

LDAPのAPIライブラリ

　LDAPプログラミングをするにあたって、いくつもの便利なAPIライブラリがすでに用意されています。LDAPのプロトコルを知らなくとも、これらのAPIを利用すれば、簡単にLDAPサーバへの検索や変更などが行えます。

　元々LDAPはAPI定義も含めた標準仕様であるため、環境を用意しやすく、さまざまなAPIライブラリが存在しているのです。以下はその中でも主なものです。

●Microsoft ADSI(Active Directory Service Interface) 2.5

　名前が示す通り、Active Directoryへアクセスするためのライブラリです。Active Directoryは標準のネットワークプロトコルとしてLDAPを使用していますので、LDAPはもちろん、Windows NT 4.0以前のNTネットワーク（ドメイン）、NDSなどにも対応しています。言語としてC／C++、VB、またはADO（ActiveX Data Object）にも対応していますので、VBScriptやそのほかのスクリプト言語からも呼び出すことができます。ただし、もちろんWindows環境でしか使えません。またWindows 2000には標準で添付されていますが、Windows 95／98／NT 4.0ではあらかじめランタイムライブラリを導入しなくてはなりません。

●Sun MicroSystems JNDI(Java Naming and Directory Interface) 1.2.1

　JNDIは以前はJavaの拡張ライブラリの1つでしたが、Java1.2より標準として含まれるようになりました。Javaはご存じのようにインターネット環境を前提とした言語／プラットフォームですので、このように独立したディレクトリサービスも包含しているわけです。

　JNDIはサービスプロバイダという独自の概念を持っています。サービスプロバイダはAPIの中のサブAPI部品のような考え方で、この部品に何をそろえるかで、対応するディレクトリが追加可能になっています。例えばサードパーティベンダが新たなサービスプロバイダを提供することで、JNDIにより、ユーザーは透過的にどのディレクトリも同じ手順でアクセス可能になります。現在ではLDAPのほかに、RMI（Remote Method Interface）、NIS、DNS、NDSなどのサービスプロバイダが用意されています。

●Netscape Directory SDK 4.0

　Netscape CorporationがJavaとC言語で提供するAPIです。本来はNetscape Directory ServerのためのAPIです。LDAPにのみ対応します。またJNDIのサービスプロバイダとしても対応しています。

　ほかの2つに比べると、ある程度LDAPの「作法」を意識しなくてはならないオーソドックスなAPIですが、逆にLDAPにアクセスするなら、最も素直な作りをしているとも言えるでしょう。本稿では次回以降、このNetscape Directory SDKを基にLDAPアクセスの手法／LDAPディレクトリの概要を解説していくことにします。

LDAPディレクトリの基本要素

　まずアクセスの前に、そのアクセス対象であるLDAPディレクトリが実際にどのような構成をしているのか、知る必要があります。これまで説明をしてこなかった部分もありますので、簡単に説明しましょう。

図1　LDAPディレクトリの仕組み

　LDAPディレクトリは、一種のデータベースととらえることができます。LDAPディレクトリ自体を示す「サーバ」またはデータベース自身の中に、個々のデータを示す「エントリ（Entry）」が含まれています。これはデータベースのレコードと解釈しても構いません。

　レコードである以上、特定するためのユニークな識別子が必要です。これが何度か登場してきたDN（Distinguished Name：識別名）です。LDAPディレクトリがX.500規約に準拠しているという意味は、このDNの付け方に特徴があるからです。cn、ou、o、といった名前の構成要素から成り立ち、階層的にデータが所属していると解釈します。右の要素から左に向かってツリーを下るものとし、「,（カンマ）」で各要素をつなぎます。

　これがDIT（Directory Information Tree）と呼ばれるデータの階層格納構造です。cで国を、oで組織／会社を、ouでサブ組織（部、課など）を、cnで固有の名称（氏名など）を示し、ユニーク性を保証します。大きく考えれば、世の中のすべての存在が1つのツリー内で定義される、という考え方です（実際にはLDAPサーバ間にデータ依存関係がなければ、1つにはならないのですが）。

図2　LDAPディレクトリの階層構造

　このDNの記述は決まった1つの形式に縛られていない点に注意してください。例えば、「cn=Taro Yamada,o=ABC-Syouji,c=JP」というDN定義もあり得れば、「mail=Taro.Yamada@ABC-Syouji.co.jp, uid=tyamada, l=Tokyo, o=ABC-Syouji,c=JP」という記述もあり得ます。どちらも間違いではありません（実はこの差異がLDAPの相互運用性を難しくしているのですが、それはまた別の機会に説明しましょう）。

　また、「o=ABC-Syouji, c=JP」といったほかのデータを含む「枝（ブランチ）」の部分も立派なデータとして扱われます。ここでは、「日本のABC商事」という会社を示す1つのエントリ情報と理解できます。つまり、親エントリ（会社）が複数の子どもエントリ（社員そのほか）を含んでいる、と理解してください。これがDIT、ツリーと呼ばれるゆえんなのです。

　エントリには当然詳細なデータ、つまり属性が含まれます。データベースで言えばフィールドに当たります。これを「アトリビュート Attribute」と呼びます。アトリビュートには2つの要素があります。アトリビュート名（Attribute Type）とアトリビュート値（Attribute Value）です。LDAPで使用されるアトリビュートは主に、文法はRFC2552で、種類はRFC2556で定義されています。

　例えば「mail」というアトリビュートには「Taro.Yamada@ABC-Syouji.co.jp」などというメールアドレスがセットされることになっています。

　これまで出てきたo、ou、cやsn（姓）、givenname（名）、証明書を格納する「userCertificate」なども実はアトリビュートです。アトリビュートに含まれるアトリビュート値は配列として定義されることがあります。例えば、英語と日本語で氏名（cn）を定義する、などの使い方をします。または、複数のメールアドレスを持つ場合もあるでしょう。

　もう1つの概念として、「オブジェクトクラス（objectClasses）」という考え方があります。エントリはそれぞれ、必ず1つまたは複数のクラスに所属しています。オブジェクトクラスでは、そのオブジェクトクラスが必ずどのアトリビュートを含まないといけないか、任意で含んでもよいかが定義されています。言うなれば、エントリのための「ひな型」と言えるでしょう。同じ社員を示すエントリなのに、含まれるアトリビュートの種類がばらばらでは、データの整合性が保てないためです。

　そこで、例えば「Person」「inetOrgPerson」などといった、含むデータのレベルに応じたオブジェクトクラスを標準仕様で定義して、エントリを分類可能にしています。オブジェクトクラスはそのほか「継承」や「拡張」など少し難しい特徴も持っていますが、ここではあまり考えないことにしましょう。なお、オブジェクトクラスもアトリビュートという形でエントリに保持されます。