【15分で終わらない】直観で理解する - LDAPとは?【話の流れが難しいページ】


このページの目的は

このページの目的は
「LDAP ってなんだっぷ?」😚って上司に聞かれても
優しく笑顔で答え😊ゆとりをもつための

ぺーじ

・・・

ではもちろんありませんが。


ダイレクトに、ldapの実像を理解して
ビビらない程度にふるまえるようになるためのページです。

「LDAPしっているかね、君?」と
言われて、ビビりながら、
話をそらしている自分がいたりしませんか?

そのまま、振り向かずに走り抜けなさい。とりあえず仕事を進めなさい。
というアドバイスに耳を傾けてはいけません。

ちゃんと理解するのです。
(ま、嘘だけどね)


実は
私も、ちょくちょくLDAPというものを耳にしていて
設計するときにとうとうそこがボトルネックになったときがありました。

その時は金曜から徹夜しながら、仕様書を見つめ
Webも   何10サイトと調べた🔍ところ
わかったことを時間節約のため
ちょっとメモっておきます。


(前置き  なげー)

LDAPとは?

LDAPの中心にあることとは?(データ形式)

単なるツリー構造のデータ形式です。

終わり。


いやー、今日も、勉強になった。


じゃあ。またね!


で終わると前置きのほうが
頭でっかちすぎますね。

もうちょっと、
ほんのちょっとだけ進めると

名前にある通りLDAPのDはディレクトリです。

ディレクトリは、 電話帳です。
windowsなどのフォルダー📁で
おなじみな形式です。

このようによく電話帳という単語が出てきます。

電話帳?なにそれ?な感じですが

LightWeight Directoryとは

簡易な電話帳です。

。。。

簡易な電話帳です。

簡易な電話帳なんです。

わけわからなすぎです。
具体的にイメージできてるのでしょうか?
知っている単語のみで構成されると理解した気になったり、理解したという人がいますが、、、こんな日本語はありません。私の短い人生には。

lightweight directoryで納得しちゃう人と、私は話が合いませぬ。

ディレクトリって、抽象的すぎ?

LDAPの略語を展開されても、
意味わかんねーよ😬と、ひとり🚬缶コーヒー飲みながら
土曜の早朝に切れていたのは内緒です。

また、同じ苦労をみんなにしてほし、、 (ごほっ ごほん)
いや、買ってでも苦労すべきだからですよ。

ええ。ほんとに。

ほんとに。 
(長くすると疑われるからこの辺で)

なにが Lightなのさ

DAPをライトに動かそうという設計ポリシーの元
作られたのがLDAPなので、
DAP。DAPを理解すること。
つまり  Directory 方式のアクセス通信規約(Access Protocol)が
何?というところが中心になります。

Directoryって何でしょうか?
フォルダ?日本人になじみが薄いですね。
directoryは何かっていうところからひも解いてみましょう。

電話帳(directory)📚って
電話番号が並んでいるNTTからもらえるゴミ。。。ではなくて、
会社にとっては宝物💎です。

電話帳に書かれているものをイメージすると
電話📞!って言いたくなりますが、

🦅視点を引いて🦅、鳥の視点で空から全体像を見ると
地域、業種、会社、部署、個人などの階層が見えると思います。

そう、これが一般的なLDAPで採用されるデータのアクセス構造です。
私も実はよくわかりませんが、
ざっくりいうと、ツリー構造で多少形を決めているようなのです。

場所?住所?オブジェクトのありかを示す方法

次に階層を表すことがわかったら、その階層を表すってどうやって?
というところが気になります。
なりますよね?IT技術者ならっ!!

c , uid , o とか  見たことありませんか?

なにこれ!?ってビビりまくりの感じですが

それぞれ
(もう、わすれちゃったけど)

c       country
l        localityName
s        stateOroProvince  Province は フランスのワイン🍷とかで聞いたことあるように、州
street streetAdress
o        companyでなく、organization、組織ですね。
ou     organization unit  部署
uid    ユーザID
cn     common name  フルネーム的な やーつだと思う
sn     surname  斉? いや姓
gn     givingname 君の名は?と聞かれているイメージ
dc     domainComponent

です。

このように cなどはなんてことはなく、単なる組織階層。
つまり組織階層のデータ形式で、今も対象のオブジェクトタイプの一種です。
(しかもこれは例として認識してもいい)

階層を指す形式は
DN :DistinguishedName という 言い方をします。
この切り分け名で、データブール内の
何をというエントリを具体的に指定します。

いっぱい単語が出てきたので、一旦まとめると。

このDNでどのエントリ先の オブジェクトを対象に通信するのがLDAPになります。Directoryが データプールで、 DNが データプール内の場所の切り分け名みたいなもの。そしてそのコミュニケーション方法(アクセスや通信方法)がAPという名が指しているものです。

言葉がたくさん出てきたので、一旦まとめながら進めると

