OpenLDAP Software je v informatice název volně šiřitelné implementace protokolu LDAP (Lightweight Directory Access Protocol). OpenLDAP je uvolněn pod svojí vlastní BSD licencí nazývanou OpenLDAP public Licence. LDAP je protokol nezávislý na platformě. Několik linuxových distribucí obsahuje OpenLDAP, ale najdeme ho též na BSD systémech stejně tak jako na systémech AIX, Android, HP-UX, Mac OS X, Solaris, Windows NT (Windows 2000, XP, Vista, 7 atd) .
Historie projektu a jádro týmu OpenLDAP projekt byl založen v roce 1998 Kurtem Zeilengaem. Projekt začal kopírováním referenčního zdrojového kódu LDAP z University of Michigan, kde probíhal dlouhodobý projekt vývoje podpory protokolu LDAP. V dubnu 2006 měl OpenLDAP projekt tři základní členy: Howard Chu (hlavní vývojář), Pierangelo Masarati, Kurt Zeilenga a bezpočet dalších důležitých a aktivních přispěvatelů např. Luke Howard, Hallvard Furuseth, Quanah Gibson-Mount a Gavin Henry.
Komponenty OpenLDAP softwaru OpenLDAP má tři hlavní komponenty:
slapd – samostatný LDAP démon a přidružené moduly a nástroje knihovny implementující LDAP protokol a ASN.1, BER (Basic Encoding Rules) softvérové klienty: ldapsearch, ldapadd, ldapdelete, a další
Navíc OpenLDAP projekt obsahuje několik podprojektů: JLDAP – LDAP knihovní třídy pro Javu JDBC-LDAP – Java JDBC – LDAP Bridge drivers Idapc++ – LDAP knihovní třídy pro C++ Fortress – RBAC (role-based access control) MDB – Memory-mapped databázové knihovny
Backendy
Souhrnný koncept Struktura OpenLDAP serveru (slapd, samostatný LDAP démon) se rozdělila na dvě části. První částí je frontend, který zajišťuje přístup na síť a rozumí protokolu LDAP. Druhý je backend který se stará pouze o datové úložiště. Struktura je modulární a je dostupné velké množství různých backendů pro spolupráci s dalšími technologiemi, nejenom s tradičními databázemi.
Poznámka: Ve starších (1.X) verzích se pojem backend a databáze často zaměňovaly. Chceme-li být přesní, „backend“ je třída implementující rozhraní úložiště a „databáze“ je instancí této třídy. Slapd server může najednou používat libovolné množství backendů a libovolné množství instancí každého z těchto backendu (databází).
Dostupné backendy V současnosti existuje 16 různých backendů dodávaných s distribucí LDAP. Mnoho dalších backendů je vyvíjeno a spravováno třetími stranami. Standardní backendy jsou volně rozdělené do tří kategorií.
Data storage backends – starají se o ukládání dat: back-bdb: je to první backend pro OpenLDAP využívající transakce, vychází BerkeleyDB back-hdb: jedná se o variantu back-bdb, která má úplnou hierarchickou strukturu a podporuje přejmenování podstromů back-ldif: vychází čistě z textových LDIF souboru back-mdb: transakční backend využívající OpenLDAP's MDB memory-mapped database back-ndb: transakční backend využívající MySQL's NDB cluster engine
Proxy backends – chovají se jako brány k dalším uloženým systémům back-ldap: jednoduché proxy k dalším LDAP serverům back-meta: proxy s funkcí meta-adresářů back-passwd: používá unixový systém /etc/passwd a skupiny /etc/group back-relay: vnitřně přesměrované na další slapd backendy back-sql: spolupracuje s různými SQL databázemi
Dynamic backends – tyto backendy dynamicky generují data back-config: slapd konfigurace přes LDAP back-dnssrv: vyhledává LDAP servery pomocí DNS back-monitor: slapd statistiky pomocí LDAP back-null: podobné Unixovému /dev/null back-perl: vyvolá libovolné perlové moduly v reakci na protokolu LDAP back-shell: vyvolá shell skripty pro LDAP požadavky back-sock: přeposílá LDAP dotazy přes IPC různým daemonům
Některé backendy ze starších verzích se přestaly používat. Nejdůležitější z nich back-ldbm který vycházel z původního Umich kódu a back-tcl který byl podobný back-perl a back-shell. V praxi, backendy jako -perl -shell a -sock používají jako rozhraní k různým programovacím jazykům a tak poskytují neomezené možnosti přizpůsobení a rozšíření. V důsledku toho se slapd server stává RPC enginem s kompaktním a všudepřítomným API.
Překrývací moduly (Overlays)
Souhrnný koncept Z pravidla jsou LDAP požadavky přijaty frontendem, dekódovány a potom předány backendu ke zpracování. Když backend dokončí požadavek vrátí výsledek frontendu, který pak výsledek pošle na LDAP klienta. Překrývací modul je část kódu, který může být vložený mezi frontend a backend. Je schopný přerušit požadavek a spustit další akce ještě před tím, než backend obdrží požadavek, a podobně reaguje na výsledek backendu před tím než ho doručí frontendu. Překrývací moduly mají plný přístup k vnitřnímu API slapd a tak mohou vyvolat všechno co může provést frontend nebo backend. Najednou může být využito více překryvných modulů vytvářejících zásobník modulů mezi frontendem a backendem. Překrývací moduly poskytují jednoduchý způsob jak rozšířit funkcionalitu databáze bez nutnosti vytvořit úplně nový backend a umožňují přidat novou funkcionalitu v kompaktním, snadno odladitelném a udržovatelném modulu. Od představení překrývacích modulů v OpenLDAP 2.2 bylo vytvořeno velké množství nových OpenLDAP modulů.
Dostupné překrývací moduly V současnosti je 21 překryvných modulů v hlavní OpenLDAP distribuci a další 15 modulů vytvořených uživateli OpenLDAP. Hlavní překryvné moduly obsahují:
accesslog: logování v další LDAP databázi auditlog: logování do souboru (prostý text) chain: přeruší odkazy a místo toho je zřetězí, je součástí back-ldap collect: implementuje X-500 sdílené atributy (Netscape Class of service) constraint: omezují přístupné hodnoty pro konkrétní atributy dds: dynamic data service – krátkotrvající nebo časově omezené záznamy deref: vrací informace o záznamech odkazující na výsledek hledání dyngroup: podpora pro jednoduché dynamické skupiny dynlist: sofistikovanější podpora pro dynamické skupiny a další funkce memberof: podpora pro funkci memberOf a podobné atributy pcache: vytváří cache pro výsledky vyhledávaní, hlavně vylepšuje výkon proxy serveru refint: referenční integrita ppolicy: LDAP Password Policy – kvalita a platnost hesla atd. Retcode: sada předem určených návratových kódů, používá se pro odladění klienta rwm: přepisující modul, umožňující změny dat v LDAP seqmod: realizuje zápis do individuálních vstupů sssvlv: třídění a virtuální Listview na straně serveru syncprov: Syncrepl Provider, implementuje hlavní část ujednání o replikacích translucent: polotransparentní, průchozí, slouží pro lokální rozšíření dat na proxy serveru unique: pro vynucení unikátnosti hodnot atributu uvnitř stromu valsort: stará se seřazení atributů a hodnot podle klíče Překryvné moduly vytvořené uživateli: addpartial: přijme požadavek a změní ho na modify jestli už cílený prvek již existuje allop: vrátí všechny funkční atributy, pro klienty kteří neví jak se na ně dotázat autogroup: dynamicky spravované statické skupiny cloak: skrývá atributy pokud nejsou explicitně vyžádány vyhledáváním denyop: umožňuje zamítnout některé dotazy dupent: vrací více hodnotové výsledky jako oddělené záznamy lastbind: zaznamenává časový záznam poslední uživatelovy úspěšné autentizace lastmod: spravuje poslední provedené změny ve stromu nops: odfiltruje redundantní změny noopsrch: spočítá záznamy které budou vráceny vyhledáváním nssov: vrací odpovědi na NSS a PAM dotazy přímo v slapd nahrazuje nss-ldap a pam-ldap proxyOld: podporuje staré kódování ProxyAuthz používané společností Sun smbk5pwd: spravuje Samba a Kreberos hesla trace: Loguje LDAP požadavek a odpověď usn: aktualizuje sekvenci čísel (pro Microsoft AD ještě nevydáno)
Další moduly Backendy a překryvné moduly jsou dva nejběžněji využívané typy modulů. Backedy jsou většinou vestavěné do binárních souborů slapd, ale mohou být sestaveny jako dynamicky načítané moduly. Překryvné moduly jsou obvykle sestaveny jako dynamicky zaváděný moduly. Navíc slapd podporuje dynamické moduly pro implementaci nové LDAP syntaxe, porovnávacích pravidel a rozšířené operace stejně tak moduly pro implementaci vlastních mechanismů řízení přístupu a hašování hesel.
OpenLDAP také podporuje SLAPI, je to plugin používaný společnostmi SUN a Netscape/Fedora/Red Hat. V současné verzi je SLAPI framework implementovaný uvnitř překryvného modulu slapd. Zatím co mnoho pluginů napsaných pro SUN a Netscape/Fedora/Red Hat jsou kompatibilní s OpenLDAP, velmi málo členů OpenLDAP komunity používá SLAPI.
Replikace OpenLDAP podporuje replikaci za použití Content Synchronization jak to bylo specifikováno v RFC 4533. Tato specifikace je také nazývána „syncrepl“. Základní aplikace navíc podporuje doplněk známý jako delta-syncrepl. Tento doplněk byl implementovány, aby podporoval multi-master replikaci.
Syncrepl Základní synchronizační operace je popsána v RFC 4533. Protokol je definován tak, že nevyžaduje trvalou databázi změn. Soubor změn je zaznamenán skrze změnu sekvenčního čísla (change sequence number – CSN), informaci uloženou v každém vstupu, optimalizovanou skrze volitelnou přihlašovací relaci (session log), což je zvláště užitečné pro dohledání nedávných smazání. Modelová operace vypadá tak, že replikační klient (uživatel) odešle "content synchronizing search" (synchronizující vyhledávání obsahu) replikačnímu serveru (poskytovateli). Uživatel může v tomto vyhledávání poskytnout cookie (obzvláště pokud byla dříve v synchronizaci s poskytovatelem). V OpenLDAP za implementace RFC 4533 tato cookie zahrnuje poslední CSN, které byly přijaty od poskytovatele (nazývající se contextCSN)
Poskytovatel pak vrací výsledky vyhledávání jako (viz optimalizace níže, synchronizované info reakce) současné (nezměněné záznamy se používají pouze v prezentační fázi obnovovací fáze, bez atributů), přidaně modifikované (reprezentované v obnovovací fázi jako přidané se všemi současnými atributy), nebo odstraněné záznamy (bez atributů), aby uživatele dostaly do synchronizovaného stavu na základě toho, co je známo přes jeho cookie. Pokud cookie chybí, nebo indikuje, že uživatel není synchronizován, potom poskytovatel v obnovovací fázi odešle doplněk pro každý vstup. V ideálním případě obnovovací fáze odpovědi obsahuje pouze odstraňovací (delete) fázi s malou sadou doplňků (včetně těch, které představují aktuální výsledky změn) a odstranění, která proběhla od poslední synchronizace s poskytovatelem. Nicméně, vzhledem k omezenému stavu relace (není trvalá) udržovanému u poskytovatele může být vyžadována prezentační fáze zahrnující zejména všechny nezměněné záznamy jako prostředek (neefektivní) sloužící k implikování toho, co bylo smazáno u poskytovatele od poslední synchronizace.
Vyhledávání lze provést buď pomocí obnovení (refresh), nebo pomocí refreshAndPersist mode, který určí, jaké fáze nastanou. Obnovovací fáze nastane vždy jako první. Během obnovovací fáze mohou nastat dvě fáze: Prezenční a odstraňovací (present and delete) kdy prezenční nastane vždy před odstraňovací. Tyto fáze jsou vymezeny skrze synchronizovanou info reakci. Ta specifikuje, která fáze je dokončena. Refresh a persist etapy jsou taktéž vymezeny prostřednictvím synchronizované info reakce. Volitelná optimalizace, jež více kompaktně představuje skupinu záznamů, které mají být prezentovány nebo smazány používá synchronizovanou info reakci obsahující syncIdSet, který definuje seznam entryUUID hodnot těch vstupů.
Prezenční fáze se od odstraňovací fáze liší následovně. Záznamy prezentující nezměněné záznamy mohou být navráceny pouze v prezenční fázi. Záznamy, jež mažou záznamy, mohou být poskytnuty pouze v odstraňovací fázi. V obou fázích mohou být vráceny přidané záznamy (zahrnující doplňky, které reprezentují všechny současné atributy změněných záznamů). Na konci prezentační fáze není každý záznam, který uživatel má a který nebyl definován v žádném dodatečném záznamu nebo v present response během prezentační fáze, obsažen u poskytovatele a tak musí být u uživatele smazán, aby se uživatel mohl synchronizovat s poskytovatelem.