Implementacja prototypu modułu dostępu do danych SkOs przy pomocy protokołu LDAP

Transkrypt

1 Implementacja prototypu modułu dostępu do danych SkOs przy pomocy protokołu LDAP Wojciech Kowalczyk( Przemysław Curzytek( 19 stycznia Częśćkonceptualna 1.1 Sformułowanie zadania projektowego SkOs, a mówiąc dokładniej Skład Osobowy- stanowi bardzo popularną bazę danych i doskonałe źródło podstawowych informacji na temat pracowników Akademii Górniczo-Hutniczej. Jest on przydatny w szczególności dla studentów, podczas wpisywania nazwisk i tytułów naukowych wykładowców do indeksów oraz kiedy zajdzie potrzeba uzyskania pewnych porad i skonsultowania się w sprawach naukowych drogą mailową, czy też odbycia bezpośredniej rozmowy w pokoju pracownika. Jednak oprócz studentów z tej bazy danych korzystają również pracownicy AGH oraz innych uczelni, a także osoby trzecie, które z różnych przyczyn potrzebują się skontaktować z daną osobą. Cały system SkOs został wykonany jako praca dyplomowa przy użyciu następujących technologii: Apache+PostgreSQL+PHP. Naszym zadaniem jest zaimportowanie istniejących danych do stworzonej przez nas bazy danych, a następnie postawienie serwera wykorzystującego protokół dostępu do katalogu, LDAP(Lightweight Directory Access Protocol). Spróbujemy również stworzyć prosty interfejs webowy dostępu do bazy danych przy wykorzystaniu popularnego frameworka webowego, Django. 1.2 Analiza stanu wyjściowego Projekt stanowi rozszerzenie, a zarazem alternatywę istniejącego na uczelni systemu SkOs. Dane zgromadzone w tej bazie są efektem kilkuletniej pracy administratorów tegoż systemu. Dla celów naszego projektu niezbędna jest możliwość zaimportowania zgromadzonych danych oraz ich późniejszego aktualizowania. Wiąże się to jednak z koniecznością wyrażenia zgody przez władze uczelni, ponieważ w bazie będą przetwarzane rzeczywiste dane osobowe. Dlatego też najprawdopodobniej w bazie nie znajdą się dane prywatne, takie jak adres zamieszkania, czy telefon prywatny. Istniejąca baza danych została przeanalizowana na podstawie udostępnionych zapomocąstrony 1 danychpersonalnych.niesątojednakwszystkieinformacjezawartewtej bazie. Reszta danych, jak na przykład lista osób administrujących poszczególne obszary bazy jest niedostępna. Jakkolwiek struktura SkOs wydaje się przejrzysta i nie mieliśmy problemu ze 1 1

2 1 CZĘŚĆ KONCEPTUALNA 2 stworzeniem projektu naszej bazy danych. Pojawiają się jednak obawy, co do stworzonej tabeli unit, w której zostaną umieszczone poszczególne jednostki administracyjne AGH. Założeniem tej tabeli jest możliwość rekursywnego przeszukiwania od najniższych szczebli do najwyższych w hierarchii struktur uczelni. Rozwiązanie takie uważamy w tej sytuacji za najprostsze, jednak nie wiemy jak zostało to zrealizowane w istniejącym systemie. 1.3 Analiza wymagań użytkownika Użytkownik systemu będzie chciał uzyskać interesujące go informacje używając interfejsu webowego pozwalającego na współpracę z serwerem. Będzie wysyłał do procesu postmastera żądania typu SELECT. Ponieważ tworzona baza danych jest przeznaczona wyłącznie do odczytu danych, należy położyć szczególny nacisk na prędkość wyszukiwania. Dobrym sposobem na uzyskanie takiego efektu będzie stworzenie indeksów, które w znaczący sposób zwiększają prędkość przeszukiwania danych w stosunku do typowego szukania sekwencyjnego. PostgreSQL jest jednak wyposażony w mechanizm automatycznego dodawania indeksu dla kolumny zdefiniowanej jako klucz główny. Prawdopodobnie będzie to wystarczające dla naszej niewielkiej bazy danych, choć bez większych konsekwencji będzie można dodać kilka innych indeksów. Może to jedynie spowolnić wprowadzanie i aktualizację danych, jednak czynności te będą wykonywane co pewien ustalony okres. 1.4 Określenie scenariuszy użycia i identyfikacja funkcji Baza danych SkOs ma jedynie charakter informacyjny. Użytkownik(host) nie może w żaden sposób modyfikować istniejących danych, ani dopisywać nowych. Może jedynie wyszukiwać pracowników AGH na podstawie dostępnych kryteriów, m.in. nazwisko, imie, grupa, stanowisko, funkcja, jednostka. Kryteria te są identyczne jak w przypadku istniejącego już systemu. Również uprawnienia administratora systemu są bardzo ograniczone. Nie może bowiem zmieniać zaimportowanych danych, zgodnie z ustawą o ochronie danych osobowych. Będzie natomiast odpowiadał za konfigurację systemu i czuwał nad poprawnym przebiegiem procedury importu danych, tak by nie doszło do naruszenia spójności, atomiczności i izolacji danych. Wyszukiwanie osób według kryteriów: 1. Wyszukiwanie podstawowe: (a) Nazwisko (b) Imię (c) Tytuł 2. Wyszukiwanie zaawansowane(= Wyszukiwanie podstawowe +): (d) Grupa (e) Stanowisko (f) Funkcja (g) (h) Jednostka

3 1 CZĘŚĆ KONCEPTUALNA 3 (i) Pawilon (j) Pokój (k) Telefon (l) Ciało kolegialne Ze względu na bardzo duże restrykcje nałożone na użytkowanie bazy danych diagramy DFD, STDiFHDsątrywialne. 1.5 FHD Functional Hierarchy Diagram 1. System zarządzania danymi osobowymi pracowników AGH 1.1 Ewidencja pracowników Wyszukiwanie pracownika Aktualizacja danych pracownika Dodanie pracownika Usunięcie pracownika Należy tutaj jednak zaznaczyć, że operacje dodawania, usuwania, czy też aktualizowania danych nie są przeprowadzane bezpośrednio przez administratora systemu, lecz w momencie importu i aktualizacji z bazy danych SkOs. 1.6 STD State Transition Diagram

4 1 CZĘŚĆ KONCEPTUALNA ERD Entity Relationship Diagram 1.8 DFD Data Flow Diagram diagram kontekstowy

5 2 CZĘŚĆ LOGICZNA 5 diagram zerowy(systemu) 2 Częśćlogiczna 2.1 Opis podstawowych tabel bazy danych Diagram ERD zawierający wszystkie tabele został przedstawiony już w sekcji 1.7. Na diagramie widoczne są zależności między tabelami, wyszczególnione są klucze główne i obce. PostgreSQL jest wyposażony w mechanizm automatycznego tworzenia indeksów na kolumnach będących kluczami głównymi tabel. Dla celów naszego projektu nie było potrzebne zdefiniowanie nowych indeksów, ze względu na fakt, iż dane są przenoszone do bazy hierarchicznej LDAP. 2.2 Słownikidanych Słowniki danych stanowią alternatywną metodę zapisu konceptualnego modelu danych. Każda tabela zawiera opis i typ atrybutów. Związki pomiędzy tabelami można odczytać na podstawie zawartego w sekcji 1.7 diagramu ERD. Przyjęta przez nas konwencja stanowi, że atrybuty tabeli będące kluczami obcymi posiadają identyczną nazwę jak klucze główne tabel połączonych relacjami, co ma pomóc w analizie struktury. W bazie danych występują dwie relacje typu wiele do wielu. Odpowiednie tabele pośrednie tych relacji posiadają w swoich nazwach sufiks pomoc. Tabela 1: tytul tytul id(pk) integer not null identyfikator tytułu naukowego tytul nazwa varchar(32) not null nazwa tytułu naukowego

6 2 CZĘŚĆ LOGICZNA 6 Tabela 2: pracownik pracownik id(pk) integer not null identyfikator pracownika AGH tytul id(fk) integer identyfikator tytułu naukowego imie varchar(32) imię pracownika nazwisko varchar(32) not null nazwisko pracownika Tabela 3: strona www www id(pk) integer not null identyfikator strony pracownika www text adres strony pracownika pracownik id(fk) integer not null identyfikator pracownika Tabela 4: adres prywatny pracownik id(pk,fk) integer not null identyfikator pracownika AGH ulica varchar(64) ulica miasto varchar(32) miasto kod pocztowy character(6) kod pocztowy Tabela 5: adres mail mail id(pk) integer not null identyfikator adresu mail mail text adres mail pracownika pracownik id(fk) integer not null identyfikator pracownika Tabela 6: telefon prywatny telefon id(pk) integer not null identyfikator telefonu telefon numer varchar(20) numer telefonu pracownik id(fk) integer not null identyfikator pracownika Tabela 7: funkcja agh funkcja agh id(pk) integer not null identyfikator funkcji AGH funkcja nazwa varchar(20) nazwa funkcji

7 2 CZĘŚĆ LOGICZNA 7 Tabela 8: jednostka agh jednostka agh id(pk) integer not null identyfikator jednostki AGH jednostka nazwa text not null nazwa jednostki jednostka nadrzedna id integer identyfikator jednostki nadrzędnej Tabela 9: funkcja pracownika funkcja pracownika id integer not null identyfikator funkcji (PK) pracownik id(fk) integer not null identyfikator pracownika funkcja agh id(fk) integer not null identyfikator funkcja AGH jednostka agh id(fk) integer not null identyfikator jednostki AGH Tabela 10: cialo kolegialne cialo kolegialne id(pk) integer not null identyfikator ciała kolegialnego cialo kolegialne nazwa text not null nazwa ciała kolegialnego jednostka agh id(fk) integer not null identyfikator jednostki nadzorującej ciało Tabela 11: cialo kolegialne pomoc cialo kolegialne id(pk) integer not null identyfikator tabeli pomocniczej pracownik id(fk) integer not null identyfikator pracownika cialo kolegialne id(fk) integer not null identyfikator ciała Tabela 12: grupa grupa id(pk) integer not null identyfikator grupy AGH grupa nazwa text not null nazwa grupy Tabela 13: stanowisko stanowisko id(pk) integer not null identyfikator stanowiska AGH stanowisko nazwa text not null nazwa stanowiska Tabela 14: pawilon pawilon id(pk) integer not null identyfikator pawilonu AGH pawilon nazwa text not null nazwa pawilonu

8 2 CZĘŚĆ LOGICZNA 8 Tabela 15: telefon sluzbowy telefon id(pk) integer not null identyfikator telefonu AGH telefon numer varchar(20) not null numer telefonu Tabela 16: fax zatrudnienie id(pk,fk) integer not null identyfikator faksu AGH telefon numer varchar(20) not null numer faksu Tabela 17: telefon sluzbowy pomoc telefon zatrudnienie id integer not null identyfikator tabeli pomocniczej (PK) telefon id(fk) integer not null identyfikator telefonu AGH zatrudnienie id(fk) integer not null identyfikator zatrudnienia Tabela 18: zatrudnienie zatrudnienie id(pk) integer not null identyfikator zatrudnienia pracownika pracownik id(fk) integer identyfikator pracownika jednostka agh id(fk) integer identyfikator jednostki AGH stanowisko id(fk) integer identyfikator stanowiska AGH grupa id(fk) integer identyfikator grupy AGH pawilon id(fk) integer identyfikator pawilonu AGH pietro pokoj varchar(40) piętro i numer pokoju pracownika glowne boolean defaulttrue oznaczenie zatrudnienia jako główne lub dodatkowe Powyższe tabele zostały stworzone tylko na podstawie analizy danych umieszczonych na stronach systemu SKOS. Oznacza to, iż pewne dane i relacje mogły zostać pominięte. Te dane posłużyły do znalezienia i odpowiedniego umiejscowienia w bazie następujących związków: 1. Każdy pracownik może posiadać 0 lub kilka stron www, adresów mailowych, telefonów prywatnych. 2. Każdy pracownik może posiadać lub nie tytuł naukowy. 3. Każdy pracownik może udostępnić swój adres prywatny lub nie. 4. Każdy pracownik może wykonywać 0 lub więcej funkcji 5. Każdy pracownik może należeć do 0 lub więcej ciał kolegialnych

9 2 CZĘŚĆ LOGICZNA 9 6. Każdy pracownik może posiadać 0 lub więcej miejsc pracy(tabela zatrudnienie), z miejscem pracy wiążą się jednostka, stanowisko, grupa, pawilon, piętro, pokój oraz numery telefonów służbowych 2.3 Analiza zależności funkcyjnych i normalizacja tabel Wszystkie tabele posiadają klucze proste, dlatego też wszystkie relacje są w drugiej postaci normalnej. Powodem użycia klucza prostego w tabelach pomocniczych relacji wiele do wielu jest fakt iż framework Django, który został wykorzystany do administracji bazy danych nie daje możliwości tworzenia kluczy złożonych. Taki klucz w literaturze angielskiej jest określany jako surrogate key. Wszystkie tabele oprócz tabeli adres prywatny(zależne od siebie pola miasto i kod pocztowy) są również w trzeciej postaci normalnej, a zarazem BCNF. Atrybuty są zależne jedynie od kluczy głównych. Denormalizację tabel uważamy tutaj za czynność zbyteczną, ze względu na fakt iż baza danych jest stosunkowo niewielka, a także później tworzony jest widok denormalizujący całą strukturę bazy danych, w celu umieszczenia danych w bazie LDAP. Poniżej umieszczony został kod SQL tworzący taki widok. create view ldap person (id,id prim,imie,nazwisko,cn,tytul,mail,www,tel prywatny,adres prywanty,grupa, stanowisko,pokoj,pawilon,fax,tel sluzbowy,czy glowne,jednostka agh,cialo kolegialne,funkcja) as select pracownik.pracownik id+1000, pracownik.pracownik id+1000, pracownik.imie, pracownik.nazwisko, pracownik.imie ŠŠ ŠŠpracownik.nazwisko, tytul.tytul nazwa, adres mail.mail, strona telefon prywatny.telefon numer, adres prywatny.ulica ŠŠ $ ŠŠadres prywatny.kod pocztowy ŠŠ ŠŠadres prywatny.miasto, grupa.grupa nazwa, stanowisko.stanowisko nazwa, zatrudnienie.pietro pokoj, pawilon.pawilon nazwa ŠŠ, ŠŠzatrudnienie.pietro pokoj, fax.fax, telefon sluzbowy.telefon numer, case when zatrudnienie.glowne = true then Główne miejsce pracy else Dodatkowe miejsce pracy end, zwroc jednostki(zatrudnienie.jednostka agh id), cialo kolegialne.cialo kolegialne nazwa, funkcja: ŠŠfunkcja agh.funkcja nazwa ŠŠ w jednostce: ŠŠ zwroc jednostki(funkcja pracownika.jednostka agh id) from pracownik left outer join tytul on tytul.tytul id = pracownik.tytul id left outer join adres mail on adres mail.pracownik id = pracownik.pracownik id left outer join strona www on strona id = pracownik.pracownik id left outer join telefon prywatny on telefon prywatny.pracownik id = pracownik.pracownik id left outer join adres prywatny on adres prywatny.pracownik id = pracownik.pracownik id

10 2 CZĘŚĆ LOGICZNA 10 left outer join zatrudnienie on zatrudnienie.pracownik id = pracownik.pracownik id left outer join grupa on grupa.grupa id = zatrudnienie.grupa id left outer join stanowisko on stanowisko.stanowisko id = zatrudnienie.stanowisko id left outer join pawilon on pawilon.pawilon id = zatrudnienie.pawilon id left outer join fax on fax.zatrudnienie id = zatrudnienie.zatrudnienie id left outer join telefon sluzbowy zatrudnienie pomoc on telefon sluzbowy zatrudnienie pomoc.zatrudnienie id = zatrudnienie.zatrudnienie id left outer join telefon sluzbowy on telefon sluzbowy.telefon id = telefon sluzbowy zatrudnienie pomoc.telefon id left outer join cialo kolegialne pracownik pomoc on cialo kolegialne pracownik pomoc.pracownik id = pracownik.pracownik id left outer join cialo kolegialne on cialo kolegialne.cialo kolegialne id = cialo kolegialne pracownik pomoc.cialo kolegialne id left outer join funkcja pracownika on funkcja pracownika.pracownik id = pracownik.pracownik id left outer join funkcja agh on funkcja agh.funkcja agh id = funkcja pracownika.funkcja agh id; 2.4 Opis tabel i widoków LDAP OpenLDAP dostarcza specjalnych narzędzi(sql-backend), za pomocą których możliwe jest przeniesienie danych z bazy PostgreSQL do bazy hierarchicznej LDAP. Operacja ta jest możliwa przy pomocy pięciu obowiązkowych tabel zdefiniowanych przez standardy pakietu OpenLDAP. Tabela 19: ldap oc mappings id(pk) integer notnull identyfikator klasy protokołu LDAP name varchar(64) not null nazwa klasy protokołu keytbl varchar(64) not null nazwa tabeli zawierających dane personalne keycol varchar(64) not null klucz główny tabeli create proc varchar(255) wyrażenie w języku SQL delete proc varchar(255) wyrażenie w języku SQL expect return integer not null wartość zwracana Tabela ldap oc mappings(tabela 19) definiuje m.in. przynależność poszczególnych wpisów widoku ldap person do odpowiedniej klasy protokołu LDAP- inetorgperson. Ponieważ nie jest możliwe tworzenie i usuwanie danych z bazy LDAP za pomocą plików ldif, pola create proc oraz delete proc mają wartość NULL. Gdyby jednak dopuścić taką możliwość pola te zawierałyby wyrażenia w języku SQL odpowiednio wstawiające oraz usuwające dane z bazy PostgreSQL. Pole expect return zgodnie z konwencją posiada zawsze wartość 0. Oprócz klasy inetorgperson do opisu pracowników w projekcie zostały użyte również klasy eduperson i pleduperson. Ponieważ jednak nie jest możliwe jednoczesne przypisanie obiektu do trzech klas, proces ten odbywa się przy pomocy innej tabeli. Dwie inne klasy: organization oraz organizationalunit opisują odpowiednio Akademię Górniczo-Hutniczą, jako organizację i ogólną społeczność pracowników.

11 2 CZĘŚĆ LOGICZNA 11 Wpisy jakie zostały wprowadzone do tabeli ldap oc mappings: 1. insert into ldap oc mappings(name,keytbl,keycol,create proc,delete proc,expect return) values( organization, uczelnia, id,null,null,0); 2. insert into ldap oc mappings(name,keytbl,keycol,create proc,delete proc,expect return) values( organizationalunit, jednostka organizacyjna, orgunit id,null,null,0); 3. insert into ldap oc mappings(name,keytbl,keycol,create proc,delete proc,expect return) values( inetorgperson, ldap person, id,null,null,0); Tabela 20: ldap attr mappings id(pk) integer not null identyfikator mapowania kolumnynaatrybutklasyldap oc map id(fk) integer not null identyfikator klasy protokołu LDAP name varchar(255) not null nazwa atrybutu klasy sel expr varchar(255) not null kolumna tabeli sel expr u varchar(255) from tbls varchar(255) not null nazwa tabeli join where varchar(255) wyrażenie SQL add proc varchar(255) wyrażenie SQL delete proc varchar(255) wyrażenie SQL param order integer not null expect return integer not null wartość zwracana Tabela ldap attr mappings(tabela 20) definiuje zależności między atrybutami klas protokołu LDAP, a odpowiednimi kolumnami widoku i tabel zawierających dane pracowników. Ponownieniezezwalasięnadodawanieiusuwaniewpisówzapomocąplikówldif,stądpola,któremożna uzupełnić wyrażeniami języka SQL mają wartość NULL. Ważne jest odpowiednie uzupełnienie pola sel expr nazwą kolumny, która później będzie wykorzystywana w procesie wyszukiwania danych. Za pomocą tabeli ldap attr mappings przemapowane zostały odpowiednie kolumny widoku ldap person na atrybuty klas. Lista użytych atrybutów poszczególnych klas: 1. organization(tabela uczelnia) (a) o- nazwa organizacji (b) postaladdress- adres pocztowy (c) telephonenumber- numer telefonu 2. organizationalunit(tabela jednostka orgaznizacyjna) (a) ou- nazwa jednostki organizacyjnej (b) description- opis jednostki 3. inetorgperson(widok ldap person)

12 2 CZĘŚĆ LOGICZNA 12 (a) employeenumber- numer identyfikujący pracownika(pracownik id+1000) (b) givenname- imię (c)sn-nazwisko (d)cn-imięinazwisko (e) title- tytuł naukowy (f)mail-adresmail (g) displayname- imię i nazwisko (h) uid- numer identyfikacyjny (i) labeleduri- adres strony internetowej (j) homephone- telefon prywatny (k) homepostaladdres- adres domowy (l) departmentnumber- nazwa jednostki AGH (m) roomnumber- piętro i numer pokoju (n)l-nazwapawilonu (o) facsimiletelephonenumber- numer faksu (p) telephonenumber- numer telefonu służbowego (q) description- oznaczenie miejsca pracy jako główne lub dodatkowe (r) ou- nazwa ciała kolegialnego (s)o-funkcjainazwajednostki,wktórejtafunkcjajestpełniona 4. eduperson, pleduperson(widok ldap person) (a) edupersonaffiliation- nazwa grupy pracowników (b) plposition- nazwa stanowiska Pełny opis klas i ich atrybutów dostępny jest na stronach Tabela 21: ldap referrals entry id(pk) integer not null identyfikator url text not null adres URL Tabela ldap referrals(tabela 21) jest tabelą obowiązkową, aczkolwiek nie znaleźliśmy żadnych informacji dotyczących jej przeznaczenia i użycia. W projekcie nie jest ona uzupełniana, ani używana. Kolejna tabela to tabela ldap entries. Jednak nie jest wskazane utworzenie tej tabeli, a następnie uzupełnienie jej odpowiednimi informacjami, ponieważ wiązałoby się to z koniecznością zduplikowania danych zgromadzonych we wcześniej utworzonym widoku. Dlatego zamiast tabeli jest tworzony widok o tej samej nazwie i wykorzystana jest do tego tabela pomocnicza, przechowująca dane statyczne.

13 2 CZĘŚĆ LOGICZNA 13 Tabela 22: ldap static entries id integer not null identyfikator obiektu dn varchar(255) not null unikatowy ciąg znaków identyfikujący obiekt oc map id integer not null identyfikator klasy obiektu parent integer not null identyfikator rodzica w drzewie hierarchii keyval integer not null identyfikator tabeli, z której pochodzi dany obiekt Wykonane wpisy do tabeli: insert into ldap static entries(id,dn,oc map id,parent,keyval) values(1, dc=agh,dc=edu,c=pl,1,0,1); insert into ldap static entries(id,dn,oc map id,parent,keyval) values(2, ou=people,dc=agh,dc=edu,c=pl,2,1,400); Następnie tworzony jest widok ldap entries: create view ldap entries(id,dn,oc map id,parent,keyval) as selectid,dn,ocmapid,parent,keyvalfromldapstaticentries union select id, cn= ŠŠcn ŠŠ +uid= ŠŠid ŠŠ,ou=people,dc=agh,dc=edu,c=PL, 3, 2, id from ldap person wherecnisnotnull; Widok ldap entries pełni dużą rolę w procesie przekazywania danych z bazy PostgreSQL do bazy LDAP. Po pierwsze nadaje każdemu obiektowi distinguish name, czyli unikatowy ciąg znaków, w którym zawarta jest również ścieżka drzewa do danego obiektu. Ważne jest wskazanie rodzica każdego obiektu. W przypadku pracowników rodzicem obiektu klasy inetorgperson jest organizationalunit people, którego rodzicem jest organization AGH, będąca korzeniem drzewa. Jak już wcześniej zostało wspomniane nie jest możliwe równoczesne przypisanie obiektu do trzech klas. Operacja ta jest wykonywana po stworzeniu widoku ldap entries. Pierwszym krokiem jest stworzenie tabeli, w której przechowywana jest lista dodatkowych klas wraz z identyfikatorami klas już użytych(tabela ldap objectclass list). Następnie, na jej podstawie w widoku ldap entry objclasses następuje przypisanie kolejnych obiektów z widoku ldap entries do odpowiedniej dodatkowej klasy. Tabela 23: ldap objectclass list oc map id integer not null identyfikator klasy z tabeli ldap oc mappings objectclass varchar(64) not null nazwa dodatkowej klasy Wpisy do tabeli: insert into ldap objectclass list values(1, dcobject ); insert into ldap objectclass list values(2, dcobject ); insert into ldap objectclass list values(3, eduperson ); insert into ldap objectclass list values(3, pleduperson );

14 2 CZĘŚĆ LOGICZNA 14 Widok ldap entry objclasses: create view ldap entry objclasses(entry id,oc name) as select id, objectclass from ldap entries,ldap objectclass list where ldap entries.oc map id = ldap objectclass list.oc map id; 2.5 Zapytania serwera LDAP Wyszukiwanie danych w bazie LDAP odbywa się przy pomocy polecenia ldapsearch. Komenda wywoływana jest w shellu. Jej składnia jest następująca: $ ldapsearch-x-b"dn""filtr" Parametr-x oznacza prostą autentykację,-b dn oznacza przeszukiwanie w bazie o zadanym dn. Przykłady prostych filtrów: "(objectclass=*)"- znajdź wszystkie obiekty "(&(objectclass=inetorgperson)(cn=m*))"- znajdź wszystkie obiekty klasy inetorg- Person o atrybucie cn(imię i nazwisko) zaczynającym się od litery M " (givenname=*sztof)(title=*dr*)"- znajdź wszystkie obiekty o imieniu kończącym się sztof lub tytule naukowym zawierającym wyrażenie dr(domyślnie klasy inetorgperson, ponieważ tylko ona posiada wymienione w filtrze atrybuty) W projekcie wykorzystaliśmy framework Django, oparty na pythonie. Dostęp do bazy danych oraz operacje wyszukiwania udostępnia moduł python-ldap(klient API LDAP). Operacja łącznia z bazą danych ldap następuje przy pomocy polecenia: con = ldap.initialize( ldap://localhost:389 ) Wyszukiwanie z kolei jest możliwe przy pomocy komendy: con.search s( dn, ldap.scope SUBTREE, filtr,[lista szukanych atrybutów])