UNIVERZITET U BEOGRADU

FAKULTET ORGANIZACIONIH NAUKA

PRIMENA LDAP PROTOKOLA

U DISTRIBUIRANIM RAUNARSKIM SISTEMIMA

DIPLOMSKI RAD

Mentor:

Student:

Prof. dr Boidar Radenkovi

Marijana Despotovi

BEOGRAD, 2001.
1

SADRAJ
1. Uvod

2. Distribuirano raunarsko okruenje

2.1
2.2

Lightweight Directory Access Protocol (LDAP)

Lightweight pristup X.500

3. LDAP direktorijumski server

3.1 Arhitektura LDAP protokola

3.2 Funkcionisanje LDAP protokola
3.2.1 Operacije LDAP protokola
3.3 Modeli opisa LDAP direktorijuma
3.3.1 Informacioni model
3.3.2 Model imenovanja
3.3.3 Funkcionalni model
3.3.4 Model bezbednosti
3.4 LDAP URL-ovi
4. Primena LDAP protokola u raunarskoj mrei FON-a

4.1 Opis raunarske mree FON-a

4.2 Primena LDAP protokola za autentifikaciju i autorizaciju
u raunarskoj mrei FON-a
4.3 Aplikacija za auriranje baze podataka LDAP servera

3
3
4
5
5
7
9
9
10
13
14
15
16
16
19
23

Zakljuak

30

Literatura

31

Prilog 1. Izgled ekrana aplikacije za auriranje LDAP baze podataka

32

1. UVOD
Intenzivan razvoj raunarske i komunikacione tehnologije uslovio je globalizaciju poslovnih
procesa i trita. Preduzea u cilju opstanka na tritu, moraju da postanu deo globalnih
poslovnih procesa to zahteva poslovanje u raunarski informatizovanom okruenju.
Koncepcija savremenog poslovanja podrazumeva spoljanju i unutranju integraciju, koja
treba da omogui lako komuniciranje preko raunarske mree.
U takvom raunarskom okruenju, dosadanji pristup da se autentifikacija i autorizacija
vri na svakoj lokalnoj maini pojedinano, se pokazao neefikasan.
Za reavanje ovih problema Open Systems Group je u okviru inicijative za definiciju
standarda za distriubuirano raunarsko okruenje predloila standard X.500 za opis
distribuiranih raunarskih sistema u formi direktorijuma. U praksi se ovaj standard
pokazao neefikasan, tako da se devedesetih godina na Internetu pojavila redukovana
verzija ovog standarda pod nazivom Light Weight Directory Access Protokol (LDAP). U
okviru ovog standarda su razvijeni mehanimi za opis veine objekata koji se mogu pojaviti
u informacionim sistemima velikih multinacionalnih korporacija. Zahvaljujui brzom razvoju
Interneta i besplatnoj implementaciji LDAP protokola (openldap.org) LDAP je danas
defacto standard za opis objekata distribuiranih sistema. LDAP ve godinama koristi
Novell a od verzije MS Windows 2000 Active Directory je postao standard i za Microsoft
proizvode.
U raunarskoj mrei FON-a postoji stotinak raunara i vie desetina tampaa i servera.
Raunarsku mreu koriste oko 150 nastavnika i saradnika i oko 4000 studenata.
Administracija ovakve mree se moe efikasno realizovati samo uz pomo LDAP
protokola i odgovarajue baze podataka o nastavnicima, saradnicima, studentima,
raunarskim resursima i pristupnim pravima.
U okviru ovog diplomskog rada, pored osnovnih teorijskih koncepata funkcionisanja LDAP
protokola bie opisana koncepcija upravljanja resursima raunarske mree FON-a,
definisani osnovni elementi za specifikaciju baze podataka, konfigurisanje LDAP servera i
kljenata.
Za administraciju baze podataka se na FON-u razvija aplikacija u programskom jeziku
JAVA koja omoguava da se iz web okruenja realizuju svi administratorski poslovi vezani
za prava pristupa i servise mree.
U okviru ovog diplomskog rada bie prikazan deo ove aplikacije koji se odnosi na
administraciju korisnikih imena, lozinki i e-mail naloga za nastavnike, saradnike i
studente.

2. DISTRIBUIRANO RAUNARSKO OKRUENJE (DCE)

Distribuirano raunarsko okruenje (DCE - Distribuited computing environment ) je
definisala organizacija Open Systems Foundation (danas poznate pod nazivom Open
Group). Open Group je nastala iz potrebe za saradnjom proizvoaa hardvera, softvera,
kupaca i konsalting firmi, sa ciljem pruanja podrke istraivanju, razvoju i isporuci
tehnologije raznih proizvoaa i industrijskih standarda.

Slika 1. Komponente DCE Arhitekture

Kao to je prikazano na slici 1. DCE obuhvata sledee glavne servise:

Servis direktorijuma (Directory Service)

Servis bezbednosti (Security Service)
Servis distribuiranog vremena (Distributed Time Service)
Servis distribuiranih datoteka (Distributed File Service)
Niti (Threads)
Daljinski poziv procedure (Remote Procedure Call RPC)

Navedeni servisi u okviru operativnih sistema imaju API e koji dozvoljavaju programeru
da koristi ove funkcije u svojim aplikacijama.
Predmet ovog diplomskog rada je servis direktorijuma LDAP i njegova primena u
raunarskoj mrei FON-a.

2.1 Lightweight Directory Access Protocol (LDAP)

Mreno-bazirane aplikacije koje danas postoje se oslanjaju na sopstvene direktorijume (ili
baze podataka) koje sadre informacije koje opisuju razliite korisnike, aplikacije, fajlove i
druge resurse dostupne preko mree.
Npr. Kompanija moe imati jedan direktorijum u kojem se nalaze informacije o svim
korisnicima i delovi za njihov e-mail sistem. Broj razliitih mrea i aplikacija je daleko vei,
broj specijalizovanih informacionih direktorijuma je takoe porastao, rezultirajui ostrvima
informacija koje se ne mogu deliti i teko ih je sauvati. Ako se sve ove informacije mogu
sauvati u postojanom i kontrolisanom nainu, obezbedie se ia za integrisanje
distribuiranog okruenja u odrive i neograniene sisteme.
Lightweight Directory Access Protocol (LDAP) je otvoren industrijski standard koji je
razvijen da zadovolji ove potrebe. LDAP definie standardni metod za pristup i auriranje
informacija u direktorijumu. LDAP dobija veliku odgovornost kao metod pristupa
direktorijumu na Internetu i on je stoga privlana strategija unutar korporativnih intraneta.
On postaje podran od strane rastueg broja softverskih proizvoaa i biva inkorporisan u
rastui broj aplikacija.

2. 2 Lightweight pristup X.500

OSI direktorijumski standard, X.500, specificira komunikaciju izmeu klijenta direktorijuma
i servera, upotrebom Direktorijumskog Pristupnog Protokola (DAP). Aplikacioni protokol,
DAP zahteva za svoj rad ceo stek OSI protokola. Podrka steku OSI protokola zahteva
vie resursa nego to je raspoloivo na veini dananjih raunara.
LDAP je razvijen kao lightweight alternativa DAP-u. LDAP
popularnom TCP/IP protokolu.

svoj rad zasniva na

