OpenLDAP

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í).

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.

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ů.

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)

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í)

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.