Rozproszona usługa katalogowa a indeksowanie zasobów LDAP

Protokół X.500, z którego wyrósł LDAP definiował specjalne atrybuty przechowujące dane potrzebne do lokalizacji serwerów usługi. LDAP wykorzystuje popularny sposób lokalizacji usług poprzez adresy URL. RFC 2255 określa postać identyfikatorów URL (Uniform Resource Locator). Format URL LDAP reprezentuje operacje przeszukania bazy katalogowej w celu pobrania określonej informacji. Łańcuch definiujący URL do bazy LDAP zawiera:

1. schemat LDAP wskazany napisem ldap;
2. nazwę serwera LDAP oraz port, na którym nasłuchuje serwer;
3. nazwę wpisu - jednoznaczną wyróżnioną nazwę obiektu;
4. listę atrybutów, których wartości nas interesują;
5. zakres przeszukania: base, lub one, lub sub;
6. filter przeszukania.

Przykładowym URL-em jest:

ldap://ldap.uci.uni.torun.pl/o=Uniwersytet%20Miko%c5%81aja%20Kopernika%20w%20Toruniu?dn?sub?(objectclass=eduperson)

Serwer LDAP ldap.uci.uni.torun.pl nasłuchuje w tym przypadku na domyślnym porcie 389, dlatego nie jest potrzebne jego podawanie. Podstawą przeszukania jest drzewo danych Uniwersytetu Mikołaja Kopernika w Toruniu (nazwę wyróżnioną podano w notacji zgodnej z RFC 1738, tzn. "nielegalne" znaki URL-a, jak np. spacja oraz znaki spoza strony kodowej ASCII są zapisywane w postaci kodu szesnastkowego poprzedzonego znakiem '%'). Zapytanie dotyczy nazwiska (atrybut sn). Przeszukiwane jest całe poddrzewo danych (parametr sub), a wyszukanie następuje za pomocą filtra (objectclass=eduperson).

Za ostatnim parametrem URL-a LDAP można umieścić, po znaku '?', dodatkowe parametry, np. nazwę użytkownika, który ma zostać dowiązany do bazy przed przeszukaniem. Szczegóły przedstawiono w RFC 2255.

LDAP URL jest wygodnym mechanizmem nawigacji między serwerami LDAP.

Dyrektywa

referral <url>

umieszczona w pliku w konfiguracji serwera slapd określa odesłanie adresowe do serwera LDAP innego niż bieżący. Takie odesłanie jest przekazywane klientowi, gdy bieżący serwer nie jest w stanie rozstrzygnąć zapytania na podstawie lokalnej bazy danych.
Efektem powyższej dyrektywy jest zwracenie klientowi jako wyniku zapytania tzw. odesłania nadrzędnego (superior referral), w przypadku, gdy serwer nie potrafi udzielić definitywnej odpowiedzi. Klient może posłużyć się otrzymanym adresem i zwrócić się do innego serwera LDAP ze swoim zapytaniem. W podejściu stosowanym w LDAP-ie, klient zawsze pośredniczy w procesie docierania do właściwego serwera danych. Serwery LDAP nie stosują łańcuchowania zleceń (chaining, tryb występujący w usłudze X.500), czyli trybu, w którym serwer, jeśli nie może rozstrzygnąć zapytania, to sam kontaktuje się z innym serwerem LDAP.

Druga postać odesłań adresowych to obiekty należące do klasy referral, które są umieszczane w ramach drzewa danych. W ten sposób są wprowadzane do bazy odsyłacze adresowe dotyczące danych podporządkowanych (subordinate referral). Ich postać jest zgodna z dokumentem RFC 3296. Wpisy zawierające obiekty będące odesłaniami adresowymi należą do klasy referral. Wymagany atrybut tej klasy obiektów to ref, którego wartością jest URL LDAP wskazujący docelowy serwer oraz jego kontekst nazewnictwa (czyli bazowy wpis wyróżniony).
Oto przykładowy wpis zawierający podporządkowane odwołanie adresowe:

dn: o=Politechnika Wrocławska, c=PL
objectClass: referral
objectClass: extensibleObject
o: Politechnika Wrocławska
ref: ldap://acc.pwr.wroc.pl/o=Politechnika%20Wroc\c5\82awska,c=PL

