Stručný souhrn dalších informací (poznatky, reference, atd.)

Výběr adresářového serveru

Základní varianty (odkazy viz [5]):

• University of Michigan LDAP implementace
• Netscape Directory Server
• OpenLDAP project

V první fázi jsme se rozhodli pro adresářový server firmy Netscape. Vychází z implementace UMICH, zle říci, že je nejdále v oblasti vývoje a je dobře podporován. V současné době testujeme novou verzi 4.0.

Bohužel se jedná o komerční produkt, nelze získat zdrojové texty (pouze pro klienty a knihovny). Během naší práce na projektu Pleiades se změnila licenční politika a server, který byl dříve pro akademické účely zdarma, se stal značně nákladným.

Jeden z důvodů pro Netscape Directory Server je jeho velmi modulární návrh. Server dává k dispozici několik rozhraní pro implantaci sw modulů (plug-in). Základní struktura (frontend, backend, jednotlivá rozhraní pro plug-in viz příslušná dokumentace ([16])).

Projekt OpenLDAP je založen na architektuře internetového vývojového týmu a slibně se vyvíjí.

Nástroj pro tvorbu aplikací

Zde je situace ještě složitější, nástrojů (prostředků pro vývoj aplikací) je velmi mnoho. Z našeho hlediska jsou zajímavé především dvě větve:

• Systémové skripty, jednodušší aplikace - knihovna pro PERL
  Takových knihoven je několik. Jako velmi dobrá se jeví knihovna PERLDAP, kterou udržuje Netscape v rámci projektu Mozilla. Jedná se o objektově orientovanou knihovnu jejíž návrh dovoluje modulární přístup. Bohužel v testovacím projektu (synchronizační nástroj), kdy je použita pro velkokapacitní změny dat, dochází k problémům se stabilitou.
• Přenositelné aplikace s uživatelským rozhraním - knihovna pro jazyk Java
  Jednou z aktivit projektu Pleiades je i práce na prohlížeči adresářových služeb (directory browser). Vychází z browseru vytvořeného v rámci projektu Globus, který je založen na knihovně JNDI (Java Naming and Directory Interface). Více informací viz odkazy ([5]).

Existuje celá řada základních knihoven pro vývoj aplikací v jazyce C a Java. Příkladem je Netscape Directory SDK (přístupné zdrojové texty v rámci projektu Mozilla) viz [17].

Directory Enabled Networks

Zajímavou aktivitou na poli adresářových služeb je iniciativa výrobců síťových zařízení zvaná Directory Enabled Networks. Její hlavní ideou je vytvoření standardizované informační infrastruktury sloužící pro řízení a konfiguraci síťových prvků. Tato aktivita je zajímavá i proto, že pro její úspěšnou realizaci bude nepochybně potřeba vyřešit řadu z problémů, které byly nastíněny výše v tomto dokumentu (rychle se měnící data, řešení integritních omezení, atd.). Více informací viz [18], základní návrh viz [19] a dokonce návrh rozšíření schématu pro DEN viz [20].

Kompatibilita se standardním schématem

Mezi hlavní výhody adresářových služeb patří nesporně kompatibilita, standardizace sémantiky dat uložených v adresářových službách. Na druhou stranu z mnoha hledisek je dobré využít otevřenosti adresářových služeb a definovat vlastní datový model pro reprezentaci dat s ohledem na (relativně) specifické cíle. Příkladem takových dat jsou informace o lidech. Návrh reprezentace těchto dat, který byl nastíněn v předcházejícím textu, není příliš kompatibilní s existujícími klienty (většina moderních poštovních klientů apod.).

Řešením této situace může být zavedení virtuálních pohledů, tj. speciálního podstromu, v němž jsou data (například o lidech) uvedena znovu, ale v jiném (standardním) formátu. To s sebou samozřejmě nese nutnost zajistit konzistenci těchto pohledů na data mezi sebou navzájem (není však zřejmě problém, aby virtuální pohledy byly pouze pro čtení).

Reprezentace skupin uživatelů

Je třeba navrhnout reprezentaci skupin uživatelů, která je obecnější a flexibilnější, než dosud existující (standardizované) metody. Zřejmě je nutné vytvořit virtuální větev skupin reprezentující skupiny nějakým jednoduchým způsobem - pro běžné klienty (mail, ...).

Základní vlastnosti, které jsou potřeba:

• Skupina ve skupině - musí být možné, aby členem skupiny mohla být jiná skupina.
• Mechanismus pro řízení práv manipulace se skupinami - každá skupina musí mít definovánu (obecně) skupinu, které určuje její administrátory. Tento bod souvisí s celkovou realizací autorizace v rámci adresářových služeb, která je nepochybně vázaná na definici skupin uživatelů. Jedná se o jeden z primárních cílů (hierarchický management, delegace práv pro správu systému).
• Mechanismus dynamických skupin založených na definici členů skupiny prostřednictvím LDAP URL je rozumným řešením některých problémů (viz návrh významu atributu mgrpDeliverTo).
• Pro naše účely je potřeba definovat mechanismus pro přiřazení vlastností skupinám. Zřejmě nejvhodnější bude návrh vycházející z mechanismu pro reprezentaci vlastností zdrojů. Tj. každé skupině může být přiřazena dvojice klíč-hodnota reprezentující vlastnost, přičemž vlastnosti skupiny jsou promítány na její členy. Je zřejmě rozumné takto moci vlastnosti definovat i samotným objektům typu uživatel a stanovit pravidla pro skládání jednoho obrazu vlastností uživatele z vlastností jemu odpovídajícího objektu a skupin jichž je členem.

Další poznámky:

• Je třeba rozhodnout o způsobu záznamu informace o členství ve skupině (atribut u objektu typu uživatel, u objektu typu skupina, apod...).
• Shrnutí základních informací a odkazů k této problematice lze nalézt v [21].