LDAP

LDAP (Lightweight Directory Access Protocol) je definovaný protokol pro ukládání a přístup k datům na adresářovém serveru. Podle tohoto protokolu jsou jednotlivé položky na serveru ukládány formou záznamů a uspořádány do stromové struktury (jako ve skutečné adresářové architektuře). Je vhodný pro udržování adresářů a práci s informacemi o uživatelích (např. pro vyhledávání adres konkrétních uživatelů v příslušných adresářích, resp. databázích). Protokol LDAP je založen na doporučení X.500, které bylo vyvinuto ve světě ISO/OSI, ale do praxe se ne zcela prosadilo, zejména pro svou „velikost“ a následnou „těžkopádnost“.

Protokol LDAP již ve svém názvu zdůrazňuje fakt, že je „odlehčenou“ (lightweight) verzí, odvozenou od X.500 (X.500 - Mezinárodní standard, vyvinutý spolkem International Consultative Commitee of Telephony and Telegraphy, pro formátování elektronických zpráv přenášených přes sítě nebo mezi počítačovými sítěmi).

Aplikace funguje na bázi klient-server. V komunikaci využívá jak synchronní tak asynchronní mód. Součástí LDAP je autentizace klienta. Při provádění požadavku lze nedokončený požadavek zrušit příkazem abandon.

Adresářový server
Související informace naleznete také v článku Adresářová služba.
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í.

Informační model
Ú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.
Jmenný model
Ú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
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ů.
Bezpečnostní model
Úkolem bezpečnostního modelu je zabránit přístupu neoprávněné osoby k informacím v adresáři.

Autentizace
Úkolem autentizace je ověření identity uživatele, který se snaží o spojení s adresářovým serverem. Uživatel může být autentizován několika způsoby.

Anonymní autentizace – v rámci operace bind nejsou serveru předávány žádné informace nesoucí identitu či heslo uživatele.
Jednoduchá autentizace – pomocí DN a hesla (atributu userpassword). Tuto autentizaci je možno provádět i na bezpečném kanále TLS/SSL. V tomto případě nejprve dojde k výměně certifikátů obou stran (serveru i klienta). Teprve po ověření těchto certifikátů dojde k otevření spojení a vyvolání operace bind.
Proxy autentizace – využívá existence definovaného uživatele, který má právo nahlížet na hesla ostatních uživatelů. Autentizace požadovaného uživatele tedy probíhá přes tento mezičlánek, který může například pomocí operace compare porovnat platnost zadaných údajů.
PKI autentizace – založená na principu PKI digitálních certifikátů, které jsou uloženy v definovaném atributu userCertificate. Při pokusu o autentizaci je uživatel požádán o zadání svého hesla a autentizován je po srovnání digitálních certifikátů na straně klienta a serveru. Tento druh autentizace je obtížný jak pro uživatele, tak pro administrátory serveru, protože obě strany musí své certifikáty v případě potřeby aktualizovat.
SASL mechanizmus – disponuje množstvím zásuvných modulů, které můžeme využít pro autentizaci uživatele.
V adresářovém serveru proběhne autentizace úspěšně v případě, že dané uživatelské jméno bude připadat nějakému existujícímu záznamu. A rozlišovací jméno tohoto záznamu obsahuje atribut s heslem (userPassword) se stejnou, jako zadanou, hodnotou.

Podobným způsobem probíhá i autentizace správce celého adresáře, jehož rozlišovací jméno definujeme v konfiguračním souboru implementace adresářového serveru (např. OpenLDAP). Jen s tím rozdílem, že danému uživateli přísluší heslo, které není uchováno v adresáři, ale ve zmíněném konfiguračním souboru.

To sebou přináší i nutná bezpečnostní opatření. Jelikož hesla jsou velmi citlivá a nepřejeme si jejich zveřejnění, můžeme v adresářovém serveru využívat možností jejich ukládání v šifrované podobě (podle dostupných šifrovacích algoritmů). Implementace adresářových serverů nejednou obsahují programy pro šifrování hesel (např. v OpenLDAP můžeme využít programu slappasswd.exe, který podporuje jako výchozí algoritmus SSHA, můžeme jej však atributem programu změnit). Veškerá hesla je tedy doporučeno ukládat v šifrované podobě – jak atributy userPassword, tak i heslo správce adresáře v konfiguračním souboru.

K některým operacím není nutné být autentizován, záleží na nastavení přístupových práv, pak můžeme využít i anonymní autentizace.

Autorizace
Autorizace úzce souvisí s mechanizmem autentizace a nastupuje po jejím úspěšném ukončení. Jejím úkolem je zajistit, aby měl autentizovaný uživatel přístup pouze k datům a operacím, ke kterým je oprávněn. Tato problematika tedy úzce souvisí s nastavením přístupových práv k záznamům a atributům.

Přístupová práva můžeme nastavit až na úroveň jednotlivých atributů. Pokud se jedná o adresář, ve kterém ukládáme přístupové informace jednotlivých uživatelů, mohlo by se nám zdát vhodné toto nastavení: Uživatel má právo write na všechny své atributy, právo read na atributy ostatních uživatelů, mimo atributu userPassword ostatních uživatelů, na které nemá právo ani read (nemá právo si ho tedy vůbec prohlížet). Nastavení pak může v konfiguračním souboru serveru OpenLDAP vypadat následovně:

access to *
by self write
by * read
access to attr = userPassword
by self write
by * none
Nastavení přístupových práv jsou velmi mocná. Mimo zmíněných práv read, write a none existují další. Např. právo compare umožňuje znát výsledek porovnávací operace, aniž by uživatel musel mít právo dané atributy číst.