Prva verzija LDAP-a je definisana u RFC 1487 X.500 Lighweight Access, koji je zamenjen
sa RFC 1777 Lighweight Directory Access Protocol.
LDAP verzija 2 je dosegla status formalizovanog standarda u IETF standardima. Vei broj
proizvoaa softvera je implementirao proizvode koji podravaju LDAP verziju 2. Neki
proizvoai su takoe implementirali proizvode koji podravaju sve ili delove LDAP verzije
3. LDAP verzija 3 je definisana pomou RFC 2251 Lightweight Directory Access Protocol
(v3).
LDAP definie komunikacioni protokol izmeu direktorijumskog klijenta i servera, ali ne
definie programirajui interfejs za klijenta. RFC 1823 The LDAP Application Program
Interface definie C jezik API za pristup direktorijumu upotrebom LDAP verzije 2. Ovo je
samo informativni RFC, ali je de-facto postao standardan. Standardizovani protokoli i
raspoloivost opteg API na razliitim platformama je glavni razlog za iroko prihvatanje
LDAP-a.

3. LDAP DIREKTORIJUMSKI SERVER

LDAP je komunikacioni protokol koji definie prenos i format poruke koju koristi klijent da
pristupi podacima na serveru. LDAP ne definie sam direktorijumski servis. Aplikacioni
program (LDAPklijent ) alje LDAP poruke pozivom LDAP API. Meutim u eksploataciji
moe nastati problem jer X.500 server direktorijuma ne razume LDAP poruke jer LDAP
klijent i X.500 server ak koriste razliite komunikacione protokole (TCP/IP tj. OSI).
LDAP klijent komunicira sa proxy ili front end servisom koji prosleuje zahteve X.500
direktorijumskom serveru (slika 2). Ovaj proxy je u literaturi poznat kao LDAP server.

Slika 2. Komunikacija LDAP servera sa X.500 serverom

LDAP server servisira zahteve LDAP klijenta. To radi tako to postaje klijent X.500
servera. Kako je porasla upotreba LDAP-a i njegove beneficije postale oigledne, ljudi koji
nisu imali X.500 server ili okruenja za njegovu podrku hteli su da naprave direktorijume
kojima e LDAP klijenti moi pristupiti. Ovo je zahtevalo da LDAP server mora uvati i
pristupati samom direktorijumu umesto da radi kao prolaz do X.500 servera (vidi sliku 3).
Ovo otklanja bilo kakvu potrebu za stekom OSI protokola ali, naravno, ini LDAP server
mnogo komplikovanijim poto mora da skladiti i vraa direktorijumske slogove. Ovakvi
LDAP serveri se esto zovu samostalni LDAP serveri jer ne zavise od X.500
direktorijumskog servera.

Slika 3. Pristup LDAP servera lokalnoj bazi direktorijuma

Koncept LDAP servera koji obezbeuje pristup lokalnoj bazi podataka direktorijuma je
uveden u RFC 2251 (LDAP verzija 3). Sa take gledita klijenta, svaki server koji izvrava
LDAP protokol je LDAP direktorijumski server, bilo da server aktivno implementira
direktorijum ili je prolaz do X.500 servera. Direktorijum kome je pristupljeno se moe zvati
LDAP direktorijum, bilo da je direktorijum implementiran preko samostalnog LDAP servera
ili preko X.500 servera.

3.1 Arhitektura LDAP protokola

LDAP definie poruke izmeu LDAP klijenta i LDAP servera. Poruke predstavljaju
operacije koje zahteva klijent (pretrai, modifikuj, obrii i tako dalje), odzive servera, i
format poruka. Poruke se prenose preko TCP/IP protokola.
Interakcija izmeu LDAP klijenta i LDAP servera ima sledeu formu:

Klijent uspostavlja sesiju sa LDAP serverom. Ovo je poznato kao operacija spajanja na
server. Klijent specificira ime ili IP adresu i TCP/IP broj porta servera. Klijent se moe
identifikovati korisnikim imenom i lozinkom ili uspostavlja anonimnu sesiju sa optim
pravom pristupa. Klijent i server mogu takoe uspostaviti sesiju koja koristi metode
zatite i ifrovanje podataka.
Klijent tada izvrava zadate operacije nad podacima direktorijuma. LDAP omoguava
itanje i auriranje baze podataka. Klijent moe da informacijama direktorijuma
upravlja isto tako dobro kao to ih pretrauje. LDAP podrava pretraivanje
direktorijuma za podacima koji zadovoljavaju proizvoljno korisniko-specificiran
kriterijum. Pretraivanje je najoptija operacija u LDAP. Korisnik moe specificirati koji
deo direktorijuma pretraivati i koje informacije vratiti. Filter pretraivanja koji koristi
Boolean uslove specificira koji podaci direktorijuma odgovaraju pratrazi.
Kada klijent zavri sa zahtevima, zatvara sesiju sa serverom. Ovo je takoe poznato
kao odvezivanje.

Poto je LDAP orginalno bio namenjen kao lightweight alternativa DAP-u za pristupanje
X.500 direktorijumima, LDAP server prati X.500 model. Direktorijum skladiti i organizuje
strukture podataka poznatih kao slogovi. Direktorijumski slogovi obino opisuju objekat
kao to je osoba, tampa, server, i tako dalje. Svaki slog ima ime poznato kao osobito
ime (distinguished name DN) koje ga jedinstveno identifikuje. DN se sastoji od niza
delova koji su poznati kao relativna osobita imena (relative DN RDN), slino kao to
imena fajlova se sastoje od puta imena direktorijuma u mnogim operativnim sistemima
kao to su UNIX i OS/2. Slogovi mogu biti ureeni u hijerarhijsku strukturu, kao drvo,
baziranoj na njegovim osobitim imenima. Ovo drvo direktorijumskih slogova se zove
stablo direktorijumskih informacija (directory information tree DIT).
LDAP definie operacije za pristupanje i auriranje direktorijumskih podataka kao to su:
Pretraivanje podataka koji zadovoljavaju proizvoljno specificiran kriterijum
Dodavanje podataka
Brisanje podataka
Modifikovanje podataka
Modifikovanje osobnih imena ili relativnih osobnih imena u slogu
Poreenje podataka

3.2 Funkcionisanje LDAP protokola

Klient-server je model komunikacije u kome klijent program na jednom kompjuteru kreira
zahtev i alje ga preko mree serveru. Server prima zahteve, izvrava odreene akcije i
vraa rezultate klijentu.
Npr. Klijent- server je Hypertext Transfer Protocol (HTTP) koji se koristi za Web strane; i
Internet Message Accsess Protocol (IMAP), koji se koristi da se pristupi elektronskoj poti.
7

Npr. Tipini LDAP server treba da ima dosta RAM memorije koju koristi za bri pristup
sadrajima direktorijuma. Takoe treba da ima i velike diskove, procesore velike brzine.
Klijent raunar treba da bude prilagoen poslu koji e se obavljati.

Slika 4. Operacija pretraivanja LDAP servera

Ako klijent trai direktorijum i pronae se vie odgovarajuih podataka, podaci se alju
klijentu u vie LDAP poruka, po jedna za svaki podatak. Rezultati se potvruju porukom
koja sadri ukupne rezultate pretrage (Slika 5.)

Slika 5. Pretraivanje direktorijuma sa vraanjem viestrukih podataka

LDAP protokol omoguava klijentu da uputi viestruki zahtev.
Npr. Klijent moe istovremeno uputiti dva zahteva za pretragu. Kod LDAP-a klijent e
generisati jedinstven ID poruke za svaki zahtev. Na slici 6. klijent alje dva zahteva za
pretragu istovremeno. Server izvrava obe operacije i vraa rezultate klijentu.

Slika 6. Viestruko istovremeno pretraivanje LDAP baze podataka

