LDAP

Adresářový server umožňuje uchovávat různé typy dat. Je ale optimalizován pro data, která nevyžadují příliš časté aktualizace. Na rozdíl od relačních databází také adresářový server nepodporuje složité transakce a kontrolu referenční integrity. Tuto starost musíme v případě potřeby naprogramovat v samotné aplikaci.

Můžeme tedy říci, že je vhodným místem pro ukládání specifických informací - a to ve standardizované formě. Z přívlastku „standardizovaná“ vyplývá, že nasazení adresáře je výhodné, když uchovávaná data zapadají do definovaného standardu. Můžou jimi být třeba informace o společnostech, zaměstnancích, uživatelských účtech atd. Právě pro tyto typy dat má adresářový server předdefinována schémata (=seskupení definic tříd a atributů. Každý záznam pak musí být instancí jedné ze tříd). To vyplývá především z poptávky, adresářové služby bývají nejčastěji využívány k centralizaci dat (uživatelských, zaměstnaneckých atd.), a proto jsou pro tyto účely dostupná i schémata.

Pokud jsou totiž data ukládána způsobem definovaným pevnou specifikací, nic nebrání jejich obecnému využití ve vícero aplikacích. Ačkoli vývojáři netuší nic o konkrétní struktuře, znají alespoň nutnou „obálku“, ve které musí být data uložena. Opírají se o předdefinovaná jména atributů a mohou tak předpokládat, že v hodnotě určitého atributu je zastoupena očekávaná hodnota (např. pro uživatelské jméno je rezervován atribut uid, pro heslo k uživatelskému účtu zase userPassword). Adresářový server umožňuje spravovat informace centrálně, odděleně od konkrétní aplikace. Spojením těchto dvou vlastností (oddělená správa a specifikací určená forma) je jednoduše možné docílit toho, že k různým aplikacím přistupujeme pod stejnými uživatelskými údaji.

Tvorba vlastních schémat a objektových tříd bývá umožněna, je nutné ji ale využívat s rozmyslem. Při implementaci samotné aplikace byste totiž museli požadovat i integraci Vašeho schématu do adresářového serveru zákazníka. Snižuje se tedy výhoda snadné integrace aplikace do existujícího IT prostředí zákazníka, kterou technologie adresářových služeb nabízí.

Úkolem informačního modelu LDAP je definovat datové typy a informace, které lze v adresářovém serveru ukládat. Data jsou uchovávána ve stromové struktuře pomocí záznamů. Pod pojmem záznam si můžeme představit souhrn atributů (dvojice jméno - hodnota). Atributy nesou informaci o stavu daného záznamu. Záznamy, uložené v adresáři, musí odpovídat přípustnému schématu. Pod pojmem schéma si představme soubor povolených objektových tříd a k nim náležících atributů. Z faktu, že každý záznam je instancí objektové třídy, vyplývá, že musí obsahovat všechny atributy vedené u dané objektové třídy jako povinné. Mimo to může obsahovat i atributy nepovinné, nicméně opět musí vybírat pouze z množiny příslušící dané objektové třídě. Viz příklad konkrétní definice objektové třídy, např. třídy person ve schématu (např. v serveru OpenLDAP je tato třída součástí základního schématu core.schema).

objectclass (2.5.6.6 NAME 'person'
	DESC 'RFC2256: a person'
	SUP top STRUCTURAL
	MUST (sn $ cn)
	MAY (userPassword$telephoneNumber$seeAlso$description))

Vidíme, že každá objektová třída je v počátku své definice jednoznačně určena svým ID a jménem. V informačním modelu je definována i dědičnost objektových tříd pomocí definice následující za klíčovým slovem SUP. Můžeme tak snadno určit, na které objektové třídě je definovaná třída založena. Následují pak definice povinných a nepovinných atributů.

I atributy musí být definovány v souboru schématu.

attributetype (2.5.4.4 NAME ('sn' 'surname')
	DESC 'RFC2256: last (family) name(s) for which the entity is known by'
	SUP name)

Výše uvedený příklad ukazuje definici atributu pro příjmení. I atribut musí být definovaný jednoznačným ID. A i atribut může být podle zákonů dědičnosti odvozen od svého předchůdce. V tomto případě je atribut sn (nebo surname) odvozen od atributu name.

Podrobnější informace o definování objektových tříd a atributů je možno hledat v literatuře či definici samotných schémat – např. v serveru OpenLDAP se jedná o soubory v adresáři etc/schema.

