■ 機能モデル

おね〜さんと、

ほげたんのっ!!

3 Minutes Networking、

Supplement !!

ん〜。プロトコルモデル、情報モデル、名前付けモデルと話をしてきたわけだけど。

うん。TCPを使ったクライアント・サーバモデル、DITとオブジェクト、DNとRDN、だったよね。

まぁ、簡単にまとめるとそうなるわね。で、今回は機能モデルを説明しようかと。

機能モデル？ 機能っていうと〜、LDAPの機能だから、ディレクトリの検索？

そうね、それがメインよね。つまり、LDAPによるディレクトリに対するオペレーションが今回の話。

オペレーション？ あぁ、操作ね。

そゆこと。さてさて、LDAPってなんでその名前があるんだっけ？

え？ Lightweight(軽量)のDAP[Directory Access Protocol]だから？
X.500のDAPを軽量化したから、だったよね。

そうそう、X.500DAPがあって、それを軽量化したんだったわよね。X.500は優れたプロトコルだけど、その豊富な機能が逆にアダとなっていた、という話を前したわよね。

まぁ、標準化団体が作るのってそういう傾向があるよねぇ。

あるわね、標準化するあまりって奴ね。まぁ、それはいいとして、このオペレーション部分がLDAPとX.500DAPで異なるわけ。つまり、X.500DAPの多彩な機能を、よく使われる機能のみ抽出したものがLDAPってことね。

へぇ。よく使われるのって何？

次の3つね。

認証、検索・比較、更新。これ、ディレクトリに対する操作だよね？

もちもち。で、まず、LDAPは前も話したように「要求」と「応答」から成り立ってるわけで。
このLDAPメッセージだけど、ちょっとわかりにくいというか、う〜ん。

わかりにくいの？

例えば、HTTPを考えてみると、操作ってメソッドでしょ。GET、POST、HEADなどね。
でも、HTTPメッセージって、メソッドによってメッセージ構造って変わらないでしょ？

変わらないね。HTTP要求メッセージだと、メソッド、URI、バージョン、メッセージヘッダ、ボディ。ヘッダはあったりなかったりするけど、構造自体は変わらないよね。

DNSやFTPでも基本的には変わらないでしょ。でも、LDAPは操作によって構造が違うわけ。
この構造、メッセージフォーマットは、ASN.1によって記述されてるんだけど、これがまたわかりにくいのよ。

あせん・わん？

ASN.1についてはまたいずれ。でで、これからその操作による構造なんかも話しながら、操作について説明していくわね。

了解です。

■ 認証オペレーション

まず、認証オペレーションからいきましょう。え〜っと、何やるかわかるわよね。

認証でしょ？

ストレートねぇ。まぁ、そうなんだけど。つまり、ディレクトリに対してのユーザ確認ね。
LDAPではこのbind操作をまず行う。すべてのオペレーションはbindから始まるってことね。

なるほど。操作するにはまず認証が必要なんだね。理にかなってるっていえばそうだね。

でしょ。で、まずこのBind要求メッセージの中身を説明すると。

……何コレ？

これがASN.1による構文ね。まぁ、今までのように書くとこんな感じ？

あー、あーあー。なんとなくさっきのASN.1の意味がわかるような。
バージョンはともかく、ユーザのDNと、認証情報ってことだね。っていうか、こっちで書いてよ、おね〜さん。

正式にはASN.1だからねぇ。まぁ、いいでしょ。ASN1.構文長いし。
で、Authenticationのところ、0と3の2つのチョイスがあるんだけど、BINDには3種類の認証が存在するの。

？ Authenticationは0と3の2種類なのに、3種類？
それにSASLって初耳なんですけど？ ▼ link

汎用認証プロトコルね。SSL/TLSと同じような感じで、使うの。
ともかく、このSASLは置いておくとして。

置いとくんだ。

SASLの説明まで話すと長いし。というわけで、チョイス「0」で匿名認証と単純認証の2種類を説明するわね。
bind操作はこのようになるわけ。

値があるかないかで、匿名認証か単純認証か変わるってことだね。

そういうことね。ポイントとしては、まず、サーバがどの認証を受け入れるかは、サーバ側の設定次第ってことね。匿名はダメとか、名前のみ単純はダメとか。

必ずしも匿名認証が可能ってわけじゃないんだね。

そしてもう１つ。パスワードは平文になっちゃうってこと。パスワードの保護をしたい場合は、SASLを使うか、SSL/TLSを使ってLDAPSにするか、しないとダメね。

なるほど。