Sa slike 6. se vidi da server alje kod rezultata poruke ID2 klijentu pre nego za ID1. To je
potpuno prihvatljivo i deava se vrlo esto. Ovi detalji su obino sakriveni od programera
pomoi LDAP SDK. Programeri koji piu LDAP aplikacije ne moraju da brinu o sortiranju
ovih rezultata; SDK o ovome vodi rauna automatski. LDAP protokol je mnogo efikasniji i
fleksibilniji od protokola koji rade na principu lock-step(HTTP), jer dozvoljavaju viestruke
konkurentne zahteve. Sa lock-step protokolima svaki zahtev klijenata mora biti reen pre
nego to se drugi moe poslati.
8

Npr. HTTP klijent program kao to je web browser eli da uita vie fajlova istovremeno,
mora da ostvari konekciju za svaki od tih fajlova. Za razliku od toga LDAP moe da
upravlja viestrukim operacijama sa jednom konekcijom, ograniavajui maximalni broj
konkurentskih konekcija kojima server moe da upravlja.
3.2.1 Operacije LDAP protokola
LDAP ima devet osnovnih operacija koje se mogu podeliti u tri kategorije:

Interrogation operation: search, compare. Ove operacije omoguavaju postavljanje

pitanja o direktorijumu.
Update operations: add, delete, modify, modify DN (rename). Ove operacije
omoguavaju auriranje podataka u direktorijumima.
Authentication and control operations: bind, unbind, abandon. Operacija bind
omoguava klijentu identifikaciju; operacija unbind omoguava klijentu prekid sesije; i
operacija abandon omoguava klijentu da oznai ukoliko nije vie zainteresovan za
rezultate prethodnih operacija.

Tipina klijent/server razmena pomou LDAP-a je data na slici 7.

Slika 7. Tipina LDAP razmena

Korak 1. Klijent otvara TCP konekciju ka LDAP serveru i pristupa operaciji bind. Operacija
bind sadri naziv direktorijuma za koji klijent eli autorizaciju zajedno sa credential.
Credential su esto obine lozinke, ali mogu biti i digitalni sartifikati koji slue za
autorizaciju klijenata.
Korak 2. Nakon to su provereni podaci za identifikaciju alje se rezultat uspenosti ka
klijentu.
Korak 3. Klijent alje zahtev za pretragu.
Koraci 4. i 5. Server izvrava te zahteve to rezultira sa dva odvojena odgovora.
Korak 6. Server alje poruku o rezultatu.
Korak 7. Klijent alje unbind zahtev, to se severu prikazuje kao elja klijenata za prekid
veze.
Korak 8. Server odgovara prekidom veze.
Kombinacijom ovih jednostavnih LDAP operacija klijenti mogu izvriti kompleksne
zadatke.
Npr. Kao to je prikazano na slici 5. e-mail klijent Netscape Communicator moe
pregledati pristigle poruke i pomoi korisniku da adresira poruke. On moe koristiti i
digitalni sartifikat koji se uva u direktorijumu da bi digitalno oznaio i enkriptovao poruku
koja se alje. Korisniki e-mail program izvrava operacije direktorijuma koje kojima je
mail adresovan, potpisan i enkriptovan. Sa take gledita korisnika sve se izvrava
automatski.
9

Slika 8. Directory-enabled server aplikacija

Directory-enabled aplikacija koji izvrava kompleksan zadatak. Iako aplikacije krajnjih
korisnika mogu biti directory-enabled, on nije jedina vrsta direktorijuma koja omoguava
aplikacije. Server-based aplikacija takoe koristi kao directory-enabled.
Postoje samo dva primera kako directory-enabled aplikacija mogu da poveaju mo
direktorijuma dodavanjem funkcionalnosti i pojednostavljenjem menadmenta. U
budunosti e ovoga biti sve vie.
Da bi obezbedio devet osnovnih operacija protokola LDAP verzija 3 moe da se proiri sa
jo tri metode:

LDAP operacije proirenja Nova operacija protokola. Ako u budunosti postoji

potreba za novom operacijom, ona se moe definisati i postati standard bez menjanja
LDAP protokola. Primer proirene operacije je StartTLS, koja naglaava serveru da
klijent eli da koristi transport layer securuty (TLS) da bi enkriptovao i potvrdio
konekciju.
LDAP kontrola Ekstra informacije koje se nalaze u postojeim LDAP operacijama,
menjajui ponaanje operacije. Npr, manageDSAIT kontrola je poslata zajedno sa
modifikovanom operacijom kada klijent eli da manipulie odreenim tipovima metainformacija koje se uvaju u direktorijumima (ove meta-informacije su obino sakrivene
od korisnika direktorijuma). U budunosti, dodatna kontrola se mogu biti definisane
tako da menjaju ponaanje postojeih LDAP operacija u korisne svrhe.
Simple Authentication and Security Layer (SASL) Biblioteka procedura koja
podrava vie razliitih metoda za autentifikaciju. Korienjem SASL, LDAP se moe
adaptirati da podrava nove, stabilnije metode autentifikacije. SASL takoe podrava
sigurnosne mehanizme nieg nivoa koji mogu da kriptuju komunikaciju izmeu klijenta
i servera. SASL je skup biblioteka opte namene i nije specifian samo za LDAP.

3.3 Modeli opisa LDAP direktorijuma

10

LDAP se moe bolje razumeti upoznavanjem etiri modela na kojim su bazirani:

Informacioni model Opisuje strukturu informacija skladitenih u LDAP

direktorijumu.
Model imenovanja Opisuje kako je informacija u LDAP direktorijumu
organizovana i indetifikovana.
Funkcionalni model Opisuje operacije koje se mogu izvriti na informacijama
skladitenim u LDAP direktorijumu.
Model zatite Opisuje kako informacije u LDAP direktorijumu mogu biti
zatiene od neovlaenog pristupa.

3.3.1 Informacioni model

Osnovna jedinica informacije skladitenih u direktorijumu je SLOG. Slog predstavlja npr.
osobu, server ili organizaciju. Svaki slog sadri jedan ili vie atributa. Svaki atribut ima tip i
jednu ili vie vrednosti.
SLOG << ATRIBUT (1 ili vie) <<TIP, VREDNOST (1 ili vie)
Npr. Direktorijumski slog OSOBA moe imati atribut koji se zove Telefon. Sintaksa atributa
Telefona je niz stringova. Vrednost atributa bi bio telefonski broj, npr.022/428-922. (Osoba
moe imati vie telefonskih brojeva, tada bi ovaj atribut bi imao viestruke vrednosti.)
OSOBA << Ime
<< Prezime
<< Adresa
<< Telefon << NIZ STRINGOVA,(022/428-922, 011/476-747)
<<
Pri definisanju sloga i odgovarajuih atributa definie se nain njihovog korienja,
ponaanja tokom pretraivanja i drugih operacija direktorijuma.
Atribut Telefon ima sintaksu koja specificira:

Leksikografku ureenost
Sluajevi, razmaci i crtice se ignoriu tokom poreenja
Vrednosti moraju biti slovni nizovi

Klasa objekta je opti opis i nekad se zove ablon.

Npr. Klasa objekta osoba ima atribut Prezime. Objekt koji opisuje Stanka Stanovia ima
atribut Prezime sa vrednou Stankovic.
Klase objekata koje direktorijumski serveri mogu skladititi i atribute koje one sadre su
opisane sa emom. ema definie koje klase objekata su dozvoljene i gde se nalaze u
direktorijumu. Koje atribute moraju sadrati, koji atributi su opcionalni, i moraju sadrati
sintaksu svakog atributa.
Npr. ema moe definisati klasu objekata OSOBA. ema osobe moe zahtevati da osoba
ima atribut Prezime koje je slovnog niza, specifikovati da unos osoba moe opcionalno
imati atribut Telefon koji je niz brojeva sa razmacima i crticama, i tako dalje.
11

