Dnešní společnosti stále více vnímají požadavky na přístup ke sdíleným zdrojům z řad vlastních zaměstnanců, zákazníků a obchodních partnerů mimo jejich tradiční hranice. Potřeba umožnit přístup uživatelům z několika různých stran se stává stále více potřebná, stejně jako jednotlivé vize užití a realizace. Důležitým aspektem však zůstává bezpečnost všech navržených přístupových prvků celého systému.

Enterprise IT postupně přesunuje zaměření z podnikové sféry na extranet a rozšíření ze stovek uživatelů na miliony a více. Aplikace, které zaměstnanci IT oddělení musí nasadit a zabezpečit, mají mnoho uživatelů, rolí, požadavků regulátorů a zdrojů, které musí obsluhovat a spravovat. S rostoucím počtem aplikací roste i riziko úniků dat, zejména s ohledem na data používaná mimo jednotlivé společnosti nebo citlivá data třetích stran.

Velkým úkolem pro podnik je vyvinout infrastrukturu, která centralizuje zabezpečení a má možnosti rozšíření, dalšího nasazení a posílení procesů, které dovolují vývojářům vytvářet aplikace bez obav o bezpečnost, poskytovat společnosti transparentnost a dodržování nařízení a doporučení, která jsou vyžadována. Všechny zmíněné prvky moderní IT architektury mají jedno společné: nutnost centralizovat a uchovávat uživatelské identity, které jsou důležitou komoditou v dnešním technickém světě.

Cílem této bakalářské práce je teoreticky popsat adresářové služby LDAP, často používaná řešení a řešení systémů pro správu uživatelských identit. Teoretický rozbor protokolu LDAP je obsahem první části této bakalářské práce. V další části je uvedeno řešení některých adresářových serverů, které jsou používané právě s ohledem na požadavky dnešních společností a regulátorů, kterými může být jak stát, tak i další organizace, popřípadě burzy. Pro porovnání bylo vybráno několik produktů, které jsou založeny jak na otevřených technologiích, tak i na technologiích uzavřených. Některé z uvedených produktů je možné používat volně nebo zakoupit podporu systému přímo od dodavatele řešení.

V návaznosti na popis adresářových serverů je součástí práce i popis řešení pro kompletní správu uživatelských identit a dalších objektů ukládaných v adresářových serverech. Souvisejícím problémem je vzájemné propojování služeb a interakce s dalšími službami a systémy, jako jsou operační systémy, aplikační servery a samotné aplikace. Dále je uveden popis služeb Single Sign-On a OpenID, s několika příklady integrace adresářových služeb s dalšími produkty. V závěru je provedeno vyhodnocení systémů zejména s ohledem na použitelnost v podnikovém prostředí.

Správa uživatelských identit

Identity management „IDM“ je infrastruktura a business procesy pro správu celého životního cyklu a následného využití, zahrnující definici prvků, ověřování a oprávnění. IDM pokrývá firemní procesy aplikované na všechny provozní operace v celé ICT infrastruktuře.

Identita v rámci IDM může být spojena s uživatelem, službou, zařízením nebo komunitou.

Vývoj a popis IDM

S rostoucím počtem uživatelských aplikací a potřebou definice přístupových pravidel a rolí pro různé uživatele a komunity bylo poukázáno na nutnost vytvoření systému pro řízení přístupů k síťovým zdrojům.

Typicky každý podnik využívá při vývoji a implementaci aplikací vlastní uživatelské a IDM rozhraní a vlastní schémata pro zabezpečení těchto aplikací. Tato metoda nasazení vede k vytvoření heterogenního systému bez centrální správy systémů a s tím související neexistence flexibility při dalším růstu a plnění pozdějších úkolů spojených s nasazováním nových aplikací či prostředí. Tento trend může například negovat výhody vývoje internetových aplikací a dostupnosti v rámci celé firemní infrastruktury včetně připojení k dalším subjektům. Následně dochází ke zvyšování nákladů na nasazení, administraci a údržbu takto řešených systémů. Další nevýhodou je zvýšené bezpečnostní riziko a prakticky zmražený další vývoj některých důležitých částí takto řešeného systému.

