■ X.500

おね〜さんと、

ほげたんのっ!!

3 Minutes Networking、

Supplement !!

さてさて。前回ディレクトリサービスについて話したけど。
今回からは現在、ディレクトリサービスの中で最も注目を浴びているLDAPについて話すわね。 ▼ link

え？ そんなに注目を浴びてるの？

さぁ？

うわ。

まぁ、そういうことにしておくと話が早いのよ。
ともかく、ほげたん？ LDAPって、Lightweight Directory Access Protocolだけど、最後のDAPはともかく、Lightweightって変な名前じゃない？

ライトウェイト？ 「軽量の」？
言われてみればそうかなぁ、「軽量の」「ディレクトリアクセスプロトコル」。何に対して「軽量」なのかな？

うんうん。ポイントはそこよね。何かがあって、それに比べて「軽量」なのがLDAPなの。
その「何か」だけど。それは、X.500という規格が前提にあっての話なの。▼ link

アルファベット1文字で始まる規格はITU-T。

ぷっ、なにそれ？ 確かにそうだけど。
X.500はITU-Tが国際標準として規格化したディレクトリサービスについての標準規格よ。

それとLDAPにどういう関連性が？

まぁまぁ、順番に話させてよ。
X.500によるディレクトリサービスは、簡単に書くとこんな感じ。

クライアントがDUA、サーバがDSA、検索に使うプロトコルがDAP………DAP？
Directory Access Protocol？ LDAP？

そう。DAP。さぁ、これでLDAPが何に対して「軽量」なのかわかったわよね？

うん。このX.500DAPよりも「軽量」ってこと？

そゆことです。もともと、この国際規格X.500ってのは、ディレクトリサービスの規格として、とても優れた規格だったの。
どれぐらい優れているかっていういと、その完璧な構造と豊富な機能があまりに複雑な構造であまりに多機能で使いこなすのが大変なぐらい。

……ダメじゃん。

で、「インターネット」という環境ではさすがに実装は無理じゃないかって感じだったのね。
なので、IETFがそのX.500DSAにかる〜くアクセスできるようにって開発したのがLDAP。

へ〜、じゃあもともとはX.500の廉価版って感じなのかな？

廉価版ってのはちょっと言い方が悪いけど、そう的外れでもないかも。
で、これが思ったより便利なので、X.500DAPの代替としてだけでなく、他のディレクトリサービスにも使えるようになったわけ。

へ〜。

あとは、ITU-T、ISO/IECのOSI参照モデルから、IETFのTCP/IPモデルで運用されてるってのも大きいかも。

あぁ、なるほど。TCP/IPが使えるのは大きいよね。

■ LDAPモデル

じゃあ、実際LDAPについて説明するとしましょう。
え〜っと、どこから説明すればいいかな？

おね〜さん。それはないよ。

と言われてもねぇ。LDAPは結構大変なプロトコルなのよ、これが。
一気に説明するとなると、骨が折れるというか。まぁ、骨が折れると言っても主にほげたんのだからいいんだけど。

僕の!?

えいっ。（ﾎﾟｷｯ）

ぐはっっ!!

そうねぇ。やっぱりモデルの話からしましょう。

僕、ほったらかしですか。（ﾌﾟﾗｰﾝ）

LDAP自体は結構いろいろな側面があるので、一気に全体を説明するのではなく、それぞれの側面ごとに説明していこうかな、っと。
で、LDAPを次のモデルに分解してみました。

ははぁ？ 何がなにやら？

ん、だから。LDAP全体をいくつかの「モデル」に分割したわけね。
この5つのモデルをまとめると、だいたいLDAPがわかるかなぁ、ってね。

ふ〜ん。で、どれから説明してくれるの？

そうね。並べた順でいきましょう。

ってことは、プロトコルモデルだね。

■ プロトコルモデル

LDAPはX.500DAPをTCP/IPで簡易化したもの、だったわよね。おかげでOSIプロトコルの呪縛から逃れてるわけなんだけど。

呪縛って。

LDAPはTCPを使用するアプリケーションレイヤプロトコルよ。

TCP389番ポートと、636番。LDAPSって、SSL/TLSを使うの？