Kontrolna ema osigurava da svi zahtevani atributi za unos budu prisutni pre nego to se
unos uskladiti. ema takoe definie naslee i podklase objekata i gde se u DIT strukturi
(hijerarhiji) moe pojaviti objekat. Slog se moe sastojati vie od jedne klase objekta.
Svaki server moe definisati sopstvenu emu. Za uzajamnu operativnost je potrebno da
opte eme budu standardizovane. U LDAP verziji 3, server daje povratnu informaciju o
sebi samom, ukljuujui emu koju koristi.
3.3.2 Model imenovanja
LDAP model imenovanja definie kako su slogovi indetifikovani i organizovani. Slogovi su
organizovani u strukturu koja lii na drvo koja se zove stablo direktorijuma (DIT). Slogovi
su ureeni u stablo direktorijuma koji je baziran na njihovim osobitim imenima (DN). DN je
jedinstveno ime koje nedvosmisleno indetifikuje pojedinani unos. DN-a su sastavljena od
niza relativnih osobitih imena (RND-a). Svaki RND u DN odgovara grani u DIT-u poevi
od korena DIT-a do direktorijumskog unosa. Svaki RDN je izveden iz atributa
direktorijumskog unosa. U optem sluaju, RDN ima sledeu formu <imeatributa>=<vrednost>. DN je sastavljen od niza RDN-ova odvojenih zarezima.
Kreiranje LDAP stabla direktorijuma (directory tree)
Stablo direktorijuma je nain organizovanja informacija. LDAP serveri uvaju informacije
hijerarhijski. Hijerarhija obezbeuje metod za logiko grupisanje pojmova. Ovo grupisanje
moe biti korisno u nekoliko sluajeva:

Delegiranje autoriteta drugom serveru ili sajtu za jednu ili vie grupa podataka
Kopiranje podataka
Sigurnost i kontrolisanje pristupa

Na slici 9. je dat primer jednostavnog stabla direktorijuma:

S t a b l o d i r e k t o r i ju m a
ro o t

c=YU

o=BG

ou=FO N

c n = M a ja H a p

......

o=NS

ou=E TF

c n = G o ra n Z e c

......

c = IT A

......

c=U S A

o=NY

o=LA

c n = D a r k o I lic
u id = u s e r n a m e
u p a s s = p a s s w o rd

c n = D a r k o I lic

......

Slika 9. Stablo direktorijuma

Svaki pravougaonik predstavlja slog direktorijuma. Atributi su prikazani u okviru sloga.
Na vrhu je root koji predstavlja poetnu taku za svako stablo direktorijuma. On je
pojmovni i ne postoji stvarno. Ispod root-a se nalaze slogovi zemalja (unos za zemlju YU
12

(c=YU) moe imati atribut opis sa vrednou Yugoslavia), ispod zemalja se nalaze gradovi
(mogu da budu nacionalne organizacije, regioni itd.), svaki od njih ima podkategorije.
Uobiajeno je pratiti ili geografsku ili organizacionu emu da bi se pozicionirali slogovi u
DIT. Ispod ovog nivoa, slogovi mogu predstavljati ljude u tim organizacijama ili budue
pododeljenje organizacije. Najnii slojevi slogova DIT-a mogu predstavljati bilo koji
objekat, kao to su ljudi, tampa, aplikacioni serveri, i tako dalje. Dubina ili irina DIT-a
nije ograniena i moe biti podeena da zadovoljava zahteve informacionih sistema.
Stavkama se daju imena prema njihovoj poziciji u DIT-u. Element direktorijuma u donjem
desnom uglu slike ima DN cn=Maja Hap, ou=FON, o=BG, c=YU.
Napomena: DN-ovi itaju od lia ka korenu. DCE elementi direktorijuma se takoe
imenuju poevi od korena. DN se sastoji iz sekvence RDN-ova. Svaki RDN se sastoji iz
atributa elementa koji imenuje.
Npr. DN cn=Darko Ili, o=NS, c=YU je nastao dodavanjem RDN-a cn= Darko Ili DN-u
elementa pretka ou=FON, o=BG, c=YU.
DIT se opisuje u formi nalik stablu, ali nije isto stablo (zbog aliasa). Aliasi dozvoljavaju
horizontalno povezivanje, tako da se anuliraju neke od loih osobina strukture istog
stabla. Ovo moe biti korisno ako element pripada vie nego jednoj organizaciji ili ako je
uobiajno korieni DN suvie sloen. Jo jedna esta primena aliasa je kada se element
pomeri unutar DIT-a a vi elite da pristup nastavi da radi kao pre. Na slici 9. cn=Darko Ili,
ou=FN, o=BG, c=YU je alias za cn=Darko Ili, o=NS, c=YU. DN-ovi u LDAP-u verzija 3 su
restriktivniju nego u verziji 2.
Npr- U LDAP-u V2, zarezi se takoe mogu koristiti da razdvoje RDN-ove. LDAP V3 mora
prihvatiti staru sintaksu, ali ne sme da generie DN-ove koji se ne slau sa novijom
sintaksom. Poto LDAP direktorijum moe biti distribuiran, jedan LDAP server ne bi
mogao uskladititi ceo DIT. Server moe sadrati elemente za specifino odeljenje a ne
elemente za pretke odeljenja.
Npr. Kao dodatne OU moemo imati lokaciju. Ovu ou moemo koristiti za dobijanje
dodatnih informacija o poslovnicama na drugim adresama, konferencijskim sobama i sl.
Adresar kompanije zasnovan na LDAP-u obezbeuje brz i lak pristup informacijama o
kompaniji. Takoe kao OU moemo imati podatke o ureajima (npr. o kompjuterima,
tampaima i ostalim kompjuterskim ureajima). To omoguava sistem administratorima
da uvaju na jednom mestu host imena, IP adrese, MAC adrese, osnovnog korisnika ili
grupu, serijske brojeve, OS imena i verzija, lokacije i opise svih ureaja u njihovoj mrei.
Posrednik je nova osobina u LDAP-u V3. Posrednici dozvoljavaju DIT-u da bude
particioniran i distribuiran na vie servera. Delovi DIT-a mogu takoe biti duplirani. To
moe poboljati performanse i dostupnost.
Napomena: Kada aplikacija koristi LDAP za dobijanje informacije o nekom elementu
stabla direktorijuma, moe se desiti da server ima samo informaciju o posredniku za taj
deo stabla, LDAP URL tu informaciju alje klijentu a klijent kontaktira novi server i dobija
informacije.
Izbor bazne DN pri pravljenju direktorijuma
Ne postoji jedinstven nain za podeavanje strukture direktorijuma. Dizajn stabla
direktorijuma se meri samo jednim kriterijumom: da li podrava trenutnu i eljenu
efikasnost.
13

Najvii nivo direktorijuma, koji se odnosi na root stabla direktorijuma, je takoe poznat
kao baza. Naziv baze je Base Distinguished Name, ili bazni DN. U principu treba odabrati
format za bazni DN. Preporuka je da bazni DN bude u trenutno najpopularnijem formatu.
1998. RFC2247 je ustanovio standard za prevoenje DNS naziva domena u LDAP (i
X.500) Distinguished names. Od tada sve vie instalacija je koristilo ovaj format Ako je
plan integracija sa Microsoft Active Directory ovo je jedini format koji moete koristiti.
Format je veoma jednostavan. Ukoliko je internet prezentacija npr, malena.com RFC2247
prevodi ovaj DNS domen u sledei DN:
dc=malena, dc=com
Dc je Domain Component. Svaki deo DNS imena je prikazan u redosledu. Izbor DN
moe da poslui i kao internet prezentacija. Ukoliko je nastavak .com moe se odabrati
dc=com, a ukoliko je .net bazni Dn moe biti dc=net. Ako nepostoji internet prezentacija
izbor e biti dc=local.
Ispod baznog DN moe biti samo jednostavan slog koji se odnosi na ostatak DNS naziva
domena.