Dodanie do wpisu klasy obiektów extensibleObject pozwala na wprowadzanie dodatkowych atrybutów, jak np. atrybutu o.
Wpisy typu referral umożliwiają generowanie odesłań, które są przekazywane klientom LDAP i używane do kontynuacji przeszukiwań w ramach podporządkowanych serwerów LDAP.

Dokument RFC 3088 pokazuje, jak specjalny, nadrzędny serwer LDAP, zawierający "globalną informację adresową" może wspomagać rozproszony serwis LDAP. Takie podejście okazuje się szczególnie przydatne, gdy nie jest możliwe podanie serwera nadrzędnego dla określonego poddrzewa danych. Zaprezentowany w RFC 3088 system automatyzuje generowanie odesłań adresowych na podstawie informacji o lokalizacji usługi, która może być umieszczana w rekordzie SRV strefy domeny w ramach usługi DNS (RFC 2782). Autor zaleca odejście od stosowania hierarchii organizacyjnej drzewa danych usługi katalogowej i wdrożenie hirearchii domenowej. Poza upraszczeniem procedur rejestracyjnych poszczególnych gałęzi drzewa, pozwoli to również na wykorzystanie serwerów DNS i rekordów SVR do lokalizacji poszczególnych usług. Funkcjonowanie proponowanego systemu opiera się na tym, że przekazuje on odesłania adresowe wygenerowane na podstawie rekordów SRV. Realizuje w tym celu odwzorowanie nazwy wyróżnionej wpisu na pełną kwalifikowaną nazwę domenową. Na przykład, nazwa uid=mgw,dc=uni,dc=torun,dc=pl zostanie przekształcona do napisu uni.torun.pl. Następnie są lokalizowane usługi związane z daną pełną kwalifikowaną nazwą domeny - odbywa się to poprzez zapytanie DNS dotyczące rekordów SRV dla tej domeny. W przypadku domeny uni.torun.pl realizowane jest zapytanie o rekord _ldap._tcp.uni.torun.pl. Pozytywny wynik polega na dostarczeniu jednego lub kilku rekordów o postaci:

_ldap._tcp.uni.torun.pl IN SRV 0 0 389 ldap.uci.uni.otrun.pl

Jeśli nie otrzymamy w odpowiedzi żadnego rekordu, to jest przerywane dalsze przetwarzanie z wynikiem noSuchObject.

Dla każdego otrzymanego rekordu jest tworzony adres URL do LDAP-a, o formacie zgodnym z RFC 2255, np. dla powyższego rekordu SVR, URL ma postać ldap://ldap.uci.uni.torun.pl:389/ - taki URL jest zwracany jako odesłanie adresowe.
Zdaniem autora RFC 3088, DNS jest cennym spoiwem dla LDAP-a i upraszcza tworzenie globalnej usługi katalogowej. Informacja o lokalizacji usług pobierana z DNS-a pozwala konstruować na bieżąco strukturę drzewa danych.
Jeżeli zostanie ustanowiony serwer działający jako tzw. "korzeń" drzewa danych, to inne serwery LDAP mogą korzystać z jego wskazań adresowych poprzez odwołanie do tego serwera np. w dyrektywie referral w konfiguracji serwera.