さてさて、一方のunbind操作だけど、これはディレクトリアクセスの終了の際に行う操作になるわ。
unbind操作は要求のみで応答がない操作で、unbindを受け取ったサーバはそのまま切断するわけ。

bindで接続をかけて、ディレクトリにアクセス後、unbindで切断、ということだね。

■ 検索・比較オペレーション

さてさて、次が検索・比較オペレーションね。

検索[search]、比較[compare]だね。

まぁ、わかると思うけど、条件を満たすエントリを探し、そのエントリの情報を読み出すの検索、指定したエントリが属性値を持っているか調べるの比較。この2つの操作ね。

っていうか、要はディレクトリに対する検索なんでしょ？

ストレートに言えばそうね。つまり、ディレクトリサービスとしての機能こそがこの検索操作になるわけね。

そうだね、ディレクトリサービスって「ディレクトリを作成・管理し、その情報を検索して提供する」んだから、検索って必須機能だもんね。

さて、その検索機能だけど、え〜っと、ホントはASN.1書くのがいいんだけど、まぁアレ面倒くさいし。
ま、search要求メッセージに含まれるのはこういうの。

Booleanってなんだっけ？

「真(true)」か「偽(false)」かの値のことね。
ともかく、ポイントの1つ目はbaseObjectとscope。DITのどこを検索するかという範囲を決めるわけね。

見てわかると思うけど、baseObjectでDITのツリー（サブツリー)を決定し、scopeでさらに範囲を絞るっていうイメージかな。

うん、わかるよ。

次はfilter。フィルタってことだから、検索結果にフィルタをかけるって意味でしょ。これで「望む結果だけを得る」ためにフィルタをかける、つまり、検索条件になるわけね。条件にはいくつかあるわ。

これらの値で、条件をつけて、望む属性型、属性値を入手するわけね。

なるほどだけど、もうちょっと具体例が欲しいかな？

我侭ねぇ。具体例の前にもう1つだけ。typesOnlyパラメータは「属性値を読み出すかどうか」で、これをtrueにしておかないと、属性型だけ入手することになるわけ。

ん？ 属性型だけ？

typesOnlyがfalseの時は、持っている属性型だけが検索結果で入手できるのよ。
ちなみに、どの属性型を入手したいかという条件はattributesパラメータで指定する、と。

う〜ん。わかるようなわからないような。

じゃあ、例をだしてみましょう。

なるほどだよ。

で、もう1つのことを話さないと。比較[compare]操作。これは「指定したエントリが属性値を持っているか調べる」って説明したわね。

ん〜でも、おね〜さん。その属性値を持っているかどうか調べるんだったら、search操作でもできるじゃない？
例えば、さっきの例でいくと…。

これで、太山田一郎だけを検索(baseObjectに太山田一郎のエントリを指定、scopeは1のためbaseObjectだけ検索)するし、これでエラーが返ってきたら、phonenumberが09012345678じゃないってことだし、返ってきたらOKってことでしょ？

うん、たしかにほげたんの言うとおり、間違ってない。

でしょ〜〜〜。

うん。今の返答はちょっとムカついたから、あとでちょっとだけ向こうの世界を見てもらうとして。

………。

searchで比較操作もできないこともないけど、ちょっと問題があるのよ。
それは、search応答に「値が入ってしまう」ことよ。

それのどこが問題なの？ 値が入って正常な応答なら、属性値を持ってる。
値が入ってない、否定応答なら、属性値を持ってない。でしょ？

まぁそうなんだけど。つまり比較操作は、検索操作で「値が入って困る」時に使うの。
つまり、パスワード入力などね。

パスワード入力？

そう、こんな感じ。

なるほど。「読み取られたくない属性値」が「一致するかどうか」を確認できるわけなんだ。

そうそう。そういうこと。
他にもね、こういうのもあるわけ。

エントリにない属性の検索、この場合initials(イニシャル)なんだけど、これを行った場合は「エラー応答」しか検索操作では帰ってこないわけ。その属性値が一致しないのか、属性そのものがないのかわからないの。

比較操作は違う？

そゆこと。比較操作は応答のコードがそれぞれで異なるから、「属性値不一致」なのか「属性値がない」のか識別できるわけ。

なるほど。使い道がやっぱり違うわけだね。

さて、次の更新操作だけど。思ったより認証と検索・比較にてまどっちゃったから、次回にしましょ。

ありゃ。

じゃ、また次回。次回でLDAPも終わりかな？
おね〜さんと、

ほげたんのっ!!

3分間ネットワーク、

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