d c=com
d c = m a len a
Slika 10. Direktorijumsko stablo za malena.com
Ukoliko se eli spojiti malena.com sa despotovic.com i sa maja.com struktura
direktorijuma e se jednostavno prilagoditi. Samo se doda dc=despotovic i dc=maja ispod
dc=com. Najvii nivo vaeg stabla direktorijuma e izgledati:

d c=com
d c = m a l en a

d c = d e sp o to v i c

d c=m aja

Slika 11. Direktorijumsko stablo spajanja malena.com sa despotovic.com i maja.com

Planiranje topologije direktorijuma
Lista saveta koja pomoe u procesu planiranja direktorijuma:
1. Stablo direktorijuma treba tako kreirati da se moe lako menjati. Treba izbegavati
stablo direktorijuma baziranog na organizacionoj emi kompanije,trenutnom
modelu poslovanja i sl.
2. Izbegavati pomeranje LDAP zapisa iz jedne OU u drugu . Ukoliko se ovo esto
deava treba redizajnirati stablo direktorijuma.
3. Ako postoje slini tipovi podataka ne treba pomerati ih iz jedne OU u drugu, treba ih
ostaviti u svojim grupama.
14

4. Ukoliko se kopiraju podaci razmisliti da li OU podelite na vie pod OU-a bazirani na

potrebama korisnika.
5. Sakrivanje dela podataka u direktorijumu bilo zbog sigurnosti ili spreavanja
konfuzije treba koristiti OU. Ako to naruava postojeu strukturu, treba doneti
odluku da li sakrivati podatke ili ne.
Podatke koji se mogu uvati u LDAP direktorijumu:

Informacije o zaposlenima
Informacije o kupcima, bilo o novim ili postojeim
Telefonske brojeve i opise lokalnih restorana i taxi servisa
Lokacije poslovnica i konferencijskih soba
Podaci o LCD projektorima
Podaci o kompjuterima: desktop, laptop, serveri, tampai, mreni ureaji
Mailing liste
NIS group map
NIS netgruop map
3.3.3 Funkcionalni model

LDAP definie operacije za pristup i modifikovanje elemenata direktorijuma. LDAP

operacije mogu biti podeljene u sledee tri kategorije

Upit ukljuuje operacije pretrage i poreenja koje se koriste da bi se dobila

informacija direktorijuma.
Update sadri dodaj, obrii, izmeni i izmeni RDN operacije koje se koriste da
auriraju informacije u direktorijumima.
Autentikacija sadri vei, razvei i napusti operacije koje se koriste da se
povee i raskine Veza sa LDAP serverom.

Operacija pretrage
Najea operacija je pretraga. Ova operacija je fleksibilna i ima i sloenie opcije.
Pretraga moe biti opta ili specifina. Operacija pretrage dozvoljava specifikaciju poetne
take DIT-a, koliko duboko unutar DIT-a traiti, atributi elementa moraju biti uzeti u obzir
za poreenje.
Primeri pretraga su:
nai potansku adresu za cn=Darko Ilic , o=NS, c=YU
daj sve elemente koji su deca elementa ou=FON, o=BG, c=YU
nai e-mail adresu i broj telefona svakoga u organizaciji ije ime sadri re "dar"
a ko takoe ima broj faksa.
Da bi se izvrila pretraga sledei parametri moraju biti specifirani:

Baza DN koji definie startnu taku, zvanu bazni objekat, pretrage. Bazni
objekat je vor u okviru DIT-a.
Opseg Specifira koliko duboko u okviru DIT-a se trai bazni objekt. Postoje tri
izbora:
15

baseObject samo se bazni objekt pregleda

singleLevel samo neposredna deca baznog objekta se pregledaju sam
bazni objekt se ne pregleda
wholeSubtree bazni objekt i svi naslednici se ptregledaju.
Filter pretrage Specifira kriterijum koji element mora ispuniti da bi bio vraen u
pretrazi. Filter pretrage je bulova kombinacija relacija vrednosti atributa.
Atributi za povratak Specifira koje atribute treba vratiti iz elemenata koji
ispunjavaju kriterijum pretrage.Poto elementi imaju mnogo atributa, ovo
dozvoljava korisnicima da vode samo atribute za koje suzainteresovani.
Normalno, korisnik je zainteresovan za vrednosti atributa. Meutim mogue je
vratiti samo tipove atributa ali ne i njihove vrednosti.
Ogranienja Pretrage mogu biti opte, pretraujui velika podstabla i dovodei
do prikazivanja mnogo elemenata. Korisnik (ili server), moe specifirati
vremenska i ogranienja veliine da bi spreio udljive pretrage dauzmu isuvie
resursa. Ogranienje veliine limitira broj elemenata koji se vraaju iz pretrage.
Vremensko ogranienje limitira vreme pretrage.

3.3.4 Model bezbednosti

Bezbednost je od velikog znaaja u svetu umreenih raunara. Tako je i u LDAP-u. Kada
se podaci alju preko neobezbeene mree, interno ili ekstreno, osetljive informacje
moraju biti zatiene tokom transporta. Takoe je potrebno znati ko zahteva informaciju i
ko je salje. To je posebno vano kada dolazi do operacije auriranja direktorijuma.
Pojam bezbednost pokriva sledee aspekte:

Identifikacija Potvrda da je suprotna strana (maina ili osoba) stvarno ona koja
tvrdi da jeste.
Integritet Potvrda da je informacija koja je stigla ista kao i ona koja je poslata.
Poverljivost Zatita od otkrivanja informacija ifrovanjem podataka za one
kojima nisu namenjeni.
Autorizacija Uveravanje da je strani stvarno dozvoljeno da radi ono to
zahteva. To se obino proverava posle Identifikacije. U LDAP v3 to trenutno nije
deo specifikacije protokola i stoga je implementacijski specifina. Autorizacija se
postie dodeljivanjem kontrola pristupa, poput itanja, pisanja i brisanja,
korisnikim Iidentifikacijama ili optim imenima resursa kojima se pristupa.

Sledei odeljak je fokusiran na prva tri aspekta (poto se autorizacija ne nalazi u LDAP V3
standardu). Postoji vie mehanizama koji se mogu koristiti u ove svrhe, o najvanijima se
ovde raspravlja.To su:
Bez identifikacije
Osnovna identifikacija
Prosti Identifikacioni i bezbednosni sloj.
Bezbednosni mehanizam u LDAP-u se odreuje kada se uspostavi veza izmeu klijenta i
servera.

3.4 LDAP URL-ovi

Poto je LDAP postao vaan protokol na internetu, URL format za LDAP resurse je
definisan. RFC 2255. LDAP URL Format opisuje format LDAP URL-a. LDAP URL poinje
sa ldap:// ili ldaps:// ako LDAP server komunicira koristei SSL. LDAP URL moe
jednostavno imenovati LDAP server ili specificirati sloenu pretragu direktorijuma.
16

