OpenLDAP

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.

Jakmile začne persist etapa, poskytovatel odešle výsledky hledání, které označí doplňky, modifikace a smazání záznamů (nezměněné údaje označeny nebudou) provedená od ukončení refresh fáze. Persist etapa trvá neurčitou dobu, což znamená, že hledání nemá finální „done“ odpověď. Naopak v refresh režimu nastane pouze refresh fáze a ta je ukončena „done“ reakcí, což zároveň ukončí prezentační nebo odstraňovací fázi (podle toho, která zrovna byla aktivní)

delta-syncrepl

Tento protokol vede trvalou databázi zapsaných přístupů (změn) a může představovat jednotlivé změny přesně (to znamená, pouze atributy, které se změnily). Je stále postaven na standardní syncrepl specifikaci, která vždy posílá změny jako kompletní záznamy. Ale v delta-syncrepl jsou přenášené záznamy zasílány z log databáze, kde je každá změna v hlavní databázi zapsána jako log záznam. Log záznamy jsou zaznamenávány pomocí LDAP Log Schema.