ldapはつまり、なんてことはなく
これクレ、あれして、のためのプロトコルです。
(データベースとか、オブジェクト管理とか、資源管理と説明していた人は
   これが言いたかったんだと勝手に思ってます)

これで、
小文字にビビっていたあの頃に、もう戻れない。

「もう 驚かないで  」  キリッ

ちなみに、 c, cnとかにこだわらなく、
system内で自由に変えちゃって問題ないと思います。あんまり知らないけど。

んで、電話帳に使うケースなんてそんなになくね?

そう、私のようにくどいあなたは
なにに使ってるの?と思うかもしれません。
(決めつけと言いがかりがひどい。)

どういう形式でldapsearch をするか、
つまり、使うときはそのコマンドが
何になるか/何に使うかということが設計やシステム選定においても大事です。

認証を指しているのか、データを取りたいのか、
こういう情報源ですよと自ら名乗っているのか

というようなアクションをしたいから使うものです。

ldapsearchで DNという識別子で、何かに尋ねる。

エントリポイントを指すDN
何かをするというコンテキストを抑える必要があります。
(具体的な使用例は後述)

ldapってなんか専用のプロトコルがあるのではなく、概念みたいなものです。
形式も、固~~いきちっとしたものではなく、OSのファイルシステムの形式みたいなもので、結構自由に変えられますし、何に使ってもよさげです。

何に使える?

どういう状況下?(コンテキスト)

ケース1 :情報の取得

c, ou を指定して、telephoneNumber くれと言えば
文字通り電話帳の代わりになります。

ケース2:アカウント情報の管理

uid と password を指定すれば、認証に使えます。
(認証しても、認証内容を偽造するとか、認証証明をサービスが無視し
  適当に動いたら意味ありませんので
  ldapだけでセキュリティ担保にはなりません)

ケース3:情報源の担保:電子署名

c や cn を渡して、私はこういうものです。
けっして、けっして怪しいものではありませんと名乗ってもいい。
そして、誰かさんに保証してもらう。たしかにこの署名はあの人のものだと。
名乗らずに裏から取りに行くのは良くないこと。

ケース4 :アクセス権限の管理

WindowsのActive Directory では、認証の時
~~~部署の だれだれさん  という DN:エントリポイントで引いて、
この人、この権限まで、

~~~部署のだれだれさん、は要注意人物で この人あれだから、
この権限までと
あなたはLDAP認証先に認識されています。
(知らなかったでしょうけど)

具体例

電子署名の場合、
私はこういうものですが、として DNを付けておくと
「この人が作った情報なのでOKだと思いますよ」とか

「このひとか~~  まあいいか」っと 例えばベリサイン社が
判断して、「確かにAさんですよ」と教えてくれています。

IPA 暗号化とデジタル署名のためのインフラ技術

マイクロソフト、Apple, Google,  Mozillaは、
何千という認証機関で  たしかにA さんですという情報をもって
https確認や  作成者本人の作品やデータですという表現をしているのです。
(ちなみに、けっして、そのサイトが良さげで、誠実なサイトであると言ってるわけではなく
   お金もらってたしかにAさんという電子上の人と一致してますというだけです)

データ形式の相性

  • ツリー構造なので、管理型組織階層と相性がいいです。
  • ツリー構造なので、配下の修正が上部に伝播しないため、地域性、スケーラビリティ、部署の変更に対して、大きな影響はありません。
  • フラットではなく複雑な分、最初の構築、機能にコストがかかります。
    データの作成にもコストがちょっとかかります。
  • 地域とか、複数部署にまたがるようなデータは混乱します(ldap範囲外)
  • ldapのデータをどう管理するか、どう使うかという部分は残ったままです。

設計するとき、使うとき抑えておきたいポイント

  • 何に使うか、業務に合わせた各ステップフローはあるか、
  • その時の階層の管理構成は何か
  • DNのフォーマットは何か
  • 何が取れるか、保存している情報は何か
  • 他のサイトとの連携や、情報の隔離はどうすればいいのか

あたりを(抽象的ですが)観点として

抑えておけばいいかと思います。

先例:有名どころ

先ほど言ったように 
ひとつは電子証明書のCA認証機関に出すときです。
テスト中はオレオレ証明書でやります。
lenovoの thinkpadシリーズじゃないほうは、オレオレ証明書発行してました。
トラックパッド使いやすいのに。。。

OpenLDAP も 2010年にちらっと不具合がありましたが、一番信頼のおける製品です。

大企業や行政の 裏で動いているシステムも LDAPという似たようなシステムで動いているかもしれません。

社内認証は Active Directoryという認証システムをセットで導入するのもいいかと思います。

まとめ

ldap は DNという 階層構造の識別子で  エントリポイントを指し、
データとかとってきて、それであとはこっちでなんかするためのやーつです。

参考サイト

Delicious にシェア
Digg にシェア
reddit にシェア
LinkedIn にシェア
LINEで送る
email this
Pocket

98 views.



コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です