LDAP, Toruń 27.06.2003 Indeksowanie ogólnopolskich zasobów LDAP Maja Górecka-Wolniewicz, UCI UMK Zadanie 26.

Prezentacja na temat: "LDAP, Toruń 27.06.2003 Indeksowanie ogólnopolskich zasobów LDAP Maja Górecka-Wolniewicz, UCI UMK Zadanie 26."— Zapis prezentacji:

1 LDAP, Toruń 27.06.2003 Indeksowanie ogólnopolskich zasobów LDAP Maja Górecka-Wolniewicz, UCI UMK Zadanie 26

2 LDAP, Toruń 27.06.2003 LDAP jako usługa rozproszona Wirtualna centralizacja zasobów Dostęp poprzez URL-e ldap://..../ Wykorzystanie rekordu DNS typu SRV (RFC 2782) w strefie domeny – RFC 3088: OpenLDAP Root Service, An experimental LDAP referral service (implementacja w OpenLDAP >= 2.0) RFC 3088 – rekord SRV _ldap._tcp.example.net IN SRV 0 0 389 ldap.example.net. – nazwa wyróżniona jest odwzorowywana na pełną kwalifikowaną nazwę domeny (algorytm działa wyłącznie dla nazw domenowych!) – na podstawie rekordu SRV można generować referral, czyli odesłanie do konkretnego serwera LDAP Dyrektywa referral w konfiguracji slapd.conf – referral – adres serwera, do którego kierujemy, gdy bieżący serwer nie może odpowiedzieć na zapytanie

3 LDAP, Toruń 27.06.2003 Ogólnopolska usługa white-pages Obiekty należące do klasy referral w bazie danych Jednostki typu UMK, PWr zarządzają gałęzią c=PL Na poziomie c=PL są wpisywane instytucje, np. na UMK: – o=Uniwerstytet Mikołaja Kopernika w Toruniu, c=PL zwykły wpis, należący do klas organization i pleduOrg – o=Politechnika Wrocławska, c=PL wpis sterujący o postaci: dn: o=Politechnika Wrocławska, c=PL objectClass: referral objectClass: extensibleObject ref: ldap://acc.pwr.wroc.pl/o=Politechnika%20Wroc\c5\82awska,c=PL

4 LDAP, Toruń 27.06.2003 Referrale Wyszukiwanie wpisów będących referalami wymaga podania opcji –M (ManageDsaIT Control) w poleceniu ldapsearch, np.: ldapsearch -M -x "(objectclass=referral)" '*' ref Podążanie za referralami: – polecenie ldapsearch z opcją –C (chase referrals) ldapsearch -b "c=PL" -x -C sn=sadowska 1.1 – w gatewayu LDAP-WWW jest zaimplementowane

5 LDAP, Toruń 27.06.2003 Serwer indeksujący – zasadność Czy w sieci akademickiej jest potrzebny specjalny serwer indeksujący? Czy chcemy budować ogólnopolską akademicką usługę white- pages à la X.500? – ochrona danych – kompletność danych Co z danymi potrzebnymi do uwierzytelniania / autoryzacji via LDAP? czy jest potrzebny lepszy mechanizm niż URL-e serwerów LDAP i obiekty typu referral? Czy danych będzie na tyle dużo, że warto myśleć o specjalnym rozwiązaniu? Element istotny: możliwość doboru danych udostępnianych przez serwery indeksowania na podstawie obowiązujących zasad ochrony danych

6 LDAP, Toruń 27.06.2003 Funkcje systemu indeksującego System indeksujący powinien spełniać następujące funkcje: – zbieranie danych z różnych serwerów katalogowych – udostępnianie wskazań do tych danych w wygodnej postaci Na podstawie systemu indeksującego mogłyby powstać scentralizowane interfejsy WWW ułatwiające dostęp do zasobów

7 LDAP, Toruń 27.06.2003 Projekt Desire II Projekt o zasięgu europejskim: Development of a European Service for Information on Research and Education – 10 partnerów europejskich Cel: – budowa systemu systemu indeksującego (Distributed Index System) – posadowienie w każdym kraju serwera z pełnym indeksem danych – integracja usług informacyjnych – zarządzanie metadanymi – dostarczenie usługi White Pages na podstawie indeksu istniejących serwerów katalogowych w Europie

8 LDAP, Toruń 27.06.2003 System indeksowania Desire II – komponenty LDAPCrawler – gromadzenie obiektów z różnych serwerów LDAP – zebrane dane zostaną skonwertowane do postaci plików LDIF, zawierających odsyłacze (referrals) wskazujące konkretne wpisy w oryginalnych serwerach LDAP Serwer LDAP – przechowuje odsyłacze w postaci obiektów TIO (Tagged Index Object, RFC 2654) – obiekty TIO są generowane na podstawie zasobów LDAP zgromadzonych przez LDAPCrawlera, powstają przez konwersję plików LDIF za pomocą konwertera LDIF/TIO – obiekty TIO są przekazywane z LDAPCrawlera do serwera odsyłaczy TIO za pomocą protokołu CIP (Common Indexing Protocol, RFC 2651) – serwer odsyłaczy TIO może zawierać obiekty TIO z wielu instytucji

9 LDAP, Toruń 27.06.2003 Serwer odsyłaczy Funkcje: – zwykły serwer LDAPv3 – klienci LDAPv3 uzyskują dostęp do serwera odsyłaczy – specjalny interfejs API umożliwia komunikację z serwerem odsyłaczy poprzez protokół HTTP

10 LDAP, Toruń 27.06.2003 NEEDS Nordic Enhanced Educational Directory Service – roczny projekt – cele: stworzenie infrastruktury usługi katalogowej opartej na indeksacji, aby ułatwić przeszukiwanie w ramach środowiska akademickiego, znalezienie efektywnego sposobu połączenia wszystkich istniejących serwerów LDAP Oprogramowanie – podejście oparte na protokołach CIP i TIO – programy lims, tags, gather gather i tags – do zbierania danych z serwerów LDAP i tworzenia obiektów indeksowych TIO lims – serwer indeksów, rozszerzony LDAP serwer, klient kontaktuje się z nim jak ze zwykłym serwer LDAP