Informace o uživatelských identitách a bezpečnostních politikách jsou distribuovány přes velké množství aplikací a datová úložiště jsou dostupná a kontrolována různými interními i externími skupinami. Potřeba větší flexibility přístupů a silnějšího zabezpečení omezuje nadbytečnost administrativních úkonů a nekonzistentnost dat přes celou společnost včetně problematického nastavování ad-hoc bezpečnostních strategií.

Prostředí s různorodými zdroji identifikačních informací implementují rozdílné přístupy pro organizaci uživatelských entit, bezpečnostních praktik, řízení přístupů a dalších aspektů potřebných v informační architektuře.

Komplikovanost interního prostředí v rámci IDM může být dále rozšiřováno za hranice prostředí uvnitř jedné firmy. V tomto případě je architektura rozšiřována z individuální sféry na úroveň tzv. federativních modelů IDM – „FIDM“. Modely FIDM jsou užívány pro propojování a správu zdrojů a s tím související zajišťování efektivní a bezpečné spolupráce mezi dalšími subjekty, kterými mohou být zákazníci, obchodní partneři či dodavatelé. To vše s ohledem na soukromí, snadné využití spotřebiteli a musí splňovat požadavky na rozšiřitelnost a aplikační nenáročnost správy od jednotek až po tisíce až milióny entit.

V případě, že je nasazována nová aplikace bez použití společné infrastruktury IDM, bezpečnostní rozhodnutí a řízení je typicky ve správě týmu vývoje aplikací a systémových administrátorů. Přímo nadřízení manažeři nemohou zajistit, aby správní lidé viděli to, co přesně mají a ve správný čas.

Manažeři musí uplatnit bezpečnostní politiku centrálně a aplikovat ji lokálně. Bezpečnostní politiky definují, jak jsou uživatelé identifikováni, ověřeni a současně definují, kteří uživatelé mohou přistupovat k jakým zdrojům – autorizace. Některé služby nebo transakce potřebují jiné formy ověření nežli jiné. Pro některé aplikace může být dostačující použití uživatelského jména a hesla, pro jiné je možné přístupy dále kategorizovat v rámci bezpečnostních politik. Silnější úrovně mohou mít formát digitálních certifikátů a osobních identifikačních čísel „PIN“, v závislosti na povaze informací a transakcí.

Autorizace je identifikována pomocí jednoznačné lokalizace zdroje „URL“ a může být přidružena k množině či skupině uživatelů a uživatelských rolí. Pokud se změní vlastnost uživatelské role, tato změna se projeví současně ve všech systémech využívajících IDM.

Rozšířením stávající infrastruktury může IDM přinést sloučení roztříštěných identifikačních dat do jednoho celku s dalšími možnostmi, které lze využít v podnikové sféře:

• Konzistentní bezpečnostní politika přes celou síť
• Centralizované ověřování a autorizace
• Řízení celého životního cyklu identity
• Využití možnosti single sign-on pro jednorázové přihlášení do systému
• Pro obchodní partnery poskytuje IDM řešení podnikových vztahů se snížením rizika podvodných transakcí

Přesun k novým inteligentním aplikacím a operačním systémům požaduje implementaci systémů zahrnujících správu uživatelů i přístupů. Takové systémy dovolují administrátorům centralizovat jejich správu jak na úrovni řízení uživatelů, uživatelských rolí, přístupů a bezpečnostních politik v rámci organizace s ohledem na nepřeberné množství různých zdrojů.

Úkoly a cíle systémů pro IDM

Sloučení všech prvků infrastruktury řízení identit umožňuje administrátorům snižovat množství duplicitních úkolů napříč všemi spravovanými aplikacemi a systémy. Toto sloučení umožňuje delegování úkolů k dalším subjektům v závislosti na konkrétních požadavcích. Výsledkem takového prostředí je integrální, flexibilní, bezpečný a jednoduše řízený systém.

Systémy IDM poskytují integrální platformu, která zahrnuje nepřeberné množství dílčích částí:

• Bezpečné ověřování
• Kontrola přístupů
• Audity
• Zajištění synchronizace identit s delegováním možností
• Federativní řízení identit
• Podpora Security Assertion Markup Language „SAML“
• Vysoký výkon
• Vysokou dostupnost
• Snadnou rozšiřitelnost

