Adresářové služby – úvod do problematiky

Transkript

Technická zpráva TEN-155 CZ číslo 4/2000
Adresářové služby – úvod do problematiky
Jiří Sitera
7. září 2000
1
Adresářové služby
Tato kapitola se snaží o přiblížení pojmu „adresářové služby“ a poskytuje přehled základních informací z této oblasti.
1.1
Jmenné služby
Jmenné služby obecně jsou jedním ze základních kamenů síťových technologií
a síťové infrastruktury. Mnoho entit vyskytujících se v komunikačních technologiích se identifikuje čísly, přičemž existuje snaha o zavádění dalšího pojmenování těchto entit. V tomto okamžiku vzniká potřeba služby, která zajišťuje
vazbu jména na číselnou identifikaci. Používání termínů „číslo“ a „jméno“ je
spíše symbolickým, resp. snadno pochopitelným příkladem. Hlavním důvodem
pro zavádění jmenného systému není totiž jen zakrytí vnitřních identifikátorů z
hlediska člověka „přijatelnějšími“, ale i řada dalších aspektů, především souvisejících se strukturou jmenného prostoru zavedených jmen. Tento jmenný prostor
je totiž obvykle strukturovaný – hierarchický a v každém případě nezávislý na
omezeních a vnitřní struktuře primárních identifikátorů.
Příkladem jmenné služby je DNS (Domain Name System). Jedná se o specializovanou jmennou službu, která poskytuje v rámci sítí TCP/IP a Internetu funkci
pro převod IP adres na (DNS) jména. DNS jména mají hierarchický charakter
a logickou strukturu nezávislou na struktuře odpovídajících IP adres. Pomocí
DNS mohou být dále získávány některé další informace přiřazené jednotlivým
jménům, jako jsou například odkazy na tzv. mail exchanger, tj. uzel prostřednictvím kterého je doručována pošta1 . Implementace DNS je navržena tak, aby
vyhověla nárokům které jsou na ni kladeny – databáze zahrnuje celý Internet a
poskytuje služby všem uzlům v něm zapojeným. Mezi hlavní znaky implementace patří distribuce dat, replikace dat a decentralizovaná správa. Více o DNS viz
[DNSAit].
1
Existují obecnější jmenné služby založené na infrastruktuře DNS, jako je například Hesiod,
který slouží k distribuovanému přístupu k informacím typu uživatelé, služby, zdroje, atd. Stejně
tak existují obecnější jmenné služby, které jsou samostatné. Jako příklad může sloužit NIS
(Network Information System) (viz například také [DNSAit]).
1.2
Adresářovou službou se rozumí specializovaná aplikace pro ukládání dat, jejich
organizaci a přístup k nim. Specifikum je především v datovém modelu, který
je rámcem pro práci s daty. Nejjednodušší představa je taková, že data jsou
uložena ve formě položek, přičemž každá položka obsahuje několik atributů.
Atribut je nositelem dat, tj. má hodnotu.
Entry
Name
Attribute
Name
Value
Obrázek 1: První přiblížení formy uložení dat v adresářových službách entry–
položka, attribute–atribut, name–jméno, value–hodnota
Na obrázku 1 je naznačen vzájemný vztah položek a atributů. Každá položka
má unikátní jméno (globálně v rámci položek – více viz dále) a každý atribut
má unikátní jméno v rámci položky2.
Jméno položky je strukturované, složené z hierarchicky uspořádaných částí.
Logicky jsou takto položky v adresářových službách rozmístěny v hierarchické
struktuře, adresářovém stromu. V souvislosti s tím, se setkáváme s pojmem DIT
(Directory Information Tree).
1.2.1
DIT – Directory Information Tree
Pod pojmem DIT (Directory Information Tree) se rozumí především konkrétní
návrh struktury adresářového stromu, jeho větvení, tj. rozčlenění položek a
2
Mohou existovat vícenásobné atributy, které si lze představit buďto jako jeden atribut s více
hodnotami nebo jako několik atributů se stejným jménem a různými hodnotami. V podstatě
jsou obě představy správné, ale je třeba si uvědomit, že k atributu lze přistupovat pouze na
základě jeho jména, takže první představa spíše odpovídá možným operacím.
2
informací jimi nesených do hierarchicky uspořádaných skupin. Pro přiblížení
významu DIT je na obrázku 2 je zobrazena část konkrétního adresářového
stromu. Je účelné si uvědomit, že takto lze rozdělit položky adresářového stromu
na uzly a listy. Uzly definují větve stromu, zatímco listy jsou samostatnými
koncovými objekty. Samozřejmě i uzlová položka může nést další informaci, než
je pouhá existence větve adresářového stromu, nicméně aby bylo lze umisťovat
do příslušné větve nějaké položky musí uzlová položka existovat.
zcu.cz
<depts>
People
Staff
civ
Jiri Siter
a
Groups
Administrators
Groups
Resources
Jiri Siter
a
Node
Leaf
Obrázek 2: Stromová struktura adresářových služeb node–uzel, leaf–list
Pro návrh DIT – architektury adresářových služeb z hlediska členění adresářového stromu a tím i informací – existuje mnoho různých postupů. Členění
konkrétního stromu je totiž právě jedno, přičemž existuje vždy mnoho různých
hledisek a vlivů, které je vhodné posoudit. V této oblasti existuje několik prací
poskytujících rozbor jednotlivých možností (např. [DITDesign, NS-deploy]).
Struktura stromu (DIT) se přímo projeví ve jménech jednotlivých položek. Každá
položka obsahuje unikátní jméno, které je složeno z části, která popisuje do které
větve adresářového stromu položka patří a z unikátního jména položky v rámci
větve.
3
1.2.2
Pojmenování položek – DN (Distinguished Name)
DN (Distinguished Name), tj. rozlišovací jméno identifikuje jednoznačně položku
v globálním jmenném prostoru adresářového stromu. Rozlišovací jméno se
skládá z RDN (Relative Distinguished Name), tj. relativních rozlišovacích jmen.
Relativní rozlišovací jméno unikátně specifikuje položku v rámci jedné větve
stromu. Rozlišovací jméno se skládá z jednotlivých relativních rozlišovacích
jmen, které odpovídají větvím adresářového stromu, kterými je třeba projít
v hierarchii mezi položkou a kořenem stromu.
Lze říci, že tato hierarchická architektura a způsob pojmenování jednotlivých
položek je analogická souborovému systému a jeho adresářové struktuře.
Každé relativní rozlišovací jméno je odvozeno od atributu (jména a hodnoty)
příslušné položky3.
1.2.3
Příklad – pojmenování atributů, tvorba rozlišovacího jména
Pojmenování atributů
Každý atribut má své jméno. Existují standardy pro jména a významy běžných
atributů.
Na tomto místě je třeba poznamenat, že každé položce je přiřazen typ položky
(objectclass). Typ položky určuje, které atributy se mohou v položce vyskytovat,
přičemž může stanovit skupinu atributů, které se musí v položce vyskytovat.
Stejně tak atributy mají přiřazen typ. Zde se jedná pouze o jednoduché typy,
jako například celé číslo či řetězec. Tato pravidla jsou definována tzv. schématem
databáze. Více o schématu viz kapitola 1.5.2.
Některé nejzákladnější atributy, které slouží jako elementy relativního rozlišovacího jména, jsou uvedeny v následující tabulce:
Jméno atributu, alias
country, c
organization, o
organizationalUnitName, ou
commonName, cn
význam
jméno (zkratka) státu
jméno organizace
jméno organizační jednotky
„common name“ položky
příklad
cz
zcu
civ
Jiri Sitera
Tabulka 1: Atributy pro relativní rozlišovací jména
Rozlišovací jméno
Na obrázku 3 jsou doplněny hodnoty některých základních atributů u položek
3
Toto je nejjednodušší případ, obecně je RDN odvozeno od atributů (jednoho nebo více)
příslušné položky.
4
zcu.cz
<depts>
o=zcu, c=cz
People
ou=People
Staff
ou=Staff
civ
ou=civ
Jiri Siter
a
cn= Jiri Sitera
Groups
ou=Groups
Administrators
ou=A dministrators
Groups
Resources
Jiri Siter
a
Node
Leaf
Obrázek 3: Atributy určující relativní rozlišovací jméno položky
5
v příkladu adresářového stromu. Náš příklad specifikuje podvětev, která je
umístěna v oblasti pojmenované dle organizace, v našem případě
o=zcu, c=cz
V této větvi jsou umístěny všechny objekty (položky) adresářového stromu z
uvedeného příkladu, tj. všechna jména budou mít výše uvedenou specifikaci
jako suffix. Pro uzly stromu v návrhu DIT jsou v našem příkladu použity atributy ou, organization unit name. Pojmenování objektu uživatele či skupiny je
reprezentováno atributem cn. Pak pojmenování neboli rozlišovací jméno (DN)
položky uživatele v příkladu je:
cn=Jiri Sitera, ou=CIV, ou=Staff, ou=People, o=zcu,
c=cz
a (položky) skupiny:
cn=Administrators, ou=Groups, o=zcu, c=cz
1.2.4
Základní vlastnosti
Adresářové služby jsou navrženy pro specifickou oblast aplikací. Jak návrh
komunikačního protokolu, tak implementace hlavních částí těchto systémů jsou
vedeny snahou o specializaci. Hlavní myšlenkou je specifikace specializovaného
datové modelu, který definuje rámec pro ukládání informací a přístup k nim
(operace nad nimi). Za adresářové služby lze v podstatě považovat množinu
nástrojů pro práci s takto uspořádanými daty (spolu s metodologií k jejich
použití).
Podstata tohoto přístupu je analogická jako například u relačních databází.
Relační model dat je navržen a použit pro usnadnění tvorby složitých datových
struktur a slouží také jako základ pro efektivní návrh a realizaci jisté množiny
aplikací.
Lze říci, že v případě adresářových služeb se jedná o specializovanou databázi
určenou především pro realizaci aplikací, které zacházejí s daty, k nímž je
velmi intenzivně přistupováno (čtení, prohledávání), ale nejsou příliš často
měněna. A pokud jsou měněna, tak pouze velmi jednoduchými prostředky
(žádné transakce apod.)4 .
4
Toto je základní představa adresářových služeb. To však neznamená, že se nemohou ukázat rozumnými například snahy o rozšíření možností změn položek v adresářových službách
(často se měnící data, jako je např. stav zařízení; podpora jednoduchých transakcí) – otevřené
standardy v těchto oblastech otevírají volnou cestu libovolnému vývoji, který se ukáže životaschopným.
6
1.2.5
Základní použití
Základním příkladem použití adresářových služeb jsou aplikace jako telefonní
seznam (seznam lidí), či databáze zdrojů, například tiskáren či aplikačních
serverů. V případě telefonního seznamu mohou adresářové služby obsahovat
položky reprezentující jednotlivé lidi, přičemž u každé položky jsou uvedeny
atributy s informacemi jako je telefonní číslo, číslo kanceláře, e–mail apod. U
objektů popisujících tiskárny může jít například o informace typu formát papíru,
rychlost tisku, umístění či cena vytištěné strany.
Adresářové služby primárně dovolují uživatelům a aplikacím hledat objekty
(lidi, zdroje) dle specifikovaných podmínek. Například jsou určeny pro zodpovídání dotazů typu „hledám uživatele a znám e-mail“ nebo „hledám tiskárnu
formátu A4, která umí tisknout barevně“.
Adresářové služby mohou samozřejmě sloužit také k získávání informací o
konkrétních objektech, tj. znám-li konkrétní specifikaci objektu (například jméno
tiskárny), mohu se dotázat na její vlastnosti5 .
Specializované prostředky pro ukládání dat a přístup k nim.
Optimalizace návrhu vzhledem k specifickým podmínkám, zejména:
– Předpoklad málo se měnících informací.
– Předpoklad jednoduchých operací s daty.
– Předpoklad majority přístupů, které pouze čtou data, navíc obvykle
potřebují data hledat.
1.3
1.3.1
X.500, LDAP – standardy adresářových služeb
Co je to X.500
X.500 je obvyklá zkratka používaná pro označení standardu adresářových služeb, který definují dokumenty X.500 až X.521 [X.500]. Standard X.500 byl vytvořen CCITT (Consultative Committee on International Telephony and Telegraphy)
a je postaven na rodině protokolů ISO/OSI. X.500 je poměrně komplexní a standardní specifikace pro adresářovou organizaci dat a operace nad nimi.
5
V literatuře se lze často setkat s pojmy jako jsou yellow pages a white pages. Tyto pojmy
v podstatě odpovídají dvěma naznačeným přístupům. Hledání objektu, který splňuje žádané
podmínky je analogické používání zlatých (žlutých) stránek (yellow pages), zatímco získání
informací o konkrétním objektu (jehož identifikaci – jméno – znám) odpovídá použití bílých
stránek telefonního seznamu (white pages).
7
Obecně lze říci, že X.500 je vystavěn na architektuře klient/server, přičemž definuje protokol pro komunikaci mezi klientem a adresářovým serverem directory
access protocol (DAP).
Protokol DAP, stejně jako implementace X.500 obecně, potřebuje OSI protokolový stack, který je relativně náročný na zdroje. Odtud plyne prvotní myšlenka
návrhu prostředku pro jednodušší (lightweight) přístupu k adresářovým službám.
1.3.2
Co je to LDAP
LDAP (Lightweight Directory Access Protocol) byl primárně navržen jako zjednodušená varianta protokolu DAP, tj. jako jednodušší přístupový protokol mezi
klientem a adresářovým serverem (X.500). Hlavní zjednodušení tkví v použití
rodiny protokolů TCP/IP jako komunikační vrstvy a ve zjednodušení protokolu
jako celku (minimalizovány operace, vypuštěny složitější vlastnosti).
Postupem času došlo k „osamostatnění“ protokolu LDAP, tj. byla uplatněna idea
samostatného LDAP serveru, což znamená adresářový server, který komunikuje s klientem protokolem LDAP (dosud sloužil LDAP pouze jako přístupový
protokol k „plnokrevnému“ X.500 serveru). Z obrázku 4 je tento vývoj jasně patrný. Tak se postupně stalo, že pod pojmem LDAP se rozumí nejen komunikační
protokol, ale i adresářový server sám (a to obvykle včetně všech náležitostí, tj.
především datového modelu a konceptu distribuované infrastruktury adresářových služeb). Z hlediska klienta by mělo být v principu jedno, zda přistupuje k
adresářovým službám realizovaným samostatným (LDAP) serverem, či zda se
jedná pouze o gateway k serveru X.500.
LDAP – hlavní významy
Protokol pro přístup k datům.
Model ukládání, organizace a přístupu k datům (informacím).
Rozhraní pro přístup k datům (operace).
1.3.3
Základní vlastnosti protokolu LDAP
Specifikace protokolu LDAP je implementačně nezávislá a je vedena snahou
o maximální jednoduchost – pro koncepci byla určující snaha o zjednodušení
implementace (za účelem podpory nasazení LDAPu v aplikacích, tj. tvorby tzv.
LDAP enabled aplikací). Díky těmto vlastnostem se protokol LDAP začal skutečně
výrazněji prosazovat a dosáhl dokonce stavu, kdy je běžně implementován a
užíván samostatně. Shrňme hlavní rozdíly oproti X.500:
8
LDA P
Client
TCP/IP
LDA P
Server
ISO/OSI
X.500
Server
Directory
Data
Stand-alone LDA P server
LDA P
Client
TCP/IP
LDA P
Server
Directory
Data
Obrázek 4: Protokol LDAP a jeho úloha
TCP/IP namísto OSI protokolového stacku,
jednodušší funkční model,
jednodušší reprezentace dat.
Globálně se k vývoji situace kolem protokolu LDAP dá říci asi toto: Poté, co se
protokol LDAP začal prosazovat díky svojí jednoduchosti, začala tato jednoduchost býti omezujícím aspektem pro některé případy nasazení. Z toho ovšem
vyplynula snaha o vylepšování protokolu LDAP a jeho doplňování dalšími vlastnostmi. Takto se vlastně tvoří nový standard pro adresářové služby a to od
elementárního (ale dostatečně otevřeného) základu, postupným doplňováním
potřebných vlastností.
LDAP – hlavní vlastnosti
Jednoduchost, dobrý poměr implementační náročnosti vůči šíři spektra
možného využití.
Rozšiřitelnost, otevřenost.
Distribuovaný model uložení dat a přístupu k nim.
9
1.4
Architektura protokolu LDAP
Protokol LDAP definuje komunikaci mezi serverem a klientem. Klient zašle serveru zprávu obsahující požadavek na provedení jedné z definovaných operací
a server vrátí odpověď (viz obrázek 5). Zprávy obsahují také příslušná data a
informace o jejich formátu.
Základní schéma komunikace:
Klient naváže spojení s LDAP serverem. Pro operaci navázaní spojení
se používá termín binding. Klient se může připojit anonymně nebo musí
prokázat svoji identitu (identitu uživatele) – provede se autentizace jednou
z možných metod.
Pro navázaní spojení je tedy nutné, aby klient znal IP adresu a port, na
kterém je LDAP server.
Klient má k dispozici spojení na server (identifikace spojení byla vydána
serverem při navázání spojení) a může v jeho rámci posílat žádosti o provedení definovaných operací nad adresářovými daty.
Klient uzavře spojení s adresářovým serverem. Pro tuto operaci se používá
termín unbinding.
Ačkoli se nejedná o přímou součást protokolu LDAP, jedním z důležitých faktorů
v této oblasti je standardní LDAP API (application program interface), tj. rozhraní
(knihovny) přímo přístupné pro psaní aplikací. Největší význam má standardní
rozhraní do jazyka C a jazyka Java.
LDAP
Architektura klient/server.
Komunikace prostřednictvím rodiny protokolů TCP/IP.
Standardní LDAP API, knihovny pro psaní aplikací.
Z hlediska návrhu adresářových služeb je komunikační protokol pouze jedním z
několika aspektů návrhu a implementace. Pro lepší pochopení celku je vhodné
rozčlenit LDAP do několika modelů:
Informační model – struktura informací uložených v adresářových službách.
Jmenný model – organizace a identifikace informací v adresářových službách.
10
Directory server
Directory client app.
Internal directory server structure
Application
Back end
Request
Reply
API
Front end
LDA P Client Library
LDA P reply/request
TCP/IP
TCP/IP
TCP/IP
Obrázek 5: Komunikace – architektura klient/server
11
Funkční model – operace nad informacemi v adresářových službách.
Bezpečnostní model – řízení přístupu k informacím v adresářových službách.
1.5
Informační model
Základní pojmy informačního modelu adresářových služeb byly nastíněny v
kapitole 1.2. Základní datová jednotka umístěná v adresářových službách se
nazývá položka. Položka má atributy, které popisují její vlastnosti. Jak položka,
tak atribut jsou identifikovány jménem (obrázek 1).
1.5.1
Atributy, syntaxe atributů
Každý atribut má přiřazen typ, tj. informaci o tom, jaké hodnoty může nést,
neboli informaci o syntaxi pro zápis hodnot atributu. Typ atributu také definuje
zacházení s hodnotou atributu při operacích, například při prohledávání či
porovnávání.
Například je definován typ atributu pro uložení telefonního čísla. Atribut označený tímto typem může obsahovat libovolný text, přičemž znaky jako mezera a
pomlčka se ignorují pro účely porovnávání. Dále se ignoruje velikost písmen a
je definováno lexikografické uspořádání.
Základní typy hodnot atributů jsou následující:
ces: řetězec znaků, při porovnávání se bere ohled na velikost písmen (Case
Exact String)
cis: řetězec znaků, při porovnávání se nebere ohled na velikost písmen (Case
Insensitive String)
tel: telefonní číslo, tj. řetězec znaků, mezery a pomlčky jsou při porovnávání
ignorovány stejně tak jako velikost písmen
bin: libovolná (binární) data
dn: rozlišovací jméno (objektu v adresářových službách)
1.5.2
Schéma
Také jména atributů a jejich význam, samozřejmě včetně přiřazení typu atributu,
jsou standardizována. Každá položka má navíc přiřazen typ, který popisuje které
atributy se musí a které se mohou u ní vyskytovat. Globálně se pro označení
popisu těchto pravidel používá pojmu schéma.
12
Jméno atributu, alias
organization, o
organizationalUnitName, ou
commonName, cn
surname, sn
telephoneNumber
jpegPhoto
typ atributu
cis
cis
cis
cis
tel
bin
význam
jméno organizace
jméno organizační jednotky
„common name“ položky
jméno osoby
telefonní číslo
portrét osoby
Tabulka 2: Příklady běžných atributů
Příklady některých nejběžnějších atributů, jejich typ a význam:
Schéma definuje třídy objektů (object class), tj. typy položek, které se mohou
vyskytovat v adresářovém stromu. Třída objektu definuje jména a typy atributů,
které se mohou v objektu (položce) vyskytovat, přičemž určuje, které z nich
jsou povinné (musí se vyskytovat). Typ položky ve formě jména třídy objektu
je u každé položky uveden ve vyhrazeném a povinném atributu objectClass.
Příklady tříd objektů (obsahují pouze příklady atributů, přičemž tučně tištěné
jsou povinné):
Třída objektu význam
příklad atributů
inetOrgPerson Reprezentuje člověka (v intranetu) commonName (cn)
surname (sn)
objectClass
mail
telephoneNumber
organization
Reprezentuje organizaci
organization (o)
objectClass
location (l)
postalAddress
seeAlso
Tabulka 3: Příklady tříd objektů
Při definování tříd objektů je možno používat dědičnost, tj. definovat novou třídu
objektů jako rozšíření jiné, již definované třídy. Schéma lze tedy chápat také jako
hierarchii tříd objektů6 .
Schéma dává možnost definovat vlastní datové typy, definovat popis nových
objektů nebo rozšiřovat či měnit popis běžných objektů. Pro interoperabilitu
6
Atribut objectClass obsahuje jména všech tříd objektů, které jsou použity pro definici
aktuální třídy objektu, tj. ze kterých je aktuální třída objektů odvozena.
13
je velmi důležitá standardizace, proto je třeba vycházet ze standardizovaných
schémat. Základní informace z této oblasti lze najít v [rfc2252] a [rfc2256].
Pro pokročilejší řešení interoperability je definován v rámci LDAP verze 3 mechanismus pro publikaci schématu. Adresářový server poskytuje některé základní informace o sobě včetně schématu, klienti mohou definovaným způsobem k těmto informacím přistupovat.
Pro textový zápis položky a obsahu adresářového stromu je definována syntaxe LDIF (LDAP Data Interchange Format) viz kapitola 1.9. Základní nástroje
pro komunikaci s adresářovým serverem z příkazové řádky (viz kapitola 1.10)
používají pro zápis dat také formát LDIF.
LDAP – informační model
Datové entity: položka, atribut.
Položka
– má typ položky (třída objektu),
– obsahuje atributy,
– má jméno, DN (rozlišovací jméno) globální v rámci DIT,
– uspořádání do Directory Information Tree (DIT).
Atribut
– má typ,
– má hodnotu, resp. hodnoty,
– má jméno – identifikaci v rámci položky.
Schéma – rozšiřitelnost (ale také standardizace).
1.6
Jmenný model
Základní koncept jmenného modelu byl nastíněn již v kapitole 1.2. Položky jsou
organizovány do hierarchické struktury zvané Directory Information Tree (DIT).
Každá položka je jednoznačně identifikována jménem (DN), přičemž toto jméno
jednoznačně určuje polohu položky v rámci stromu.
14
1.7
Funkční model
Standardní operace protokolu LDAP lze rozdělit do tří kategorií:
Dotazování a prohledávání – slouží pro získávání informací z adresářového
stromu. Operace search a compare.
Změny dat – operace add, delete, modify (modifyRDN). Základní prostředky
pro změnu dat.
Autentizace – navázání spojení a prokázání identity uživatele. Operace
bind a unbind.
1.7.1
Operace search
Pro realizaci veškerého přístupu k datům (čtení) v adresářovém serveru slouží
jediná operace, prohledávání. Tato operace je navržena obecně, tj. pokryje jak
potřebu hledání, tak čtení přesně specifikovaných dat.
Specifikace požadavku pro operaci search se definuje prostřednictvím několika
základních parametrů:
Báze
Rozlišovací jméno definující nejvyšší objekt v hierarchii DIT, který je prohledáván.
Rozsah
Specifikuje rozsah prohledávání vzhledem k bázovému objektu. Lze požadovat prohledání celého podstromu, jedné úrovně podstromu či pouze
bázového objektu samého.
Prohledávací filtr
Pro definici kritéria pro výběr vyhovujících položek existuje relativně
komplexní syntaxe a sémantika tzv. prohledávacího filtru.
Základní syntaxe filtru je:
<atribut> <operátor> <hodnota>
kde nejjednodušším operátorem je rovnítko, například sn=Sitera. Filtry
lze skládat pomocí logických operací. Syntaxe je:
( <operátor> (<filtr>) (<filtr>) (<filtr>) ...)
například (& (ou=civ)(mail=si*)), kde & je operátor logického součinu a * zástupný znak pro libovolný řetězec. Pak tedy tento příklad
definuje prohledávací filtr, jemuž vyhovují všechny položky mající atribut
15
ou s hodnotou civ a atribut mail s hodnotou, která začíná znaky si.
Podrobnější informace o syntaxi filtru viz [rfc2254].
Atributy k vyzvednutí
Je možno omezit množinu atributů, které jsou z hlediska konkrétního
dotazu zajímavé.
Limity
Klient může omezit maximální počet položek vrácených dotazem nebo
maximální objem času který je možno věnovat na zodpovězení dotazu. To
je užitečná vlastnost v případě dotazů, u kterých není z hlediska klienta
jasná informace o objemu položek, které splňují kritéria dotazu.
1.7.2
Operace compare
Operace compare slouží speciálně pro porovnání hodnoty atributu konkrétní
položky se zadanou hodnotou. Vrací logickou hodnotu.
1.7.3
Operace pro změnu dat
Operace pro změnu dat:
add: Vytvoření nové položky.
delete: Zrušení existující položky. Mohou být smazány pouze položky, které
jsou listy stromu (tj. pokud neexistují žádné položky umístěné v podstromu mazané položky).
modify: Slouží ke změnám uvnitř existující položky. Dovoluje měnit hodnotu
atributu, mazat atribut a přidávat nový atribut.
modifyRDN: Slouží ke změně rozlišovacího jména položky. Dovoluje změnit
pouze relativní rozlišovací jméno v rámci větve, ve které je položka umístěna.
1.7.4
Autentizační operace
Operace pro navázání a řízení komunikace:
bind: Navázání spojení mezi LDAP serverem a klientem. Při navázání spojení
probíhá autentizace.
unbind: Zrušení spojení mezi LDAP serverem a klientem.
abandon: Operace, kterou klient požaduje zrušení nedokončené (předchozí)
operace.
16
Vlastní autentizace může být provedena několika standardními mechanismy.
Více viz kapitola 1.8.
1.7.5
Možnosti rozšíření funkčního modelu
Také funkčního model je navržen jako rozšiřitelný. Jednak je možno definovat
tzv. controls, což jsou dodatečná rozšíření standardních operací, jednak je možno
definovat zcela nové operace (extended operations).
LDAP – funkční model
Prohledávání – obecně definovaná operace search.
Změna dat, na úrovni položek a na úrovni atributů.
Otevřený návrh, rozšiřitelnost.
1.8
Bezpečnostní model
Z hlediska bezpečnosti lze v rámci protokolu LDAP hovořit především o autentizaci uživatele, tj. metodě prokázání identity (a tím vazbě uživatele na položku
která ho reprezentuje v adresářovém stromu), o bezpečnosti obecně (zabezpečení proti odposlechu a napadení komunikace) a o autorizaci (řízení přístupových práv k jednotlivým objektům a operacím nad nimi).
Autorizace není dosud součástí žádného přijatého standardu. Existuje řada
řešení (obvykle formou přístupových listů, např. Netscape [NS-doc]) a návrh
standardu.
1.8.1
Autentizace
Z hlediska prokázání identity uživatele (autentizace) lze v současných adresářových službách mluvit o třech základních možnostech:
Žádná autentizace
Nejjednodušší přístup, určený obvykle pouze pro čtení veřejných položek,
je anonymní. V tomto případě není potřeba provádět žádnou autentizaci.
Základní autentizace
Jednoduchá metoda prokázání identity uživatele. Klient specifikuje DN
uživatele a jeho heslo. Heslo je uloženo (obvykle přes jednosměrnou
šifru) v atributu příslušné adresářové položky.
SASL (Simple Authentication and Security Layer)
SASL (Simple Authentication and Security Layer) je standardizovaná ([rfc2222])
17
cesta pro dodatečné zabezpečení spojově orientovaných komunikačních
protokolů. Jedná se v podstatě o jasně definované rozhraní, jehož prostřednictvím lze propojovat standardní autentizační mechanismy s komunikačními protokoly. Podpora SASL je novou vlastností standardu LDAP
verze 3.
Základní schéma použití SASL autentizace je následující:
1. Klient předá informace pro autentizaci:
– DN – rozlišovací jméno entity, která se autentizuje.
– mechanismus – identifikace SASL autentizačního mechanismu.
Server může prostřednictvím SASL podporovat několik autentizačních mechanismů7 . Běžně podporovaným autentizačním mechanismem je SSL (nebo jeho následník TLS - viz kapitola 1.8.2)8,
přičemž tyto protokoly poskytují také zabezpečení komunikace.
– credentials – data prokazující identitu (v příslušném autentizačním mechanismu).
2. Přes LDAP API dojde autentizační požadavek LDAP serveru, který
pro jeho vyřízení použije příslušný autentizační modul (dle zadaného mechanismu).
3. Příslušný autentizační modul na základě předaných dat rozhodne,
zda je identita prokázána či nikoli. Za tímto bodem se může skrývat
další komunikace vlastní autentizačnímu mechanismu (např. Kerberos).
1.8.2
Zabezpečení komunikace
Protokol SSL (Secure Socket Layer) je určen jak pro zabezpečení komunikace
tak pro provádění autentizace komunikujících entit. Slouží primárně pro zabezpečení TCP/IP komunikace – jako mezivrstva mezi aplikací a běžnou TCP/IP
komunikační abstrakcí (sokety). Další informace o protokolu SSL a TLS (Transport Layer Security) přesahují rámec tohoto dokumentu. Lze pouze doporučit
některé základní informační zdroje [ssl, rfc2246, tls].
LDAP – bezpečnostní model
Autentikace – prokázání identity uživatele, vazba na objekt v adresářových
službách.
7
Samozřejmě server musí podporovat klientem použitý autentizační mechanismus, jinak
nemůže autentizace uspět. Podporované autentizační mechanismy lze získat standardizovaným
LDAP dotazem.
8
Mezi jiné možné autentizační mechanismy patří: Kerberos, S/Key, GSSAPI ([rfc2078]),
CRAM-MD5.
18
Zabezpečení – komunikace, odolnost proti napadení.
Autorizace – řízení přístupu.
1.9
LDIF
LDIF (LDAP Interchange Format) [ldif] je textový formát pro zápis obsahu adresářových služeb. Slouží také jako prostředek pro zápis operací pro změnu obsahu
adresářových položek. LDIF se používá především pro hromadné změny dat,
import a export dat (přenos ze serveru na server) apod. LDIF také využívají
nástroje pro komunikaci s LDAP serverem z příkazové řádky.
V této kapitole lze najít základní nástin formátu LDIF, další informace viz doporučená literatura.
1.9.1
LDIF – formát pro zápis adresářových položek
Popišme použití formátu LDIF pro zápis adresářových položek.
LDIF soubor se skládá z bloků dat oddělených prázdnou řádkou. Každý blok
dat reprezentuje jednu položku. Základní struktura:
dn: <rozlišovací jméno> objectClass: <třída objektu> ... <jméno atributu>: <hodnota atributu> ...
Atribut objectClass je z hlediska formátu LDIF atribut jako každý jiný, jeho
zvýraznění ve výše uvedené struktuře slouží pouze k přiblížení obvyklého
vzhledu LDIF formátu položky.
Příklad položky:
dn: cn=Jiri Sitera, ou=CIV, ou=Staff, ou=People, o=zcu, c=cz objectClass: top objectClass: organizationalPerson objectClass: inetOrgPerson cn: Jiri Sitera sn: Sitera mail: [email protected] seeAlso: http://home.zcu.cz/ sitera l: UI404
1.9.2
LDIF – formát pro zápis změn adresářových položek
Způsob zápisu příkazů pro modifikaci položek v adresářových službách je popsán v kapitole 1.10.2.
LDIF
Standardní textový formát pro zápis dat v adresářových službách.
Slouží také pro zápis příkazů pro modifikaci dat v adresářových službách.
Pro hromadné změny dat, export a import databáze adresářového serveru.
19
1.10
Nástroje pro komunikaci s LDAP serverem z příkazové
řádky
Nástroje pro komunikaci s LDAP serverem z příkazové řádky jsou obvykle
součástí prostředků pro tvorbu aplikací, často označovaných jako SDK (Software
Development Kit). Nicméně v hlavních rysech jsou zcela kompatibilní. Základní
použití těchto nástrojů je nastíněno v následujících odstavcích. Více informací
viz příslušná dokumentace, např. [NS-admin].
1.10.1
Prohledávání adresářového stromu – ldapsearch
Funkce ldapsearch odpovídá operaci search LDAP funkčního modelu. Základní použití:
ldapsearch -h <LDAP server> -b <báze> <prohledávací
filtr>
například:
ldapsearch -h pleiades.zcu.cz -b ’o=zcu,c=cz’ ’sn=sitera’
Dále lze parametry prohledávání určit především:
seznam atributů, jejichž hodnoty mají být vráceny,
rozsah prohledávání,
port na kterém je LDAP server (implicitně 389),
limity,
autentizační data (jednoduchá autentizace, tj. DN a heslo),
zabezpečení a autentizaci, obvykle se používá SSL.
1.10.2
Modifikace položek adresářového stromu – ldapmodify, ldapdelete,
ldapmodrdn
Příkaz ldapmodify používá pro zadávání požadavků na modifikaci adresářových položek tzv. LDIF update formát. Základní syntaxe je:
dn: <rozlišovací jméno> changetype: <typ změny> <bližší specifikace
změny> <seznam atributů> ... - <bližší specifikace změny> <seznam
atributů> ...
20
Například pro provádění základních změn uvnitř položky se užívá specifikace
changetype:modify, přičemž bližší specifikace změny může být:
add: <jméno atributu> – přidá specifikovaný atribut a jeho hodnotu do
položky. Existuje-li již takový atribut, přidá mu další hodnotu. Například:
dn: cn=Jiri Sitera, ou=CIV, ou=Staff, ou=People, o=zcu, c=cz changetype: modify add: telephoneNumber telephoneNumber: 580
delete: <jméno atributu> – smaže specifikovaný atribut z položky.
Pokud má specifikovaný atribut více hodnot, smaže všechny. Je-li potřeba
smazat pouze jednu hodnotu a ostatní ponechat, je možno ke jménu
atributu připsat hodnotu, která se má smazat.
replace: <jméno atributu> – slouží k obecné modifikaci atributu –
zadáním cílového stavu, tj. neexistuje-li atribut, je vytvořen a není-li specifikována žádná nová hodnota, tak je případný původní atribut smazán.
Další typy změny jsou: add, delete a modrdn. Takto lze pomocí příkazu ldapmodify
a příslušného LDIF vstupu zakládat, mazat a přejmenovávat položky.
Přidání nových položek lze také realizovat na základě běžného LDIF souboru
popisujícího tyto položky. K tomu slouží přepínač -a příkazu ldapmodify – poté
je operace add implicitní. Smazání položky je možno také realizovat příkazem
ldapdelete.
Poznamenejme ještě, že při operacích, které mění data v adresářovém serveru,
je potřeba použít autentizaci a pravděpodobně také zabezpečení komunikace
(SSL).
2
LDAP – Co dále?
Vzhledem k rozsahu tohoto dokumentu není možno pokročilejší a praktičtější
otázky probírat podrobně. Proto se tato kapitola snaží poskytnout stručnou
formou základy pro praktickou práci s adresářovými službami, jmenovitě protokolem LDAP a pro studium informací z této oblasti, které sami o sobě překračují
rámec tohoto dokumentu.
2.1
2.1.1
Některé další důležité vlastnosti protokolu LDAP
LDAP URL
V rámci snah o standardizaci protokolu LDAP a využití adresářových služeb
jako jednotné informační infrastruktury byl navržen URL (Universal Resource
21
Locators) [url] formát pro přístup k LDAP službám. LDAP URL je přijatým standardem [rfc2255] a podporuje ho řada aplikací (například Netscape Navigator
4.0).
Základní syntaxe LDAP URL:
ldap://<host>:[<port>] [/ [<dn>[? [<atributy>] [? [<rozsah>] [? [<filtr>]]]]]]
kde:
ldap: Specifikuje protokol LDAP. Může zde být také ldaps což určuje použití
protokolu LDAP přes SSL (implicitní port 636).
host: Jméno LDAP serveru.
port: TCP/IP port na kterém je přítomen server.
dn: Rozlišovací jméno určující bázi pro hledání.
atributy: Seznam atributů, které mají být získány.
rozsah: Rozsah hledání. base, one nebo sub. Implicitní je base.
filtr: Filtr pro hledání. Implicitní je objectClass=*
Příklad použití LDAP URL pro dotaz:
ldap://pleiades.zcu.cz/o=zcu,c=cz??sub?sn=sitera
LDAP URL je velmi flexibilní – může vyjadřovat odkaz na LDAP server, odkaz
na položku v adresářových službách nebo LDAP dotaz. LDAP URL lze také
s výhodou používat pro specifikaci dotazů v aplikacích.
2.1.2
Odkazy
LDAP server nemusí obsahovat celý adresářový strom. Tento strom může být
rozprostřen mezi hierarchicky uspořádané servery. Každý server obsahuje jeden podstrom9 a některé položky mohou reprezentovat odkaz, tzv. referal. Tímto
způsobem jsou jednotlivé servery, a části dat v nich umístěné, propojeny. Kořenová položka podstromu se nazývá suffix, neboť její název je vždy sufixem
rozlišovacích jmen všech položek v podstromu se nacházejících.
Odkaz (referal) je speciální položka (objectClass=referal), jež slouží jako ukazatel
na server, který obsahuje příslušný podstrom. Pro zápis odkazu se používá
atribut ref a LDAP URL.
9
Ve skutečnosti může LDAP server obsahovat několik podstromů.
22
Více informací o odkazech viz doporučená LDAP literatura a dokumentace k
příslušnému vývojovému nástroji (většina implementací LDAP API poskytuje
transparentní vyhodnocování odkazů).
2.1.3
Replikace
Z hlediska návrhu implementace adresářových služeb je samozřejmě důležitým
faktorem dostupnost a rozšiřitelnost („škálovatelnost“). První z mechanismů pro
zajištění robustnosti infrastruktury LDAP služeb, členění na části (partitioning),
je realizováno výše popsaným mechanismem odkazů. Data jsou rozdělena do
hierarchicky uspořádaných částí, přičemž každá část je poskytována samostatnými prostředky.
Druhým mechanismem je replikace. Adresářový server může mít několik replik,
tj. serverů, které poskytují stejná data. Datový obsah je mezi replikami udržován konzistentní a je zajištěna základní funkce systému i v případě výpadku
některého ze serverů.
Více informací opět viz příslušná dokumentace, např. [NS-doc], [UMICH-doc].
2.2
Kostra základního nasazení adresářových služeb
Nastiňme nyní, které základní kroky je třeba provést v rámci nasazení adresářových služeb. Předpokládejme základní nasazení, tj. jako seznam lidí s informacemi o nich. Mezi takové informace patří především telefon, fax, kancelář,
příslušnost organizační jednotce, e-mail, atd. Mezi funkce může patřit telefonní
seznam s vazbou na běžné aplikace (e-mail, ...).
Server – výběr a instalace serverového SW. Obvykle je k dispozici dokumentace s informacemi nejen o instalaci, ale i konfiguraci a návrhu
adresářových služeb. Patří sem samozřejmě návrh fyzické infrastruktury,
tj. především otázky replikace a rozčlenění dat. To je samozřejmě již úzce
vázáno na návrh DIT. Pravděpodobně nejlepší cesta pro většinu případů
je učinit základní návrh a postupovat dále dle naznačeného schématu,
přičemž celek bude sloužit jako ověřovací implementace a v rámci posledního kroku se navrhnou změny vedoucí k nasazení do produkčního
prostředí.
Schéma – volba, respektive návrh informačního modelu. V našem případě
nejspíše vybereme některou ze standardních tříd objektů. Pro realizaci objektů pro uživatele se hodí organizationalPerson či inetOrgPerson.
Je samozřejmě třeba navrhnout DIT a realizovat jeho uzly. K tomu se hodí
třída objektů organization a organizationalUnit.
23
Klient – je třeba navrhnout základní využití adresářových služeb. V první
fázi postačí nástroje pro komunikaci s LDAP serverem z příkazové řádky
a standardní aplikace (mail klient, WEBový prohlížeč). Je možné vybrat si
a vyzkoušet některý z pokročilejších nástrojů, jako je WWW–LDAP brána
(gateway) či samostatný LDAP prohlížeč (browser).
Rozhraní – nástroje, synchronizace, migrace dat – jedním z důležitých
kroků je samozřejmě naplnění daty. Po prvních pokusech s testovacími
daty bude nutno navrhnout mechanismy pro získání reálných dat. Samozřejmě, že zde se dotýkáme velmi komplexního problému, který se často
označuje pojmem metadirectory – integrace existujících zdrojů dat, resp.
přechod na jednotnou bázi dat. Zde bude potřeba stanovit postupy a navrhnout nástroje pro synchronizaci dat, resp. pro jejich migraci. Existuje
řada postupů a nástrojů v této oblasti10 . Mezi nejjednodušší začátek patří
transformace dat z existujících systémů do formátu LDIF a import tohoto
souboru.
Konfigurace aplikací – viz dokumentace příslušných aplikací. Velmi mnoho
současných e-mail klientů podporuje LDAP pro získávání e-mail adres lidí
(viz například Netscape Communicator Mail).
Údržba, restrukturalizace pro nasazení do produkčního prostředí
2.3
Hlavní implementace
Jmenujme nyní, bez nároku na úplnost a správnost výběru, několik základních
implementací LDAP serveru a souvisejících věcí.
University of Michigan LDAP implementace – tato práce otevřela svět
LDAPu tak, jak je nastíněn v tomto dokumentu. Je k dispozici standalone
LDAP directory server (slapd), standalone LDAP update replication daemon
(slurpd), front end for an X.500 DSA a mnoho vývojových nástrojů. Vše je
k dispozici volně včetně zdrojových textů [UMICH].
Netscape Communications – dobře podporovaná rozvíjející se technologie
LDAPu. Adresářový server s modulární architekturou, podporou LDAPv3
a mnoha rozšířeními (autorizace, schéma, integrace s ostatními produkty).
Jsou k dispozici nástroje pro tvorbu aplikací (C SDK, Java SDK, modul pro
Perl – PerLDAP). Nástroje pro tvorbu aplikací jsou k dispozici včetně
zdrojových textů zdarma, server je komerční [NS-LDAPCentral].
10
V této oblasti lze najít řadu komerčních (více či méně komplexních) řešení. Je také třeba si
uvědomit, že s tímto úsilím souvisí práce s vlastním obsahem dat, často označovaná (po právu)
termínem „konsolidace dat“.
24
OpenLDAP – projekt OpenLDAP, vývoj LDAP technologie na otevřené
bázi, vychází z implementace University of Michigan. Rychle se rozvíjející
projekt, server i vývojové nástroje volně šířené včetně zdrojových textů
[openldap].
2.4
Vývojové nástroje
Kromě knihoven SDK pro C a Javu, které jsou součástí mnoha implementací
LDAPu, stojí za alespoň stručnou zmínku především:
Java Naming and Directory Interface (JNDI) – rozhraní pro tvorbu aplikací
v jazyce Java. Jedná se o zobecněné rozhraní k jmenným a adresářovým
službám, které dovoluje jednotné zacházení se souborovým systémem,
DNS a LDAPem. JNDI je navrženo jako otevřené vzhledem k dalším jmenným službám. Oproti LDAP Java SDK poskytuje abstrakci vyšší úrovně.
Více viz [JNDI].
PerLDAP – knihovna pro programovací jazyk Perl, která poskytuje objektově orientované rozhraní pro práci s adresářovými službami [perldap].
2.5
Kde hledat další informace a zkušenosti
Možností je mnoho. Uveďme několik základních vstupních bodů.
Innosoft’s LDAP World, dříve Critical Angle. Mnoho informací a odkazů
udržovaných Markem Wahlem, autorem UMICH LDAPu.
http://www3.innosoft.com/ldapworld
An LDAP Roadmap & FAQ, Kings Mountain Systems, udržuje Jeff Hodges,
Stanford. http://www.KingsMountain.com/ldapRoadmap.shtml
Reference
[rfc2222]
RFC 2222, Simple Authentication and Security Layer (SASL).
[rfc2251]
Wahl, M., Howes, T., Kille, S., Lightweight Directory Access Protocol
(v3), RFC 2251, Critical Angle, Inc., ISODE Consortium, Netscape
Communications Corp., July, 1997.
[rfc2252]
Wahl, M., Coulbeck, A., Howes, T. and S. Kille, Lightweight Directory
Access Protocol (v3): Attribute Syntax Definitions, RFC 2252, December 1997.
25
[rfc2253]
Wahl, M., Kille, S., and T. Howes, Lightweight Directory Access Protocol
(v3): UTF-8 String Representation of Distinguished Names, RFC 2253,
December 1997.
[rfc2254]
T. Howes, Lightweight Directory Access Protocol (v3): The String Representation of LDAP Search Filters, RFC 2254, December 1997.
[rfc2255]
T. Howes, M. Smith, The LDAP URL Format, RFC 2255, December
1997.
[rfc2256]
RFC 2256, A Summary of the X.500: User Schema for use with LDAPv3.
[rfc2078]
RFC 2078, Generic Security Service Application Program Interface.
[DITDesign] Jim Rommel, Perot System Corporation: DIT Design. Electronic
Messaging Association Conference 1998.
[DNSAit]
Jiří Sitera: Administrace TCP/IP sítí v prostředí OS UNIX. Akademie
informačních technologií ZČU Plzeň, materiály pro posluchače, 1998.
[ssl]
Netscape Communications, The SSL Protocol Version 3.0, Secure
Sockets Layer, Internet–Draft,
http://home.netscape.com/eng/ssl3
[rfc2246]
RFC 2246, The TLS Protocol Version 1.0,Transport Layer Security protocol.
[tls]
LDAPExt Working Group, Lightweight Directory Access Protocol (v3):
Extension for Transport Layer Security, Internet–Draft,
draft-ietf-ldapext-ldapv3-tls-04.txt
[ldif]
Gordon Good, Netscape Communications, The LDAP Data Interchange Format (LDIF) - Technical Specification, Internet–Draft,
draft-good-ldap-ldif-02.txt
[UMICH-doc] University of Michigan, The SLAPD and SLURPD Administrator’s
Guide,
http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd
[UMICH]
University of Michigan, Lightweight Directory Access Protocol,
http://www.umich.edu/~dirsvcs/ldap/
[openldap] The OpenLDAP Project, Open source suite of LDAP applications and
development tools, http://www.openldap.org
[NS-admin] Netscape Communications, Netscape Directory Server 3.0 Administrator’s Guide,
http://developer.netscape.com/docs/manuals/directory/
admin30/
26
[NS-deploy] Netscape Communications, Netscape Directory Server 3.0 Deployment Guide,
http://developer.netscape.com/docs/manuals/directory/
deploy30/
[NS-doc]
Netscape Communications, Netscape Directory Server Documentation,
http://developer.netscape.com/docs/manuals/directory.html
[NS-LDAPCentral] Netscape Communications, Directory Developer Central,
http://developer.netscape.com/tech/directory
[perldap] Netscape Communications, PerLDAP Central,
http://developer.netscape.com/tech/directory/
perldap central.html
[X.500]
Recommendations X.500, OSI Directory Standard,
http://www.nexor.com/public/directory.html
[url]
[JNDI]
Berners-Lee, T., Masinter, L. and M. McCahill, Uniform Resource Locators (URL), RFC 1738, December 1994.
Java Naming and Directory Interface (JNDI), Java Standard Extension
http://www.javasoft.com/products/jndi
27

Adresářové služby – úvod do problematiky

Transkript

Podobné dokumenty

Kvalita OK.p65