W latach 1998-2000 był realizowany europejski projekt o nazwie Desire - Development of a European Service for Information on Research and Education. Celem była budowa rozproszonego systemu indeksującego, składającego się z serwerów przechowujących dane uzyskane w procesie indeksowania. Planowano, że w każdym kraju, będzie działał co najmniej jeden serwer indeksujący. Taki indeks danych miał umożliwić kontynuację usługi White Pages, która funkcjonowała w europejskim środowisku akademickim od 1992 roku dostarczając swego rodzaju książkę informacyjno-adresową o pracownikach naukowo-akademickich.
Jednocześnie, system Desire był projektowany dużo szerzej, miał obejmować różne usługi sieciowe, umożliwiać ich integrację i ułatwić wyszukiwanie informacji dowolnego typu.
Efektem projektu było m.in. zaprojektowanie oraz implementacja prototypowego mechanizmu indeksowania. Niestety problemy prawne związane z publikacją danych osobowych dotyczących pracowników akademickich zahamowały wdrożenie systemu. Ustawodawstwa wielu państw, a także prawo Unii Europejskiej wprowadzają istotne ograniczenia odnośnie udostępniania danych osobowych. Często obowiązujące ustawy nie są jednoznaczne w tym zakresie, co również zniechęca do publikacji danych w ramach White Pages. Drugim czynnikiem hamującym popularność White Pages jest szerząca się tendencja do nielegalnego wykorzystywania adresów e-mail do przesyłania tzw. spamów, czyli niechcianej poczty o charakterze reklamowym - właśnie adresy e-mail pracowników naukowych, telefony, adresy pocztowe miały być istotnym komponentem tej bazy danych.
Z drugiej strony, nadal jest popularna idea przywrócenia katalogu adresowo-informacyjnego pracowników naukowo-akademickich Europy, trwają prace nad aspektami prawnymi tego zagadnienia, a wyniki projektu Desire miały być wykorzystane przez działającą przy organizacji TERENA grupę TF-LSD. Grupa ta zajmowała się wdrożeniem protokołu LDAP w sieciach akademickich Europy, m.in. koncentrowała działalność na usłudze White Pages. W 2002 roku zakończyła działalność, zadanie stworzenia infrastruktury serwerów indeksowania wspomagających wyszukiwanie informacji LDAP zostało zawieszone. Polskie środowisko akademickie, wcześniej zgłasiło udział w tym przedsięwzięciu, jednak prace zakończyły się na etapie projektu oraz testów prototypu docelowego systemu, wdrożenie planowanego rozwiązania dotychczas nie nastąpiło. Jednym z programów testowanych przez grupę TF-LSD było oprogramowanie LIMS - serwer odesłań adresowych oparty na protokole CIP (opisany w punkcie 6 tego opracowania).

Zaprojektowany w ramach programu Desire rozproszony system indeksacji zasobów danych ma topologię hierarchiczną i bazuje na technologii LDAP. Serwery indeksów są rejestrowane. Technicznie rozwiązanie opiera się na protokole CIP (Common Index Protocol) i używa mechanizmu TIO (Tagged Index Object).

Podstawowym celem protokołu CIP (RFC 2651) jest ustalenie wspólnego sposobu komunikacji serwerów, które korzystają z odmiennych protokołów do kontaktu z klientami. Wiele argumentów przemawia za tym, by tworzenie wspomagających komunikację indeksów danych, tzw. metadanych, było realizowane przez serwery lokalne, nie przez odległe, dedykowane serwery pełniące funkcję robotów - takie serwery nie mogą działać sprawnie, gdyż nie mają żadnej wiedzy o zawartości indeksowaych danych (kwestia doboru słów kluczowych), nie znają formatu danych, mogą mieć problem z dostępem do pełnych danych, np. wówczas, gdy strony HTML są tworzone dynamicznie na podstawie niezależnej bazy danych. CIP w celu określenia mechanizmu wymiany danych indeksowania pomiędzy serwerami przede wszystkim definiuje typy obiektów danych o postaci umożliwiającej współdzielenie indeksów, drugoplanową sprawą jest zagadnienie transferu takich obiektów. CIP składa się z trzech części:

• definicji typów MIME służących do przechowywania indeksów (RFC 2652) oraz do przekazywania poleceń (najistotniejsze jest zlecenie pobrania indeksu);
• definicji jednego rodzaju obiektu indeksu dla każdego typu danych;
• specyfikacji mechanizmu transportu, np. HTTP, TCP, e-mail (RFC 2653).

Aby można korzystać z protokołu CIP, oprogramowanie musi akceptować: typy MIME zdefiniowane w dokumentach, jeden z rodzajów obiektu indeksu oraz jakiś mechanizm transportu.