Implementací IDM získává společnost výhody v silnější bezpečnosti ve všech síťových aplikacích, zvýšení produktivity a snížení nákladů na administraci. Společné řešení pomáhá společnosti zaměřit se na jejich hlavní činnosti a vyvíjet aplikace jako část integrálního celku se zapojením dalších moderních technologií.

IDM poskytuje společnosti možnosti pro identifikování problémů a současně dokáže tyto problémy řešit. Poskytuje také základ pro nasazování nových služeb v budoucnosti.

Pro dosažení stále se rozvíjejících požadavků enterprise, musí systémy pro správu identit splnit:

• Hloubka – společnosti vyžadují přínos IDM na mnoha úrovních, od základního provisioningu, řízení přístupů, možností zabezpečení pro zautomatizování poskytování a delegování na základě rolí a pravidel, federativní SSO a bezpečnost internetových služeb.
• Shoda – dnešní společnosti vyžadují infrastrukturu, která napomáhá zajistit shodu s požadavky regulátorů a interních politik, a musí být schopna dalšího rozšiřování a změn.
• Rozšiřitelnost – řešení IDM musí být schopny rozvíjení přes celý enterprise segment.

Integrace – komponenty IDM jsou vyvíjeny pro úzkou spolupráci s dalšími prvky v IT infrastruktuře.

Lightweight Directory Access Protocol

Lightweight Directory Access Protocol „LDAP“ je protokol vytvořený pro ukládání a přístup k datům umístěných na adresářovém serveru „DS“.

Standardy a doporučení DAP a LDAP

Protokol LDAP vychází z Directory Access Protocol „DAP“, který byl vytvořen na základě doporučení X.500, které bylo vyvinuto a přijato organizací International Consultative Committee of Telephony and Telegraphy „ICCTT“. Vzhledem ke složitosti protokolu DAP byla vytvořena organizací Internet Engineering Task Force „IETF“ odlehčená verze, LDAP, která byla akceptována jako standard ve světě ICT.

Popis a cíle LDAP

Rozlehlé firemní počítačové sítě s velkým množstvím terminálů, síťových komponent, aplikací a uživatelů vždy vyžadovali informační systém, který poskytuje jména, adresy a další důležité atributy o lidech a objektech zahrnutých k komunikaci. Z pohledu uživatele je adresář databáze, kde jsou uloženy informace o skutečných objektech a tyto informace jsou dostupné na vyžádání. Tato databáze je označována jako adresářová informační báze „DIB“. Každý známý objekt v adresářové službě je reprezentován záznamem v DIB.

Jednotlivé entity adresáře X.500 jsou na adresářovém serveru uspořádány do stromové struktury pod společnou entitou root. Hierarchie obsahuje prvky (anglicky): country, organization, organization unit a person. Záznam v každé z těchto větví musí obsahovat určité atributy, z nichž některé jsou povinné a jiné volitelné. V každém firemním prostředí může být adresář implementován jinou cestou tak, aby bylo dodrženo základní schéma nebo určitý plán.

Distribuované globální adresáře pracují skrze registrační proces a jedno nebo více centrálních míst, které spravují adresáře. V X.500 je každý lokální adresář nazýván Directory System Agent „DSA“. DSA může být reprezentován jednou nebo skupinou organizací. Jednotlivé DSA jsou vzájemně propojeny v Directory Information Tree „DIT“. Uživatelský program přistupující k jednomu nebo více DSA je nazýván Directory User Agent „DUA“.

Directory Information Base „DIB“

Soubor všech informací uložených v adresáři je znám jako Directory Information Base „DIB“. Skládá se ze záznamů, kde každý jednotlivý obsahuje informaci o jednom objektu. Objekt je identifikován atributy, které můžou být definovány různým typem a jednou nebo několika hodnotami. Typ atributu záleží na třídě objektu, který popisuje záznam. Objekty mající podobné vlastnosti jsou identifikovány vlastní třídou objektů. Každý záznam v adresáři je členem minimálně jedné třídy objektu. DIB a jeho struktura je definována v ITU-T Rec. X.501.

Directory Information Tree „DIT“

Informace uložené v DIB mají přesnou strukturu a hierarchii využívající stromovou strukturu. DIB je tedy reprezentován jako Directory Information  Tree „DIT“, kde každý uzel ve stromě reprezentuje záznam adresáře.

Jmenná konvence