Neki primeri e pomoi da se objasni format LDAP URL-a. Sledei se odnosi na LDAP
server na domainu branko.fon.bg.ac.yu, (koristei standardan port 389).
ldap:// branko.fon.bg.ac.yu/
Sledei prikuplja sve atribute za DN o=BG,c=YU sa ldap servera na domainu
saturn.itso.austin.ibm.com. Primetite da jje ovde port 389 eksplicitno specifiran u URL-u.
Poto je 389 uobiajen port, nije neophodno da se specifira u URL-u.
ldap:// branko.fon.bg.ac.yu:389/o=BG,c=YU
Sledei vraa sve atribute za cn=Darko Ili, ou=FON, o=BG, c=YU. Neki karakteri se
smatraju nebezbednim u URL-u jer mogu biti uklonjeni ili shvaeni kao graninici od
strane nekih programa. Nebezbedni karakteri poput razmaka, zareza, zagrada itd. trebaju
biti predstavljeni svojim heksadecimalnim brojem iza znaka za procenat.
ldap:// :// branko.fon.bg.ac.yu cn=Darko%20Ili, ou=FON, o=BG, c=YU
U ovom primeru %20 predstavlja razmak. Vie informacija o nebezbednim karakterima i
URL-ovima uopte se moe nai u RFC 1738 Uniform Resource Locators (URL).

17

4. PRIMENA LDAP PROTOKOLA U RAUNARSKOJ MREI FON-a

4.1 Opis raunarske mree FON-a
Namena raunarske mree Fon-a je obezbeivanje mrenih servisa za potrebe
nastave i nauno istraivakog rada. Korisnici raunarske mree su nastavnici,
saradnici i studenti redovnih i poslediplomskih studija. Raunarsku mreu takoe
mogu koristiti saradnici na projektima koji su zaposleni izvan fakulteta. Osnovna
namena raunarske mree je obezbeenje internet veza sa okruenjem.
Raunarska mrea FON-a je povezana sa okruenjem preko sledeih veza:
1.
2.
3.
4.
5.

RCUB
ETF
EUNET
YUBC
EuropeOnline

Osnovna koncepcija realizacije veza ka okruenju je redundantno povezivanje, sa

akademskom mreom (ETF, RCUB) i komercijalnim internet provajderima (YUBC,
EUNet). Grafiki prikaz je dat na slici 12.
Internet servisi u raunarskoj mrei FON-a su realizovani distribuirano to je
prikazano na slici13. na sledeim raunarima:
Sonja.fon.bg.ac.yu :
1. Servis za prijavljivanje ispita
2. Proxy za satelit (EuropeOnline) sonja.fon.bg.ac.yu port:80
3. Web za Simlab
Rasputin.fon.bg.ac.yu :
1.
2.
3.
4.

Router izmedju podmrea 120 i 130

Web
DNS
Proxy
- proxy.fon.bg.ac.yu port:8080 za akademsku mreu
- proxy.fon.bg.ac.yu port:8081 za nastavnike i saradnike
5. LDAP
6. RADIUS
7. Mail server
Sun sparcstation 20, fon.fon.bg.ac.yu :
1.
2.
3.
4.

Mail
Shell
Web za prezentacije korisnika
Sekundarni DNS

18

Slika 12. Raunarska mrea FON-a i veze sa okruenjem

19

s o n ja .f o n .b g .a c .y u
1 4 7 .9 1 .1 3 0 .7
IN T E L P -3
C PU 450M H z
256 M B R AM
5 0 G B d is k

S e r v is i n a r a u n a ru
s o n ja .f o n .b g .a c .y u :
1.
2.
3.
4.

F a jl s e r v e r la b o r a t o r ije z a s im u la c iju .
W e b la b o r a t o r ije z a s im u la c iju .
P r o x y z a s a t e lit .
P r ija v ljiv n je is p it a .

r a s p u tin .f o n .b g .a c .y u

128 M B R AM
8 G B d is k

B a y N e tw o rk s

re s e t

U LT R A
E N T E R P R IS E
150

S e r v is i n a r a u n a ru
r a s p u tin .f o n .b g .a c .y u :
1.
2.
3.
4.
5.
6.
7.
8.
9.

R u te r iz m e u m r e a 1 2 8 i 1 3 0 .
F a k u lt e t s k i w e b .
P r im a r n i D N S .
P ro x y z a a k a d e m s k u m re u .
P r o x y z a n a s ta v n ik e i s a r a d n ik e .
L D A P.
R A D IU S .
m a il.
N ew s.

11 1 3

23

12 14

24

B a y S ta c k

3 0 1 E th e r n e t S w itc h

C o m p o rt

S e rv is i n a ra u n a ru
f o n .f o n .b g .a c .y u :
1.
2.
3.
4.

M a il.
S h e ll.
W e b p r e z e n t a c ije k o r is n ik a .
S e k u n d a rn i D N S .

Slika 13. Serveri u raunarskoj mrei FON-a

20

4.2 Primena LDAP protokola za autentifikaciju i autorizaciju u raunarskoj

mrei FON-a
U raunarskoj mrei FON-a postoji stotinak raunara i vie desetina tampaa i servera.
Raunarsku mreu koriste oko 150 nastavnika i saradnika i oko 4000 studenata. Za
efikasno korienje resursa raunarske mree FON-a nuno je urediti procese autorizacije
i autentifikacije. Zbog toga se 1999. krenulo u eksperimentalni rad LDAP servera.
Aktuelna implementacija LDAP servera je preuzeta sa www.openldap.org.
Okviri za definiciju eksperimentalne baze podataka su postavljeni vrlo usko. Jedan LDAP
server i baza podataka, iskljuivo za autentifikaciju korisnika. Autorizacija za korienje
resursa se zadavala implicitno za pojedine grane stabla korisnika (direktorijumsko stablo).
Korisnici raunarske mree su podeljeni na:
1. Studenti
2. Saradnici
3. Osoblje fakulteta
4. Nastavnici
5. Studenti redovnih studija
6. Studenti poslediplomci
7. Doktoranti
8. Diplomirani studenti FON-a
9. Magistri FON-a
10. Doktori FON-a
11. Nastavnici, saradnici drugih fakulteta i instituta
12. Studenti, magistranti drugih fakulteta i instituta
13. Saradnici na nauno istraivakim projektima
14. Ostali
Zbog eksperimentalnog rada i jednostavnosti auriranja svi navedeni objekti imaju istu
strukturu koja je opisana Tabelom 1.
Tabela 1. Atributi objekata u LDAP bazi FON-a
Klasa objekata
person
uid
organizationalPerson
top
Atrubuti objekata
User id
Common name
Given name
Sure name
User password
First user pasword
Email
Zabrana pristupa
Broj indeksa

uid
cn
givenname
sn
userpassword
firstuserpassword
mail
crna_lista
broj_indeksa
21

Izgled eksperimentalne verzije stabla direktorijuma je prikazan na slici 14.

LDAP bazu podataka za svoj rad koriste sledei serveri raunarske mree FON-a:
1. Radius server koji koristi LDAP za autentifikaciju i autorizaciju Dial-in korisnika
www.xtradius.com

2. Squid proxy server koji koristi LDAP za autorizaciju pristupa web stranama na
Internetu.
www.squid.nlanr.net

3. Apache web server koji koji koristi LDAP za autorizaciju pristupa zatienim web
stranama FON-a.
www.apache.org

4. Sendmail koji koristi LDAP za prijem i slanje elektronske pote

www.sendmail.org

LDAP koriste i klijenti na PC raunarima za autentifikaciju i autorizaciju prilikom ukljuenja

na mreu.
Za auriranje eksperimentalne verzije LDAP baze podataka, u proteklom periodu je
razvijana posebna aplikacija u programskom jeziku JAVA, koja je detaljno opisana u ovom
radu.
Pregled servera i klijenata koji za svoj rad koriste LDAP bazu podataka dat na slici 15.
U narednom periodu potrebno je proiriti bazu podataka o nastavnicima, saradnicima i
studentima sa certifikatima i odgovarajuim tajnim i javnim kljuevima za realizaciju
digitalnih potpisa. Takodje je potrebno proiriti strukturu i sadraj LDAP baze podataka da
obuhvati sve raunarske i materijalne resurse fakulteta.

