From Wikipedia, the free encyclopedia
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 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. 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 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.
Ú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.
Úkolem bezpečnostního modelu je zabránit přístupu neoprávněné osoby k informacím v adresáři.
Ú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.
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 ú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.
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.