Každý objekt uložený v adresáři je rozeznán od ostatních objektů svým jednoznačným názvem, které se označuje jako Distinguished Name „DN“. Každý jednotlivý záznam přebírá od svého nadřazeného záznamu jeho název, který je připojen k jeho vlastnímu názvu Relative Distinguished Name „RDN“.

Sufix (jmenný kontext)

Sufix (přípona) je DN, které identifikuje nejvyšší záznam v lokální adresářové hierarchii. Protože LDAP používá relativní jmenné schéma, toto DN je také sufixem každého dalšího záznamu v adresářové hierarchii. Adresářový server „DS“ může obsahovat několik různých sufixů, každý identifikující vlastní adresářovou hierarchii. Příkladem může být o=Firma,c=CZ.

Relative Distinguished Name „RDN“

V hierarchicky organizovaném adresářovém stromu jsou objekty identifikovány unikátní cestou jmen patřící nadřazenému objektu. Například v hierarchii poštovní adresy, objekt ulice může zahrnovat jméno města, stát a zemi. Tento název se označuje jako Distinguished Name (DN). Název jednoho objektu z pohledu objektu druhého je označován jako Relative Distinguished Name (RDN).

Na obrázku výše je například RDN záznamu ZáznamA název c=CZ.

Distinguished Name „DN“

Distinguished Name (DN) je globální autoritativní název instance v adresáři dle OSI X.500. DN je obsahem globální unikátní identifikace uživatelů nebo systémů. DN například zajišťuje, že digitální certifikát vydaný konkrétnímu člověku nemůže být použit jinou osobou stejného jména. DN unikátně identifikuje záznam vztahující se k rootu objektu, případně je DN celé jméno objektu. DN se skládá ze setříděného seznamu RDN, začínající rootem objektu.

DN záznamu ZáznamC je tedy c=CZ,o=Firma,cn=Jarmil.

Adresářové schéma

Adresářové schéma je množina pravidel zaručující, že DIB zůstane z pohledu dalších změn stále ve stejné podobě. Obsah záznamů ve strumě je určen právě adresářovým schématem. Díky těmto pravidlům se předchází možnosti mít špatně nastavené atributy pro jednotlivé třídy objektů. Schéma definuje typy atributu, které může adresářový záznam obsahovat.

Schéma definuje třídy objektu. Každý záznam musí mít atribut objectClass, obsahující pojmenovanou třídu definovanou v adresářovém schématu. Typicky je atribut objectClass vícehodnotový a obsahuje třídu top stejně jako čísla dalších tříd. Definice schématu pro každou třídu záznamu vymezuje, jaký druh objektu může záznam reprezentovat.

To znamená, že členství v konkrétní třídě dává záznamu možnost obsahovat alternativní množinu atributů a povinnost obsahovat další povinný soubor atributů. Například záznam reprezentující osobu může patřit třídám top a person. Členství v třídě person vyžaduje nutnost vyplnit atributy sn a cn, a dovoluje userPassword, telephonNumber a další.

objectclass ( 2.5.6.6 NAME ‚person‘
DESC ‚RFC2256: a person‘
SUP top STRUCTURAL
MUST ( sn $ cn )
MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )

attributetype ( 2.5.4.3 NAME ( ‚cn‘ ‚commonName‘ )
DESC ‚RFC2256: common name(s) for which the entity is known by‘ SUP name )

Jelikož můžou záznamy náležet do několika tříd, každý záznam obsahuje směs volitelných a povinných množit atributů sjednocených tříd objektů, které obsahují.

Většina adresářových schémat obsahuje jméno a globální unikátní identifikátor objektu OID (Object Identifier).

Identifikátor objektu

Každá třída objektu, atribut nebo typ atributu musí mít unikátní identifikátor umožňující adresářové službě správné rozlišení. Tento unikátní identifikátor se nazývá OID (Object Identifier). OID poskytuje informaci, jak jsou atributy uloženy v adresáři stejně jako vodítko pro správné pojmenování. Strukturálně se OID skládá z hierarchicky poskládaných uzlů namapovaných ve jmenném prostoru.