Je nutné připojit konstatování, že záznam nemusí být instancí pouze jedné objektové třídy. Ty jsou ve schématu uspořádány hierarchicky. A mohou být trojice různých druhů, od kterých se pak odvíjí možnost jejich využití a kombinace v definici záznamu.

• Abstract – samy nemohou být vzorem pro tvorbu záznamu. Slouží pouze jako předloha pro odvození dalších tříd.

• Structural – třídy odvozené. Právě ony slouží jako hlavní předloha pro tvorbu záznamu. Každý záznam musí ve své definici obsahovat odkaz alespoň na jednu ze strukturálních tříd. Může se dokonce odvolávat na více než jednu, ale v tomto případě musí být třídy v dědičném vztahu (např. osoba - zaměstnanec). Nelze vytvářet záznam na základě strukturálních tříd ze dvou větví (zaměstnanec - místnost).

• Auxiliary – třídy doplňkové. Takové třídy můžeme v libovolném počtu připojovat k definici záznamu. Rozšiřují počet přípustných atributů u daného záznamu.

Úkolem jmenného modelu LDAP je definovat, jakým způsobem budou data v adresáři organizována a jak je možné se na ně odkazovat.

Každý záznam musí být jednoznačně identifikovatelný pomocí svého rozlišovacího jména (DN = Distinguished Name) v rámci celého stromu serveru. Musí být také jednoznačný pomocí relativního rozlišovacího jména (RDN = Relative Distinguished Name) v rámci jedné úrovně větve v adresáři. RDN se skládá ze jména a hodnoty identifikujícího atributu. Není vhodné za RDN považovat např. atribut pro křestní jméno s hodnotou Jana (givenName=Jana), protože nositelů tohoto jména může být na dané úrovni více. Vhodněji vybraným atributem může být např. emailová adresa (atribut mail) nebo uživatelské jméno pro vstup do nějakého systému (atribut uid).

K záznamům přistupujeme pomocí cesty. Cesta je synonymem pro výše zmíněné rozlišovací jméno DN. Rozlišovací jméno je závislé na zvoleném sufixu a na poloze záznamu v adresářovém stromu. Sufix je část rozlišovacího jména, která je společná všem záznamům, často bývá odvozena od lokality, nebo od internetové domény. To proto, aby zaručila danému adresáři jedinečnost (i v rámci celého světa). Např. sufix patřící firmě ABC by mohl mít následující podobu: dc=abc, dc=cz (dc je povinným atributem objektové třídy dcObject, zastupující komponenty internetové domény). Sufix je ale pouze jednou z částí, pomocí které identifikujeme záznam v rámci adresáře. A zatímco ten je pro každý záznam v adresáři shodný, další část rozlišovacího jména se musí pro každý záznam lišit. Při tvorbě rozlišovacího jména postupujeme „zdola nahoru“, na rozdíl od tvorby cest v klasickém adresářové struktuře, kde postupujeme od kořene „shora dolů“. Rozlišovací jméno poskládáme z relativních rozlišovacích jmen předchůdců daného záznamu.

Rozlišovací jméno zaměstnance z adresářového serveru firmy ABC může mít následující podobu: uid=jana.jiraskova, dc=abc, dc=cz. Zatímco pro stejného zaměstnance platí relativní rozlišovací jméno uid=jana.jiraskova.

Funkční model umožňuje pomocí základních operací manipulovat a přistupovat k záznamům v adresáři a měnit či zjišťovat tak jejich stav.

• Autentizační operace: Slouží k přihlášení a odhlášení uživatele pro komunikaci s adresářovým serverem. Jsou jimi míněny především operace bind a unbind. Na úspěšném provedení operace bind závisí výsledky aktualizačních a dotazovacích operací nad adresářem.
• Aktualizační a dotazovací operace: Každý adresářový server podporuje základní operace s daty, jako je vyhledávání (search), přidávání (add), mazání (delete), porovnávání (compare) a modifikace (modify) záznamů. Tyto operace bývají často spjaté s nastavením bezpečnostního modelu. Opět je můžeme provádět buď přímo pomocí pomocných programů, které bývají součástí jednotlivých implementací adresářového serveru (např. server OpenLDAP umožňuje využít přímo programů ldapadd.exe pro přidávání, ldapmodify.exe pro modifikaci atd.), nebo pomocí knihoven jednotlivých programovacích jazyků.

Úkolem bezpečnostního modelu je zabránit přístupu neoprávněné osoby k informacím v adresáři.

access to *
	by self write
	by * read
access to attr = userPassword
	by self write
	by * none