22

H i ja r a r h i ja b a z e p o d a t a k a L D A P s e r v e r a F O N - a
o=FO N

c=YU

o u = s tu d e n ti

o u = d o k to ra n ti

o u = s a r a d n ic i

o u = d ip lo m ir a n i
s tu d e n ti F O N -a

o u = o s o b lj e
f a k u lt e t a

o u = m a g is t r i
F O N -a

o u = n a s t a v n ic i

o u = d o k to ri
F O N -a

o u = s tu d e n ti
r e d o v n ih
s t u d ij a

o u = n a s t a v n ic i,
s a r a d n ic i d r u g ih
f a k u lt e t a i
in s t it u t a

o u = s tu d e n ti
p o s t d ip lo m c i

o u = s tu d e n ti i
m a g is t r a n t i
d r u g ih f a k u lt e t a
i in s t it u t a

o u = o s t a li

o u = s a r a d n ic i n a
naucno
is t r a z iv a c k im
p r o j e k t im a

Slika 14. Hijerarhija baze podataka LDAP servera FON-a

23

L D A P s e r v e r i k lije n ti u r a c u n a r s k o j m r e z i F O N -a
C IS C O 3 6 2 0
r a d iu s k lije n t
M odem

M odem

U d a lje n i k o r is n ik
m re z e F O N -a

R a d iu s
s e rv e r
r a d iu s .fo n .b g .a c .y u

L D A P s e rv e r
L D A P .f o n .b g .a c .y u

A p lik a c ija z a o d r z a v a n je
b a z e p o d a ta k a L D A P s e rv e ra

Au
ten
tif

S e n d m a il
s e rv e r
m a il.fo n .b g .a c .y u

S q u id
s e rv e r
p r o x y .fo n .b g .a c .y u

S U N E -1 5 0

r a s p u tin .f o n .b g .a c .y u

ika
cija
lok i aut
a ln
og orizac
r ac
i
Citan
una ja ko
je i sla
risn
ra
nje e
ika
lektro
nske
post e

r
serve
erver
proxy
ro xy s
p
Web
b
e
w
a
z
a
ij
tifikac
r
Auten
rve
r b se
e
v
r
e
se a w
z
eb
W ci j a
ka
tifi
ten
u
A

K o r is n ik lo k a ln e
ra c u n a rs k e m re z e F O N -a

Apache
s e rv e r
w w w .fo n .b g .a c .y u

Slika 15. LDAP server i kljienti u raunarskoj mrei FON-a

24

4.3 Aplikacija za auriranje baze podataka LDAP servera

Da bi se napravila dobra aplikacija za auriranje baze podataka LDAP servera treba
uraditi modelovanje. Modelovanje je centralni deo svih aktivnosti koje vode do razvijanja
dobrog softvera. Najee to su strukturni modeli koji omoguavaju ljudima da zamisle
delove sistema i da vide kako ti delovi interaguju meusobno.
Unified Modeling Language (UML) je standardni jezik za modelovanje softvera. UML se
koristi za predstavljanje, specificiranje, konstrukciju i dokumentaciju softverskog sistema.
Statika struktura sistema e se prikazati dijagramima klasa ( Class Diagram ). Statikim
modelom opisuju se entiteti sistema i veze izmeu njih koje su predstavljene klasama i
vezama izmeu klasa.
Klasa predstavlja skup atributa i operacija kojima se opisuje struktura i ponaanje
objekata posmatrane klase. Prikazuje se pravougaonikom podeljenim u tri dela. U
gornjem delu navodi se ime, stereotip i osobine klase, u srednjem navode se atributi, a u
donjem operacije posmatrane klase:
Atribut klase ima definisano ime, tip i vidljivost,opciono stereotip, viestrukost,
inicijalnu vrednost I osobine.
Tipovi mogu biti primitivni, nabrojivi ili neka druga klasa.
Vidljivost moe imati vrednosti public, protected i private.
Veze izmeu klasa mogu biti : asocijacija, agregacija, generalizacija, veza zavisnosti i
veza pojava.
Dinamikim modelom opisaemo dinamike karakteristike sistema.
Vrste komunikacije izmeu objekata su:
Interakcija opisuje nain na koji objekti u sistemu meusobno komuniciraju u cilju
ostvarivanja oekivanog ponaanja i izvrenja zadataka.
Poruka, preko njih se ostvaruje komunikacija i razmena informacija izmeu
objekata u sistemu.
Zahtev, specifikacija komunikacije izmeu objekata, podsticaja koji se prosleuje
nekom objektu.
Izuzetak poseban tip signala, koji slui za signalizaciju greke koja se moe desiti
u toku izvravanja metode neke klase objekata.
Akcija izraz kojim se opisuje funkcija sistema, a rezultat akcije moe biti promena
stanja sistema.
Scenario, predstavlja odreenu sekvencu interakcija izmeu objekata sistema.
Da bi prikazali dinamike karakteristike sistema koristImo se:
Dijagramom sekvenci se prikazuje komunikacija izmeu skupa objekata. Na njemu su
prikazane dve dimenzije: vertikalna, koja oznaava vreme, i horizontalna, koja oznaava
objekte. Akcenat je na opisu poruka i njihovom redosledu.
Dijagramom saradnje se opisuje komunikacija izmeu objekata, a ona je prikazana
objektima i njihovim vezama. Komunikacija izmeu objekata opisuje se porukama koje
objekti meusobno razmenjuju, ostvarujui na taj nain oekivano ponaanje i odreenu
funkcionalnost sistema.
25

Model prikazujemo USE CASE dijagramima, na kojima su predstavljeni sluajevi

korienja, veze izmeu njih, zatim uesnici i veze izmeu nih.
Program za administraciju LDAP baze podataka se sastoji iz sledeih procesa:
1. Podeavanje parametara konekcije
1.1 Unos podataka o pristupu serveru
1.1.1 Host name
1.1.2 Base DN
1.1.3 Port
1.2 Unos podataka za autentifikaciju administratora
1.2.1 Manager DN
1.2.2 Password
2. Unos korisnika
2.1 Izbor korisnike grupe
2.2 Unos korisnika
2.2.1 Ime
2.2.2 Prezime
2.2.3 Username
2.2.4 Alias
2.2.5 Password
2.2.6 Password potvrde
2.2.7 Broj indeksa
2.2.8 Mail
2.2.9 Mail kvota
2.2.10 Na crnoj listi
3. Pretraivanje korisnika
3.1 Pretraivanje po atributima
3.1.1 Unos Username
3.1.2 Unos Ime i prezime
3.1.3 Unos broja indeksa
3.2 Prikaz rezultata pretraivanja
4. Izmena podataka o korisniku
4.1 Izbor korisnike grupe
4.1.1 Prikaz korisnika
4.2 Izbor korisnika
4.2.1 Prikaz atributa korisnika
4.2.2 Izmena atributa
4.2.2.1 Ime
4.2.2.2 Prezime
4.2.2.3 Username
4.2.2.4 Alias
4.2.2.5 Password
4.2.2.6 Password potvrda
4.2.2.7 Broj indeksa
4.2.2.8 Mail
4.2.2.9 Mail kvota
4.2.2.10 Crna lista
5. Unos korisnike grupe
5.1 Izbor ili unos korisnike grupe

26

Slika 15. Use-case dijagram Administracija naloga

Slika 16. Use-case dijagram Podeavanje parametara konekcije

27

Slika 17. Use-case dijagram Unos podataka za pristup serveru

Slika 18. Use-case dijagram Unos podataka za autentifikaciju administratora

28

Slika 19. Dijagram klase Podeavanje parametara konekcije

29