Zgodnie z protokołem CIP każdy indeks jest jednym, samodzielnym obiektem indeksu. Taki obiekt może być współdzielony. Sam obiekt indeksu jest definiowany jako obiekt MIME, dzięki czemu może zostać "opakowany" zgodnie z regułami MIME, np. może stać się częścią nowego obiektu typu multipart/mixed oraz może zostać przetransportowany za pomocą dowolnego mechanizmu pozwalającego na transmisję danych tekstowych. Jeśli obiekt indeksu jest binarny, to musi zostać zakodowany (np. przez Base64). Obiekty mogą być szyfrowane i poświadczane podpisem cyfrowym.
Istnieje wiele rodzajów obiektów indeksów, każdy ma specyficzny typ, który jest określany w parametrze application/cip-index-object.
Zastosowanie protokołu MIME pozwala swobodnie dobierać mechanizmy dystrybucji odpowiednie dla aplikacji. Na przykład serwer, który wygenerował obiekt indeksu może przekazać go za pomocą e-maila kierowanego do wszystkich subskrybentów (metoda push, dane są przekazywane niezależnie od subskrybenta). Innym sposobem jest dystrybucja przez protokół HTTP - serwer tworzy pliki z indeksem, nazwy tych plików są np. podane w pliku robot.txt, aby wskazać lokalizację indeksów. Subskrybent sam sprawdza, czy pojawił się nowy obiekt indeksu i pobiera go (metoda poll - subskrybent może przeoczyć aktualizację indeksu i oferować przestarzałe dane). Zastosowanie specjalizowanego protokołu CIP pozwala na wysyłanie komunikatu o zmianie danych w zakresie indeksu do wszystkich subskrybentów. Następnie subskrybent sam decyduje, czy natychmiast pobrać nowe dane, czy zaczekać do czasu zaistnienia innych zdarzeń (model push/poll). Protokół ten pozwala również na negocjowanie przez producenta indeksu i jego subskrybenta zawartości obiektu indeksu na podstawie zlecenia od subskrybenta i praw dostępu ustalonych przez producenta.

Zaletą opisanego sposobu generowania indeksów jest lepsza jakość obiektu indeksu (jest tworzony przez serwer znający specyfikę zasobów). Poza tym obiekt indeksu może być wielokrotnie używany do różnych celów. Najistotniejsze dla poprawnej pracy systemu jest właściwe zaprojektowanie obiektu indeksu. Musi on zawierać wszystkie informacje, które mogą być potrzebne subskrybentom. Często sugerowanym formatem jest wzorzec opisany w RFC 2655, zwany SOIF (Summary Object Interchange Format), który pokazuje nie tylko składnię danych, ale również sposób określania atrybutów. Inną ważną korzyścią zastosowania indeksów CIP jest dostęp producenta indeksów do pełnych danych, również tych przechowywanych w wydzielonych bazach danych.

Rzeczą niezależną od protokołu CIP jest określenie obiektu indeksu, używanego do umieszczania informacji wymienianej przez serwery indeksów. Zajmuje się tym zagadnieniem RFC 2654RFC 2654. Obiekt indeksu powinien umożliwiać realizację przyrostowej aktualizacji. Przedstawiony w tym dokumencie Tagged Index Object zezwala na dokonanie tego typu aktualizacji. Konsekwencją uzyskania tej funkcjonalności jest większy rozmiar obiektu indeksu. Zaletą TIO jest etykietowanie poszczególnych fragmentów informacji za pomocą identyfikatorów, dzięki czemu atrybuty zostają przyporządkowane danemu obiektowi, a serwer indeksów ma szersze możliwości w zakresie przekierowania zlecenia do właściwego miejsca.

Typowo skonfigurowany serwer LDAP jako wynik wszystkich zapytań, na które nie potrafi odpowiedzieć (gdyż nie ma danych dotyczących zapytania) przekazuje odesłanie adresowe do jednego, konkretnego serwera LDAP (umownie - serwera nadrzędnego). Dokument RFC 2654 definiuje mechanizm, według którego serwery LDAP mogą wymieniać między sobą informację indeksowania, pozwalającą na dostarczanie właściwych odesłań adresowych przez taki serwer nadrzędny. CIP wraz z TIO służą do wymiany informacji indeksowania dotyczącej drzewa danych LDAP i wspomagają wydajność nawigacji między serwerami w ramach drzewa danych katalogowych. Mechanizm TIO jest uniwersalny, może być również z powodzeniem stosowany w odniesieniu do innych usług informacyjnych.
Zanim obiekt TIO będzie przekazywany należy ustalić zasady obowiązujące dostawcę obiektu (supplier) oraz jego odbiorcę (consumer). Powstaje uzgodnienie dotyczące komunikacji serwerów, w ramach którego m.in. określa się:

• index-type: typ indeksu, wg RFC 2654 jedynym możliwym typem jest x-tagged-index-1;
• dsi (dataset identifier): unikatowy identyfikator wskazujący podrzewo i zakres (OID);
• base-uri: co najmniej jeden identyfikator URI, który będzie służył do tworzenia korzenia odesłania adresowego konstruowanego na podstawie obiektu indeksu danego uzgodnienia (w przypadku LDAP-a base-uri to nazwa serwera i jego obiekt bazowy, np. c=PL;
• supplier: nazwa oraz port serwera dostawcy, ewentualnie zastępczego serwera utrzymującego dany kontekst nazewnictwa;
• consumeraddr: identyfikator URI o postaci mailto: z adresem mailowym serwera konsumenta;
• updateinterval: czas w sekundach między dwiema kolejnymi aktualizacjami, upłynięcie tego czasu oznacza, że indeks jest przedawniony;
• attributeNamespace: jeśli kilka serwerów indeksowania ma oferować pewne specyficzne indeksy, to te serwery muszą między sobą uzgodnić wspólny zbiór nazw atrybutów używanych w obiektach indeksów;
• consistencybase: sposób utrzymywania spójności indeksu w trakcie aktualizacji przyrostowej:
  • complete - każda zmiana dotycząca obiektu musi zawierać wszystkie elementy tego obiektu;
  • tag - każda przyrostowa aktualizacja następująca po pełnej aktualizacji musi zawierać informację o stanie znaczników (tags), obiekt w oryginalnej bazie musi mieć zawsze przypisany ten sam numer znacznika;
  • unique - każdy obiekt musi mieć unikatową wartość ustalonego atrybutu w indeksie (np. DN - wyróżniona nazwa obiektu).
• securityoption: wskazuje czy dostawca ma szyfrować lub poświadczać cyfrowo aktualizacje przekazywane do serwera, dopuszczalne opcje to: "nie", "PGP/MIME" (aktualizacja podpisana cyfrowo i szyfrowana za pomocą techniki PGP), "S/MIME" (aktualizacja podpisana cyfrowo i szyfrowana za pomocą techniki S/MIME), "SSLv3" (aktualizacja podpisana cyfrowo i szyfrowana za pomocą techniki SSLv3), "Fortezza" (aktualizacja podpisana cyfrowo i szyfrowana za pomocą techniki Fortezza).

Aktualizacja indeksu to komunikat zawierający obiekt MIME o typie application/cip-index-object, przekazywany z parametrami: type, dsi oraz base-uri.

W części 4.3 RFC 2654 przedstawiono szczegółową składnię służącą do opisu obiektu TIO, a w części tego dokumentu 5 zaprezentowano przykłady konwersji plików w formacie LDIF do postaci TIO.

Zadaniem serwera odesłań adresowych zaprojektowanego w ramach programu Disire było przekierowywanie klientów do właściwego serwera, zawierającego poszukiwane dane. Podstawowym elementem architektury jest serwer odesłań adresowych (referral server), odgrywający rolę usługi pośredniczącej w realizacji zapytania. Serwer taki jest rozbudowanym serwerem LDAP (np. zgodnym z projektem OpenLDAP), z jednej strony potrafi przyjmować zlecenia od klientów LDAP i udziela odpowiedzi w tym protokole, z drugiej, za pomocą protokołu HTTP kontaktuje się z demonem działającym zgodnie z mechanizmem TIO. Do przekazywania obiektów TIO służą protokoły CIP oraz HTTP. Indeksy są generowane na rodzimych serwerach LDAP przez specjalne programy zbierające dane (LdapCrawler) - konstruują one pliki w formacie LDIF, które są następnie konwertowane do postaci obiektu TIO. Obiekt TIO jest przekazywany do serwera odesłań adresowych za pomocą zlecenia HTTP POST z komunikatem MIME type=application/index.obj.tagged, z parametrami base-uri, np. base-uri="ldap://host/o=abc,c=pl", oraz dsi. Globalny serwer odesłań adresowych zawiera obiekty wygenerowane na podstawie różnych baz LDAP i umożliwie szybie przekierowanie klienta do docelowego serwera LDAP, niezależnie skąd pochodzi zapytanie.

Przedstawione w skrócie rozwiązanie, szczegółowo opisane na stronie SURFnetu pt. "Search Engines The Ldap- and TIO server communication", wymaga rozbudowy możliwości serwera LDAP. Niezbędne są również skrypty do konwersji LDIF - TIO CIP, skrypty serwera HTTP do zapamiętywania i pobierania obiektów TIO poprzez HTTP oraz skrypty serwera HTTP i pomocnicza baza danych do przeszukiwania zmagazynowanych TIO. Przedstawione rozszerzenia pozwolą na uzyskanie nowej funkcjonalności - powstanie mechanizm nadrzędnego serwera odesłań adresowych do obiektów rozproszonej bazy LDAP. Taki serwer może znacząco przyspieszyć nawigację pomiędzy serwerami LDAP i obniżyć czas obsługi zleceń.

Głównym celem rocznego projektu NEEDS, realizowanego przez środowisko akademickie krajów skandynawskich było:

• zaprojektowanie i wdrożenie wspólnej infrastruktury katalogowej LDAP opartej na indeksacji zasobów w celu poprawy efektywności przeszukiwania;
• stworzenie dokumentacji, podręczników obrazujących korzystanie z usługi katalogowej.

Najwięcej uwagi poświęcono kwestii połączenia istniejących, lokalnych usług katalogowych, w jedną, wirtualnie scentralizowaną usługę. Podsumowaniem wyników jest dokument NEEDS, z 25.07.2002. W trakcie implementacji projektu główny nacisk został położony na zbudowanie wysokiej jakości oprogramowania indeksującego, opartego na protokole CIP i obiektach TIO. Powstały podstawowe elementy, niezbędne do działania systemu indeksacji: oprogramowanie centralnego serwera indeksów (wspierające protokół LDAP) oraz oprogramowanie do generowania indeksów na podstawie zawartości baz LDAP. Największym problemem okazało się stworzenie dobrego mechanizmu dystrybucji indeksów do głównego serwera, który z jednej strony będzie wygodnym narzędziem dla administratorów, służącym do automatycznego zbierania danych z serwerów LDAP, z drugiej, będzie zgodny z obowiązującym prawodawstwem w zakresie ochrony danych prywatnych.

W projekcie NEEDS używane było oprogramowanie napisane przez Rolanda Hedberga (Catalogix) - pakiet LIMS (testowany również przez grupę TERENA TF-LSD). W skład tego oprogramowania, zgodnie z tym, co zostało opisane w punkcie 5c, wchodzą:

• serwer indeksowania - lims;
• narzędzia do tworzenia obiektów TIO - tags;
• narzędzia do zbierania informacji z działających serwerów LDAP - gather.

Te elementy tworzą razem rozszerzony serwer LDAP oraz wyszukiwarkę zasobów (search engine). Obiekty TIO są generowane w pobliżu zwykłych serwerów LDAP, a następnie są dostarczane do ich odbiorców - specjalizowanych serwerów LDAP, gromadzących odesłania adresowe. Serwer odesłań adresowych jest miejscem, do którego są kierowane wszystkie zapytania o dane katalogowe. Specjalizowanych serwerów LDAP z odesłaniami adresowymi nie powinno być wiele, np. w projekcie NEEDS mówi się o jednym scentralizowanym serwerze indeksów. Przedstawione rozwiązanie bazuje na tym, że będzie możliwe stworzenie mechanizmów umożliwiających przesyłanie dowolnego typu indeksu między jego producentem a odbiorcą, a także, że klient będzie mógł być w sposób transparentny przekierowany ze swoim pytaniem do właściwego serwera. Zalety takiego podejścia to m.in.: jeden ogólnie znany punkt obsługi zapytań, brak konieczności uzgadniania przestrzeni nazewnictwa, krótka trasa zapytanie-odpowiedź (przy założeniu, że indeksy są poprawnie skonstruowane). Wśród najistotniejszych trudności wymienia się: konieczność uzgodnienia zawartości indeksu (atrybuty, sposób podziału na elementy) oraz potrzeba obsługi odesłań adresowych przez klientów.

Oprogramowanie składające się z programów lims, tags oraz gather nie jest ogólnodostępne. Wyłącznie interfejs WWW, przygotowany w języku PHP, realizujący wyszukiwanie danych LDAP poprzez serwer indeksów jest do ściągnięcia ze strony projektu NEEDS.

Wymiana obiektów TIO oraz uruchomienie centralnego serwera indeksów wiąże się z koniecznością rozstrzygnięcia problemów związanych z ochroną prywatności. Wiele aspektów tego zagadnienia zostało poruszonych w raporcie dotyczącycm prywatności danych, opracowanym w trakcie projektu na podstawie ustawodawstwa krajów skandynawskich oraz dyrektywy Unii Euopejskiej (95/46/EC). Wdrożenie podobnej usługi w polskiej sieci akademickiej wymagałoby podjęcia ustaleń w tym zakresie.

W punktach 5 i 6 przedstawiono przykładowe rozwiązania dotyczące indeksacji zasobów LDAP. Podstawowym ich celem jest poprawa wydajności operacji wyszukiwania danych, gdy mamy do czynienia ze strukturą rozproszonych serwerów LDAP. Pod względem technicznym najlepszym podejściem jest zastosowanie uniwersalnego protokołu CIP oraz mechanizmu TIO do obudowywania obiektów indeksu. Wprawdzie implementacje takich systemów nie są ogólnodostępne, ale wydaje się, że przygotowanie odpowiedniego oprogramowania nie byłoby czasochłonne. Największym problemem jest organizacja przedsięwzięcia, przede wszystkim z punktu widzenia prawnego. Obecnie zasoby LDAP dotyczące pracowników akademicko-naukowych w Polsce są utrzymywane przez jednostki, w których dane osoby pracują i, zgodnie z wykonanymi ekspertyzami prawnymi, nie jest to sprzeczne z obowiązującym w naszym kraju ustawodawstwem. Uruchomienie centralnego serwera indeksów, na wzór tego, co było planowane w projekcie NEEDS, oznaczałoby, że dane (dokładnie indeks danych) byłby magazynowany w bazie niezależnej, nie związanej z właścicielem danych. Musiałby zostać sprecyzowany zakres danych ogólnodostępnych - czyli takich, które mogą być publikowane w sieci bez żadnych ograniczeń. Dotychczasowe ekspertyzy pokazują, że oznaczałoby to, że w sieci Internet byłoby możliwe udostępnianie niewielkiej części zasobów. Taki serwis byłby z powodu zakazu udostępniania danych niekompletny, a fakt, że w ogóle istnieje stwarzałby wrażenie, że jest nieaktualny, zaniedbany. Z tego powodu pozostawienie baz LDAP przy instytucjach, których dane dotyczą wydaje się obecnie najlepszym rozwiązaniem. Nie będzie to stanowiło wielkiego utrudnienia, jeśli wiemy, w jakiej uczelni pracuje poszukiwana osoba, gorzej, gdy nie wiemy, czy nie pamiętamy tego. Wówczas globalna usługa wyszukiwania, bazująca na indeksach danych zbieranych z różnych serwerów byłby idealnym rozwiązaniem. Uruchomienie systemu indeksacji i wdrożenie go być może będzie istotnym zadaniem w przyszłości, gdy zostaną uporządkowane kwestie ochrony danych osobowych.
Przedstawione rozwiązania dotyczące indeksowania mogą również docelowo znaleźć zastosowanie w systemach służących do automatycznego uwierzytelniania oraz autoryzacji użytkowników poprzez zasoby LDAP, np. w celu dostępu do chronionych stron WWW. W takim przypadku centralny serwer indeksów gromadziłby np. identyfikatory sieciowe użytkowników powiązane z odesłaniami adresowymi do serwera przechowywującego całość danych o użytkowniku. Poświadczenie tożsamości odbywałoby się poprzez dowiązanie z właściwym hasłem do rodzimego serwera LDAP danego użytkownika. istnineie sugerowałoby