 |
|
LDAP bevezető, elmélet
LDAP vs. SQL
A bevezetőben megfogalmazott célokat egy SQL adatbázissal is meg lehet valósítani, így felmerülhet a kérdés miért jobb mégis LDAP-al csinálni. Az alábbiakban felvillantok néhányat a lehetséges okok közül, amik nem jelentenek perdöntő érveket, de a rendszertervezésnél figyelembe veendőek:
- LDAP keresésre optimalizált: míg az SQL adatbázisok általános célú felhasználásra, addig az LDAP szerverek elsősorban ritkán változó adatok keresésére optimalizáltak. Az felhasználói azonosítás, személyek és eszközök nyilvántartása stb. mind a saját életciklusukon belül ritkán változó adatokat szolgáltatnak. A legtöbb feladat pedig az ilyen adatbázisokon való kifinomult kereséssel oldható meg.
- LDAP kifinomultabb azonosítási és hozzáférés szabályozási mechanizmussal rendelkezik: maga az X.500-as szabvány is, de az LDAP protokoll maga is tartalmazza az un. bindig mechanizmust, aminek segítségével akár minden DIT-beli azonosíthatja magát mielőtt bármilyen műveletet végezne az adatbázison. Ez a bindig mechanizmus ráadásul lehetővé teszi, hogy az azonosítást úgy végezzük el, hogy az adatbázisból a azonosítási token (pl.: jelszó) nem kerül ki soha. Mindehhez az LDAP szerverek többsége kifinomult hozzáférés szabályozási mechanizmust is tartalmaz, aminek a segítségével akár minden egyes LDAP bejegyzésről megadhatjuk, hogy kik milyen műveletekre férhetnek hozzá vagy akár azt is, hogy az adott attribútumnak milyen értéket adhatnak csak.
Ezzel szemben általában a SQL alapú azonosítási mechanizmusok közönséges adatbázisban tárolják a jelszavakat (akar kódolva, akár kódolatlanul), az SQL kliens ezt a jelszót egy SQL lekérdezéssel kiolvashatja és összehasonlítja a felhasználó által megadottal. Maga az SQL kliensnek olyan adatbázis felhasználóként kell a szerverhez kapcsolódnia, aki minden felhasználó adatához is hozzáfér.
- LDAP alapvetően elosztott információs modellel rendelkezik: míg egy SQL szerver esetén az elosztott működés meglehetősen bonyolultan valósítható meg, addig a DIT alapvetően könnyen elosztható és ezt az elosztottságot a legegyszerűbb LDAP szerverek is támogatják. Ezen túlmenően az LDAP szerverek legalább master-slave jellegű, de nem ritkán muti-master, replikációs mechanizmussal rendelkeznek, amihez ráadásul nem szükséges közös elosztott állományrendszer sem.
Néhány esetben, például amikor már van egy SQL adatbázisunk felhasználói adatokkal, értelmes lehet a két módszert kombinálni, azaz LDAP protokollon keresztül elérhetővé tenni az SQL adatbázis adatait azonosítási célból.
Attribútum: igen
LDAP osztály: van neve, vannak kötelező és nem kötelező attribútumai, van OID-je. Az osztály egy konkrét példányának van DN-je.
Öröklődés: A leírtak nem az öröklődéssel, hanem a DIT szerkezetéből adódnak, semmi köze az öröklődéshez. Az öröklődés az osztályokra vonatkozik, azaz, ha People osztály kötelező attribútuma a CommonName és az PhoneNumber akkor, ha van egy OrganizationalPeople nevű osztály, ami a People osztálytól öröklődik, akkor annak is ezek kötelező attribútumai lesznek, de lehet ennek neki további kötelező attribútuma is. A DIT egy eleme, pedig az osztályok közül egy vagy többet valósít meg.
Az attribútumok leírása kicsit tömör. Remélem, a következőre gondolsz:
Egy attribútum:
suly=89
Az attribútum neve suly, típusa valós szám, értéke 89.
Egyenlők, ha a különbségük egynél kisebb
Ez stimmt?
Egy LDAP osztály:
- áll sok attribútumból
- meg egy azonosítóból, ami a fa hozzá vezető csomópontjainak jegyzéke, aka DN.
Az egyszerű öröklődés:
Ha az N-edik szinten a fában van egy allat nevű osztály, aminek a DN-je legyen mondjuk
planet=earth,category=living_things,kingdom=animals
Ez egy csomópontot definiál, ahol több ilyen információ is lehet, például van planet=earth,category=living_things,kingdom=plants is.
A category egy csomópont a fában (DIT), és ebben a cosmópontban van több adat, mint pl. a living_things, rocks, sky, ghosts?
A kingdom egy másik csomópont, amiben van mondjuk a plants meg az animals, mint adat?