attributetype ( 1.3.6.1.1.1.1.0 NAME ‚uidNumber‘
DESC ‚An integer uniquely identifying a user in an administrative domain‘
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
attributetype ( 1.3.6.1.1.1.1.1 NAME ‚gidNumber‘
DESC ‚An integer uniquely identifying a group in an administrative domain‘
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

attributetype ( 1.3.6.1.1.1.1.2 NAME ‚gecos‘
DESC ‚The GECOS field; the common name‘
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

attributetype ( 1.3.6.1.1.1.1.3 NAME ‚homeDirectory‘
DESC ‚The absolute path to the home directory‘
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

Formálně jsou OID definovány dle standardu ITU-T ASN.1. Následná čísla uzlů, začínající rootem stromu, identifikují každý jednotlivý uzel ve stromě. Návrháři umisťují nové uzly pomocí registrace pod registrační autoritou každého jednoho uzlu.

Uvnitř schémat LDAP, každá třída a každý atribut má unikátní OID.

Bezpečnost LDAP

Vzhledem k důležitosti a s ohledem na informační hodnotu dat uložených v adresářovém serveru je nedílnou součástí LDAP bezpečnostní politika. Celý bezpečnostní model je popsán v konkrétních dokumentech RFC.

RFC 2829 – Authentication Methods for LDAP definuje základní hrozby pro LDAP adresářové služby:

• Neautorizovaný přístup přes operaci data-fetching
• Neautorizovaný přístup s použitím informací získaných monitoringem cizích přístupů
• Neautorizovaný přístup k datům získaných monitoringem cizích přístupů
• Neautorizovaná úprava dat
• Neautorizovaná úprava konfigurace
• Neautorizované nebo nadměrné využití zdrojů – DoS
• Vydávání se za adresářový server

LDAP v3 uplatňuje čtyři typy ověřování:

• Bez ověření – anonymní přístup

Anonymní přístup slouží pro přístup do adresáře bez poskytnutí ověřovacích informací. S řízením kontroly přístupů můžeme nastavit anonymním uživatelům přístupová práva dle našeho uvážení. Často jsou anonymním uživatelům zpřístupněny pouze data takové povahy, která nejsou citlivá, jako jména, telefonní čísla a emailové adresy. Lze tedy například zabezpečit přístup pouze k určitému typu atributů, obsahující pouze informace o kontaktech.

• Základní ověření

Ověření se uskutečňuje na základě znalosti DN (Distinguished Name) a hesla. Data jsou přenášena v textovém formátu nebo zakódována pomocí Base64.

• Ověřování pomocí PKI

Pro ověření klient digitálně podepíše náhodně vygenerovaný řetězec dat a pošle je spolu s certifikátem na server. Na serveru se provede ověření certifikátu porovnáním s certifikátem uloženým na serveru.

• Jednoduché ověření a s použitím SASL

Simple Authentication and Security Layer „SASL“ je framework zásuvných modulů pro použití alternativních bezpečnostních mechanismů. Tyto mechanismy zahrnují: Kerberos v4, S/Key, GSSAPI, CRAM-MD5, TLS, ANONYMOUS

Zabezpečení komunikace je možné díky StartTLS/SSL. SSL je protokol, který je určen pro zabezpečení komunikace a provádění ověřování. Primárně slouží pro zabezpečení TCP/IP jako transparentní mezivrstva mezi aplikací a sítí.

Další prvkem zabezpečení adresářových služeb LDAP je tzv. řízení přístupů k obsahu uloženému v adresáři. Toto řízení se provádí pomocí ACI (Access Control Instructions). Mechanismus, kterým se definuje přístup k datům, se nazývá řízení přístupu (Access Control). V případě že adresářový server přijme požadavek, použije ověřovací informace poskytnuté uživatelem v operaci bind a ACI definované v adresáři pro povolení nebo zakázání přístupu k adresářovému obsahu. Server muže povolit nebo zakázat přístup pro operace čtení, zápisu, vyhledávání nebo porovnání. Úroveň zabezpečení může záležet na poskytnutých ověřovacích informacích.

Za použití ACI můžeme řídit přístup k celému adresáři, stromu, části stromu, jednotlivým záznamům nebo specifické množině atributů. Práva lze nastavit pro jednotlivé uživatele, skupinu uživatelů nebo všechny uživatele v adresáři. Lze také řídit přístup pro klienty s určitou IP adresou nebo doménovým jménem.

ACI jsou uloženy v adresáři jako atributy záznamů. Atribut aci je atributem operativním. Je použit adresářovým serverem pro vyhodnocení informace, jaká práva jsou povolena nebo zakázána v případě obdržení LDAP požadavku ze strany klienta. Atribut aci je také vracen na vyžádání operace ldapsearch.

Třemi hlavními částmi pravidla ACI jsou:

• Cíl – určuje záznam nebo atributy, na které se pravidlo vztahuje
• Práva – určuje, které operace jsou povoleny nebo zakázány
• Uživatel – určuje pro koho je ACI pravidlo určeno. Uživatel je identifikován pomocí DN.

Každý adresářový produkt používá vlastní syntaxi ACI (příklad OpenLDAP a OpenDS):

# users can authenticate and change their password
access to attrs=“userPassword,sambaNTPassword,sambaLMPassword“
by dn=“cn=samba,ou=DSA,dc=firma,dc=cz“ write
by dn=“cn=smbldap-tools,ou=DSA,dc= firma,dc=cz“ write
by dn=“cn=nssldap,ou=DSA,dc= firma,dc=cz“ write
by dn=“uid=root,ou=People,dc= firma,dc=cz“ write
by dn=“cn=syncuser,ou=DSA,dc= firma,dc=cz“ write
by anonymous auth
by self write
by * none

access to *
by dn=“cn=samba,ou=DSA,dc= firma,dc=cz“ write
by dn=“cn=syncuser,ou=DSA,dc= firma,dc=cz“ read
by * read

(target=“ldap:///“)(targetscope=“base“)(targetattr=“objectClass||namingContexts||supportedAuthPasswordSchemes||supportedControl||supportedExtension||supportedFeatures||supportedLDAPVersion||supportedSASLMechanisms||vendorName||vendorVersion“)
(version 3.0; acl „User-Visible Root DSE Operational Attributes“;
allow (read,search,compare) userdn=“ldap:///anyone“;)

Replikace

Replikace adresářového obsahu umožňuje dosahovat vyšší dostupnosti a výkony adresářových služeb. Replikace je mechanismus, kdy jsou data z jednoho adresářového serveru automaticky kopírována do jiného adresářového serveru. S použitím replikace může být jakýkoli DIT, nebo část DIT, kopírován mezi servery. Adresářový server plnící funkci master, automaticky kopíruje informace o změnách do ostatních replik. Replikací adresářových dat můžeme snižovat zatížení jednoho serveru, snižovat čas odpovědí a poskytovat vyšší stabilitu. Replikace záznamů adresáře co nejblíže k uživateli nebo aplikaci můžeme více snižovat latenci. Replikace není primárně určena pro rozšiřování možností zápisu do adresáře.

Jakákoli databáze účastnící se replikace se nazývá replika. Používají se tři typy replik:

• Master replika je replika sloužící jak pro čtení tak i pro zápis. Obsahuji hlavní kopii adresářových dat. Master replika vykonává následující úkony:
  • Odpovídá za změny uvnitř adresáře a čtení záznamů klienty
  • Udržuje historické informace o replice a udržuje protokol o dotazech
  • Inicializuje replikaci do ostatních replik
• Slave replika je podřízenou replikou, která slouží pouze pro čtení záznamů z adresáře. Slave replika vykonává následující úkony:
  • Odpovídá za čtení záznamů klienty
  • Udržuje historické informace o replice a udržuje protokol o dotazech
  • Mění data ve své databázi na základě požadavků master repliky
• Centrální slave replika je službou určenou pouze pro čtení. Tato replika je podobná slave replice s tím rozdíle, že je na adresářovém serveru umístěno více slave replik. Centrální slave replika vykonává následující úkony:
  • Odpovídá za čtení záznamů klienty
  • Udržuje historické informace o replice a udržuje protokol o dotazech
  • Inicializuje replikaci do slave replik
  • Mění data ve své databázi na základě požadavků master repliky

Replikace poskytuje následující výhody:

• Fault tolerance a failover – replikace DIT přes několik serverů, kdy je adresářová služba dostupná i v případě výpadku některého z adresářových serverů.
• Load balancing – replikace DIT přes několik serverů snižující zatížení jednoho stroje, což má za následek zvýšení rychlosti odezvy na dotazy.
• Vysoký výkon a zvýšení rychlosti odezvy – replikace adresáře blíže k uživatelům nebo aplikacím přímo zvyšuje rychlost odezvy na dorazy.
• Místní správa dat – replikace dovoluje lokální správu a vlastnictví DIT a současné sdílení v rámci enterprise sítě.

Nejmenší jednotkou určenou k replikaci je suffix. Nicméně není možno replikovat dva jmenné kontexty uložené na master replice do jednoho uloženého na slave replice.

Pro odlišení master replik se používá unikátní identifikátor, kterým je 16b číslo mezi 1 – 65534. Slave repliky používají 65535. Toto číslo slouží k identifikaci replik sloužících k zápisu. Pokud je na master adresářovém serveru použito několik jmenných kontextů, mohou používat stejný identifikátor pro identifikaci serveru, na kterém se změny provádí.

Vztahy mezi repliky jsou řešeny v konfiguraci replikace. Tato konfigurace je uložena na master replice a obsahuje následující parametry:

• Suffix určený k replikaci
• Slave server, na který jsou data odesílána
• Plán replikací
• DN a heslo pro komunikaci mezi replikami
• Nastavení zabezpečení
• Nastavení atributů zahrnutých v případě částečné replikace
• Skupina a velikost okna definující množství dat odeslané slave replice před potvrzením přijetí
• Případné nastavení stupně komprese u některých systémů

Na základě požadavků na topologii replik a vzájemné konfiguraci existuje několik scénářů replikací:

• Single master replikace jejíž použití je nejzákladnější replikační konfigurací obsahuje master repliku kopírující data přímo do jednoho nebo více podřízených serverů, které slouží pouze pro obsluhu dotazů klientů. Veškeré změny klienty jsou prováděny pouze v master replice.

• Multi-master replikace neobsahuje žádné slave repliky. V tomto prostředí master repliky obsahují stejná data. Tato data mohou být současně upravována na několika různých geografických místech. Změny jsou poté replikovány na ostatní adresářové servery.

• Kaskádní replikace využívá centrální slave repliky, která přebírá změny z master repliky a poskytuje je dále slave replice. Centrální slave replika se tedy chová jako slave replika v kombinaci s master replikou, která je pouze pro čtení.

• Smíšená topologie obsahuje všechny výše zmíněné scénáře, od multi-master až po kaskádní konfiguraci replik.

Závěr

Díky využívání standardů a doporučení pro návrh a vývoj řešení jsou LDAP servery založené na LDAP verze 3 kompatibilní a umožňují vzájemnou interakci z pohledu řízení zdrojů a přístupů. Zejména komerční řešení obsahují rozhraní pro připojování externích zdrojů dat, ať jsou to LDAP servery, internetové služby nebo databáze, a poskytují transparentní přístup k různým typům zdrojů. V tomto ohledu lze poukázat na adresářové servery typu proxy, které neumožňují uchování adresářových dat, ale zpřístupňují obsah z cizích zdrojů. Další možností je použití federativních služeb, které slouží pro propojování zdrojů na intranetové i extranetové úrovni a řeší problém vzájemné důvěryhodnosti.

Problém se vzájemnou kompatibilitou lze ale například vidět u produktu Microsoft Active Directory, kde je použito odlišné hierarchie adresářového služby, která více vyhovuje prostředí sítí založených právě na operačním systému Windows. Zde se uplatňuje jiný přístup ke sdíleným zdrojům, který je nicméně také založen na LDAP verze 3, avšak obsahuje další specifické prvky pro Microsoft Active Directory, kterými je například absence ACI, implementace důvěryhodnosti založené na doménách a odlišných bezpečnostních politikách. V případě interakce s Microsoft Active Directory používají ostatní adresářové systémy specializované konverzní nástroje, které umožňuji synchronizaci odlišných adresářových systémů a adresářových schémat. Právě rozdílnost adresářových schémat je další z rozdílů mezi Microsoft Active Directory a dalšími adresářovými servery.

Mezi největší hráče na poli komerčních řešení adresářových serverů patří zejména Oracle, IBM, Microsoft a Red Hat. Z pohledu použití v prostředí menších společností, které hledají enterprise level systém s nízkou cenou, vysokou dostupností a rozšiřitelností je na prvních místech Sun Microsystems, Red Hat a Novell. Ostatní komerční řešení nabízejí velké množství funkcí pro použití v enterprise prostředí, avšak za cenu podstatně vyšší. Pouze Sun Microsystems ale nabízí kompletní řešení správy celého životního cyklu uživatelských identit za cenu stažení software a implementace v podnikovém prostředí. Pokud však společnost vyžaduje stálou podporu na produkt ze strany dodavatele, tato podpora je již placena. Nicméně ve všech případech lze na internetu nalézt vyčerpávající informace pro řešení každodenních problémů s provozem a nasazováním těchto produktů.

Zdroje

[1] Apache Software Foundation: Apache Directory Server v1.0 – Apache HTTP Server [2009-04-22]: <http://directory.apache.org/apacheds/1.0/43-apache-http-server.html>
[2] Apache Software Foundation: Apache Directory Server v1.0 – ome Background. Directories, directory services and LDAP [2009-04-22]: <http://directory.apache.org/apacheds/1.0/12-some-background-directories-directory-services-and-ldap.html>
[3] Apache Software Foundation: Apache Directory Server v1.0 – What Apache Directory Server is [cit. 2009-04-22]: <http://directory.apache.org/apacheds/1.0/11-what-apache-directory-server-is.html>
[4] Ella Deon Lackey: Red Hat Directory Server 8.1 Deployment Guide: 2009 Red Hat, Inc.
[5] IBM: Addressing single sign-on inside,outside, and between organizations: PN TIW14018-USEN-00
[6] IBM: IBM Tivoli Directory Server: PN TID10444-USEN-00
[7] IBM: IBM Tivoli Identity Manager: PN TID10294-USEN-00
[8] IDC, Sally Hudson: Worldwide Identity and Access Management 2008 – 2012 Forecast and 2007 Vendor Shares: #213650
[9] IETF: Request for Comments: <http://www.ietf.org/rfc.html>
[10] Nokia Siemens Networks: PLMN C-NTDB Basics: PN CN6740EN20GLA00
[11] Novell: Novell eDirectory 8.8 Administration Guide
[12] OpenLDAP: OpenLDAP Software 2.4 Administrator’s Guide: Introduction to OpenLDAP Directory Services
[13] Oracle: Oracle Identity Management 11gR1: 2009 Oracle Corporation
[14] Oracle: Oracle Identity Manager feature overview 10gR3v3 [2009-04-22]
[15] Oracle: Oracle Whitepaper – Oracle Role Management Architecture: 2008 Oracle Corporation
[16] Sun BluePrints™: TomBialaski: Demystifying the LDAP Directory Information Tree [OnLine – April 2001]
[17] Sun Microsystems: Federating to Google Apps with OpenSSO [2009-07-01]
[18] Sun Microsystems: Keeping IT simple, a pragmatic approach to identity management: SunWIN #557782 Lit. #SWWP14833-0 03/09
[19] Sun Microsystems: Sun Java™ System Access Manager Configuration and Customization: PN 705-7839-10
[20] Sun Microsystems: Sun Java™ System Identity Manager 7.0 Technical Deployment Overview: PN 819-6126-10
[21] Sun Microsystems: Sun OpenDS™ Standard Edition: SunWIN #542235 Lit. #SWDS14482-0 9/08
[22] Sun Microsystems: Sun OpenSSO Enterprise: SunWIN #541269 Lit. #SWSB14464-0 09/08
[23] WIKIPEDIA, the free encyclopedia: Active Directory [2009-04-22]: <http://en.wikipedia.org/w/index.php?title=Active_Directory>
[24] WIKIPEDIA, the free encyclopedia: Identity management [2009-03-10]: <http://en.wikipedia.org/wiki/Identity_management_system>
[25] WIKIPEDIA, the free encyclopedia: Identity management systems [2009-04-22]: <http://en.wikipedia.org/w/index.php?title=Identity_management_systems>
[26] WIKIPEDIA, the free encyclopedia: Lightweight Directory Access Protocol [2009‑03-10]: <http://en.wikipedia.org/wiki/LDAP>
[27] WIKIPEDIA, the free encyclopedia: Single Sign-On [2009-04-22]: <http://en.wikipedia.org/wiki/Single_sign-on>
[28] Windows Server 2003: Active Directory Infrastructure: Microsoft Press: ISBN 0‑7356-1438-5