[LDAP over SSL]で、LDAPSね。HTTPとHTTPSの関係と同じ。

あぁ、なるほど。

で、LDAPはおなじみクライアント/サーバモデルで動作するわけね。

ん。おなじみだね。

あれ？ さっきでてきたDUAとかDSAとかの用語じゃないんだ？

あれはX.500の用語だからね。普通に「クライアント」「サーバ」でOK。

■ 情報モデル

さて、次は情報モデルね。LDAPはあくまでも、「X.500DAP」の簡易型、つまり「ディレクトリへアクセスする」ためのプロトコルでしょ？

ディレクトリにアクセスして、「検索」したりするプロトコルってことだよね？

そうそう。なので、ディレクトリについてはX.500のデータモデルを使用しているの。
あ、ただしX.500以外のディレクトリでもOKなことはOKよ。

あ、そうなんだ。

LDAPバージョン3からはX.500以外のディレクトリでもOKになってるの。
さてさて、そのX.500ディレクトリのデータモデルといえば…前回の図を見てみましょ。

ディレクトリはエントリと属性からできている、って前回に話したわよね。
まず、現実世界にあるもの(オブジェクト)を切り取ってディレクトリに格納することからスタートね。

オブジェクトをディレクトリに格納する。

格納されたものがエントリ。で、エントリが持つ情報が属性。ここまではいい？

うん。そこまでは聞いたよ。

で、まず。オブジェクトをディレクトリに格納してエントリにするわけだけど。
オブジェクトって実世界にあるもの、人、組織、地域、国、なんでもいいんだけど、どの情報を抜き出して、ディレクトリに格納するか決めておかないと。

現実世界にあるオブジェクト、例えば「人」だとするよね。
で、「人が持つ情報」の中から、「どの情報をエントリするか」を決めるってことでいいのかな？

そう。それをオブジェクトクラスというの。

オブジェクトクラスには、エントリがどの属性を持たなければいけないかなどが決まってるわけね。

あぅ。クラス…。なんかもう、そのままオブジェクト指向だ。

で、エントリには属性がある。属性は「属性型」と「属性値」から成り立ってるの。

属性型と属性値？ 属性値は、属性が持つ情報だってわかるけど、属性型ってなに？

属性型は属性値が取りうる値や検索の際の条件を決めておくの。

なるほど。型が決まっていて、好き勝手に値を入れることができないようになってるんだ。

「電話番号」属性に、顔写真があったら笑っちゃうからね。
で、これら属性を持つエントリだけど、これをディレクトリに格納するわよね。

そりゃそうだね。しないと意味がないからね。

前も話したけど、ディレクトリではエントリを木構造で格納するの。
ファイルシステムのディレクトリなんかいい例よね。

そういえば、DNSの名前空間も木構造だよね。

そう言われればそうね。DNSもディレクトリサービスだからね。
で、このエントリを格納する木構造を、DITと呼ぶの。木構造の利点はわかるわよね？

理解しやすい。特に情報が多い場合、階層化することによって、体系化できるとか。
組織とかを表現しやすいよね。

そうそう。でね？ 木構造にしたがってエントリを配置していくわけ。
最上位、つまり根に位置するエントリが「ルートエントリ」。で、それぞれ節にエントリを配置するってわけ。

なんか、DNS名前空間みたいだね。

そうね、DNS名前空間をイメージしてもらうと一番ラクかな。
ちなみにピンクのエントリが「組織」のオブジェクトをエントリにしたもの。青のエントリが「人」のオブジェクトをエントリにしたもの、ね。

橙のrootは？

ルートエントリは特別なエントリで、DITを管理するディレクトリサーバ用の情報のエントリ。
さて、ほげたん？ X.500ディレクトリの概略がわかった？

オブジェクトにオブジェクトクラス。エントリと属性。
そして、格納したDIT。

そうそう。オブジェクトクラスや属性、DITについては先で細かくやるから、まずこれらのX.500ディレクトリの基本を覚えておいてね。

あいあい。

で、他のモデルは次回にします。
おね〜さんと、

ほげたんのっ!!

3分間ネットワーク、

サプリメントでした〜〜〜っ!!