Slika 20. Dijagram sekvenci za Podeavanje parametara konekcije

30

Slika 21. Dijagram kolaboracije za Podeavanje parametara konekcije

Proces Podeavanje parametara konekcije kao sluaj korienja, dijagram klasa,
sekvencijalni i kolaboracioni dijagram (Slike 15., 16., 17., 18., 19., 20., 21.) je veoma
slian ostalim procesima programa ( Unos korisnika, Pretraivanje korisnika, Izmena
podataka o korisniku, Unos korisnike grupe ). Zbog velike slinosti procesa neemo
zalaziti u dalju analizu gore navedenih procesa i njihovih podprocesa na niim nivoima
dekompozicije.

ZAKLJUAK

31

U okviru ovog diplomskog rada, pored osnovnih teorijskih koncepata funkcionisanja LDAP
protokola opisana je koncepcija upravljanja resursima raunarske mree FON-a,
definisani osnovni elementi za specifikaciju baze podataka, konfigurisanje LDAP servera i
odgovarajuih kljenata.
U raunarskoj mrei FON-a postoji stotinak raunara i vie desetina tampaa i servera.
Raunarsku mreu koriste oko 150 nastavnika i saradnika i oko 4000 studenata. U okviru
ovog rada dat je prikaz sadanjeg stanja LDAP baze podataka na FON-u, kao i deo
aplikacije u programskom jeziku JAVA koja omoguava da se iz web okruenja realizuju
administratorski poslovi vezani za korisnike, prava pristupa i servise mree.
Pored osnovnih koncepata LDAP protokola i baze podataka koji su prikazani u ovom radu,
u narednom periodu ostaje da se proiri baza podataka o nastavnicima, saradnicima i
studentima sa certifikatima i odgovarajuim tajnim i javnim kljuevima za realizaciju
digitalnih potpisa. Takodje je potrebno proiriti strukturu i sadraj LDAP baze podataka da
obuhvati sve raunarske i materijalne resurse fakulteta.

32

LITERATURA
1. Internet i savremeno poslovanje,
Editori M.Ivkovi, B.Radenkovi.
Fakultet tehnikih nauka, Zrenjanin, 1998.
2. Konkurentno programiranje u programskom jeziku JAVA
B.Radenkovi, skripta, FON, Beograd, 2000.
3. Distribuirani informacioni sistemi,
D. Starevi, skripta, Beograd 2001.
4. Uvod u objedinjeni jezik modeliranja,
Ivana Stanojevi, Duan Surla,
Grupa za informacione tehnologije, Novi Sad, 1999.
5. The SLAPD and SLURPD Administrators Guide,
University of Michigan, Release 3.3, 1996.
6. Authentication project report,
David J.N. Begley, Information Technology services, University of Westerne
Sydney, Nepean, 1999.
7. TCP/IP Tutorial and Technical Overview
Martin W. Murhammer, Orcun Atakan, Stefan Bretz,
Larry R. Pugh, Kazunari Suzuki, David H. Wood,
International Technical Support Organization, http://www.redbooks.com.
October 1998.
8. Mogue zloupotrebe i prana zatita u raunarskoj mrei FON-a,
M.Despotovi, seminarski rad, FON, Beograd, 2001.
9. Zepter book world,
M.Despotovi, seminarski rad, FON, Beograd, 2001.
10. Authentication project report,
David J.N. Begley, Information Technology services, University of Westerne
Sydney, Nepean, 1999.
11. Aplikacija za auriranje LDAP baze podataka FON-a u jeziku C++
D.Sarkanovi, Seminarski rad, FON, Beograd 2000.
12. www.openldap.org
13. www.opengroup.org
14. RFC 2251, RFC2252
15. Izvod iz projekta izvedenog stanja raunarske mree FON-a, mart 2001.
33

PRILOG 1. Izgled ekrana aplikacije za auriranje LDAP baze podataka

Trenutna implementacija nije realizovana u potpunosti, s obzirom na edukativnu ulogu
ovog projekta. Ostaje otvorena mogunost nadgradnje postojeeg reenja.
Na osnovu modelovanja je implementirana Aplikacija Administratorski
nalog .
Korisniki interfejs i komunikacija interfejsa sa bazom podataka ostvareni su u Java
tehnologiji. Osnovno reenje podrazumeva pristup LDAP serveru od strane klijenata.
Na glavnom ekranu se vri izbor jedne od opcija programa.

Podeavanje parametara konekcije

Ovaj dialog slui za podeavanje sledeih parametara konekcije na LDAP Server:

34

Ime LDAP servera,

Port LDAP servera (default vrednost je 389),
BaseDN,
Verzija LDAP konekcije,
Administratorov DN i password;

Unos korisnika
U ovom dialogu se unose podaci o novom korisniku kojeg elimo uneti u LDAP server,
odnosno, kojima elimo otvoriti Email nalog.

Unose se osnovni podaci:

Ime i prezime korisnika,

Username (ukoliko korisnik nije student) odnosno Broj indeksa (ukoliko je
korisnik student I tada mu username odgovara njegovom broju indeksa),
Lozinka korisnika (potrebno ju je uneti dva puta radi provere),
Mail adresa novog korisnika (ukoliko se ne unese nista onda se mail adresa
formira na osnovu username-a),
Mail kvota.
Na Crnoj listi (ovaj parametar oznacava da li je korisnik na crnoj listi (1) ili ne
(0). Na poetku se ovaj parametar postavlja na vrednost 0)

Pretraivanje korisnika
35

U ovom dialogu se vri pretraivanje postojeih korisnika na LDAP serveru I to po tri

kriterijuma:

User name,
Ime i prezime,
Broj indeksa (ovaj nain pretraivanja pogodan je samo za korisnike studente
kojima je upisan broj indeksa)

Zavisno od eljenog kriterijuma pretraivanja potrebno je upisati eljeni kriterijum u

odgovarajue polje i pritisnuti odgovarajue dugme Trai. Prilikom zadavanja kriterijuma
mogu se koristiti i joker znaci:

* jedan ili vise karaktera,

? jedan karakter.

Nakon to se unese kriterijum pretraivanja i pritisne odgovarajue dugme Trai, za

nekoliko trenutaka na ekranu e se pojaviti rezultati pretraivanja u vidu imena korisnika.
Ukoliko elimo videti podatke za nekog korisnika na listi potrebno je miem kliknuti na to
ime i pritisnuti dugme Prikai ime se otvara novi dijalog sa podacima o tom korisniku.
Izmena podataka o korisniku
36

U ovom dialogu se menjaju parametri postojeeg korisnika (koji je izabran u dialogu za

pretraivanje korisnika).

U ovom dialogu su prikazani korisnikovi podaci a biranjem opcije Prikai skrivene

Atribute prikazuju se i svi ostali LDAP atributi vezani za tog korisnika (objectclass, itd).
Sve parametar je mogue menjati. Nakon izmene potrebno je podatke snimiti pritiskom na
dugme Snimi.

Unos korisnike grupe

37

Nakon to se izabere ova opcija iz glavnog menija otvorie se ovaj dialog i u njemu e se
prikazati postojee korisnike grupe.

Ukoliko se eli ubaciti nova korisnika grupa potrebno je upisati ime nove grupe i pritisnuti
dugme Snimi. Ukoliko je ime grupe ispravno uneeno i takva grupa ve ne postoji, bie
kreirana grupa sa tim imenom.
Ukoliko se eli obrisati neka od postojeih grupa potrebno je selektovati eljenu grupu u
listi ponuenog i pritisnuti dugme Obrii. Time e grupa biti izbrisana.
Napomena: Grupa se moe obrisati samo ako u njoj nema ni jednog korisnika inae se
dobije poruka o greci.

38