Zobrazení zdroje stránky LDAP

'''LDAP''' (''Lightweight Directory Access Protocol'') je definovaný [[protokol (informatika)|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ě [[Referenční model ISO/OSI|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 ==
{{Vyjmout|Adresářová služba}}
{{podrobně|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í databáze|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. Mohou 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 <kbd>uid</kbd>, pro heslo k uživatelskému účtu zase <kbd>userPassword</kbd>). 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|(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 <kbd>person</kbd> ve schématu (např. v serveru [[OpenLDAP]] je tato třída součástí základního schématu <kbd>core.schema</kbd>).

 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 <kbd>SUP</kbd>. 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 <kbd>sn</kbd> (nebo <kbd>surname</kbd>) odvozen od atributu <kbd>name</kbd>.

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 <kbd>etc/schema</kbd>.

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 (<kbd>givenName=Jana</kbd>), 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 <kbd>mail</kbd>) nebo uživatelské jméno pro vstup do nějakého systému (atribut <kbd>uid</kbd>).

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: <kbd>dc=abc, dc=cz</kbd> (<kbd>dc</kbd> je povinným atributem objektové třídy <kbd>dcObject</kbd>, 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: <kbd>uid=jana.jiraskova, dc=abc, dc=cz</kbd>. Zatímco pro stejného zaměstnance platí relativní rozlišovací jméno <kbd>uid=jana.jiraskova</kbd>.

== 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 <kbd>bind</kbd> a <kbd>unbind</kbd>. 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í (<kbd>search</kbd>), přidávání (<kbd>add</kbd>), mazání (<kbd>delete</kbd>), porovnávání (<kbd>compare</kbd>) a modifikace (<kbd>modify</kbd>) 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ů <kbd>ldapadd.exe</kbd> pro přidávání, <kbd>ldapmodify.exe</kbd> 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 <kbd>bind</kbd> nejsou serveru předávány žádné informace nesoucí identitu či heslo uživatele.
# ''Jednoduchá autentizace –'' pomocí <kbd>DN</kbd> a hesla (atributu <kbd>userpassword</kbd>). 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 <kbd>bind</kbd>.
# ''[[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 <kbd>compare</kbd> porovnat platnost zadaných údajů.
# ''[[PKI]] autentizace –'' založená na principu PKI [[digitální certifikát|digitálních certifikátů]], které jsou uloženy v definovaném atributu <kbd>userCertificate</kbd>. 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 (<kbd>userPassword</kbd>) 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 <kbd>slappasswd.exe</kbd>, který podporuje jako výchozí algoritmus <kbd>SSHA</kbd>, 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 <kbd>read</kbd> na atributy ostatních uživatelů, mimo atributu <kbd>userPassword</kbd> ostatních uživatelů, na které nemá právo ani <kbd>read</kbd> (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 <kbd>read</kbd>, <kbd>write</kbd> a <kbd>none</kbd> existují další. Např. právo <kbd>compare</kbd> umožňuje znát výsledek porovnávací operace, aniž by uživatel musel mít právo dané atributy číst.

== Odkazy ==
=== Reference ===
<references />

=== Literatura ===
* THOMAS, M.T.: Zabezpečení počítačových sítí bez předchozích znalostí. CP Books. 1. vyd. Brno 2005.
* MATHEW N., STONES R.: Linux Programujeme profesionálně. CP Books. 1. vyd. Brno 2003.
* BOLLINGER G., NATARAJAN B.: JSP Java Server Pages – podrobný průvodce začínajícího tvůrce. Grada Publishing. 1. vyd. Praha 2003.

=== Související články ===
* [[LDAP Data Interchange Format]], LDIF
* [[OpenLDAP]]
* [[Active Directory]]

=== Externí odkazy ===
==== v češtině ====
* [http://ldap.smejdil.cz/ MALÝ L.: LDAP v praxi s MUA]
* [http://ldap.zdenda.com/ BURDA Z.: Využití LDAPu v praxi]
* [http://www.root.cz/clanky/lehky-uvod-do-ldap/ ZAPLETAL, L.: Lehký úvod do LDAP ]
* [http://www.cesnet.cz/doc/techzpravy/2000-4/ SITERA, J.: Adresářové služby - úvod do problematiky] {{Wayback|url=http://www.cesnet.cz/doc/techzpravy/2000-4/ |date=20070609133149 }}
* [http://ldap.benak.net/diplom.pdf BENÁK, K.: Použití adresářových služeb v informačních systémech ]
* [http://www.samuraj-cz.com/serie/ldap-a-active-directory/ BOUŠKA, P.: Seriál LDAP a Active Directory]

=== LDAP implementace ===
* [http://www.openldap.org/ OpenLDAP]
* [http://directory.apache.org Apache Directory Server]
* [https://web.archive.org/web/20100316095928/http://www.directory.fedora.redhat.com/ Fedora Directory Server]
* [https://web.archive.org/web/20061205223837/http://www.redhat.com/software/rha/directory/ Red Hat Directory Server]
* [http://www.novell.com/products/edirectory/ Novell eDirectory]
* [http://www.sun.com/dsee Sun Directory Server Enterprise Edition] {{Wayback|url=http://www.sun.com/dsee |date=20100803052453 }}
* [https://web.archive.org/web/20070527032727/http://www-142.ibm.com/software/sw-lotus/domino IBM Lotus Domino]
* [http://www.microsoft.com/windowsserver2003/technologies/directory/activedirectory/default.mspx Windows Server 2003 Active Directory]
* [http://www.oracle.com/technetwork/middleware/id-mgmt/overview/index-082035.html?ssSourceSiteId=ocomen Oracle Internet Directory]
* [http://www.fefe.de/tinyldap/ tinyldap]
{{Autoritní data}}
{{Portály|Internet}}

[[Kategorie:Aplikační protokoly IP]]
[[Kategorie:Adresářové služby]]