Zanim przejdę dalej rozwinę jeszcze temat modelu danych – a wiec napiszę teraz trochę o strukturze drzewa, atrybutach, klasach obiektu oraz wpisach.
Fundamentalną strukturą danych w LDAP jest DIT (ang. Directory/Data Information Tree). Zbudowana jest ona w sposób hierarchiczny z obiektów nazywanych wpisami (ang. entry). Wierzchołek drzewa nazwany jest korzeniem (ang. root, inne nazwy to base lub suffix). Każdy wpis posiada jeden wpis rodzica (ang. parent entry) i może posiadać jeden lub więcej wpisów potomnych (ang. child entries). Każdy wpis potomny jest rodzeństwem dla innych wpisów potomnych swojego rodzica.
Ponieważ temat LDAP będę rozwijał w oparciu o serwer OpenLDAP, wspomnę teraz o schematach, klasach obiektowych, atrybutach i wpisach.
Zacznijmy od schematów (ang. Schemas). Aby serwer wiedział z jakich klas obiektowych może korzystać, musi mieć zdefiniowane schematy. Wewnątrz nich zdefiniowane są klasy obiektów wraz z atrybutami.
Dla przykładu w schemacie ‘core.schema’ zdefiniowana jest klasa obiektowa ‘organizationalUnit’:
objectclass ( 2.5.6.5 NAME ‘organizationalUnit’
DESC ‘RFC2256: an organizational unit’
SUP top STRUCTURAL
MUST ou
MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
x121Address $ registeredAddress $ destinationIndicator $
preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
telephoneNumber $ internationaliSDNNumber $
facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $
postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) )
Wygląda dziwnie, ale spróbuję rozebrać ten zapis na czynniki pierwsze.
Klasy obiektowe
Każda klasa posiada swój unikalny identyfikator obiektu (ang. Object identifier, OID) – czyli w naszym przykładzie ‘2.5.6.5’. Następnie mamy opis (ang. desctription). Kolejny zapis definiuje obiekt nadrzędny oraz typ klasy. Klasa obiektu może być w jednym z 3 typów – strukturalna (ang. Structural), pomocnicza (ang. Auxiliary) lub abstrakcyjna (ang. Abstract). Typ abstrakcyjny jest typem używanym jako klasa nadrzędna dla innych klas. Najbardziej znaną klasą abstrakcyjną jest klasa ‘top’, która tworzy najwyższy poziom w hierarchii klas. Każdy obiekt musi należeć do jednej (i tylko jednej) klasy strukturalnej, która opisuje obiekt (wpis). Klasa pomocnicza rozszerza obiekt o kolejne atrybuty.
Klasy obiektowe sa zbiorem atrybutów i definiują które z tych atrybutów sa obowiązkowe (MUST), a które opcjonalne (MAY).
Czyli nasza klasa ‘organizationalUnit’ jest klasą strukturalną, dziedziczy z klasy ‘top’ i wymaga atrybutu ‘ou’.
Atrybuty
Jak już wiemy, każdy atrybut zdefiniowany jest w jednej lub większej ilości klas obiektowych. Może być obowiązkowy lub opcjonalny. Może być jednowartościowy lub wielowartościowy (domyślnie). Aby móc użyć atrybutu we wpisie, wpis musi zawierać także informację o klasie do której należy. To są właściwie najistotniejsze informację dotyczące atrybutów. Ale dla dopełnienia dodam. Atrybuty mogą dziedziczyć. I tak dla przykładu nasz atrybut ‘ou’ z klasy ‘organizationalUnit’ dziedziczy z atrybutu ‘name’. Dodatkowo definicja atrybutu zawiera takie dane jak typ (np. string, liczba, JPEG), reguły dopasowania (czyli czy dana wartość jest na przykład zależna od wielkości liter), aliasy czy też przez jakie klasy obiektu jest używana.
Wpis
Na sam koniec doszliśmy do pojęcia wpisu. Trochę powtórzę wcześniejsze informację. Wpis musi być zbudowany z jednej i tylko jednej klasy strukturalnej. Może zawierać dowolną ilość klas pomocniczych oraz może zawierać tylko jedną klasę abstrakcyjną. To pociąga za sobą konsekwencję dotyczącą wymaganych atrybutów. Wpisy mogą posiadać wpisy potomne (znajdujące się poniżej w hierarchii drzewa), wpis rodzica (znajdujący się powyżej w hierarchii) oraz wpisy będące na tym samym poziomie czyli rodzeństwo.
Z pewnością temat nie został całkowicie wyczerpany. Specjalnie pominąłem wiele zagadnień, ale dla podstawowego zobrazowania jak wygląda LDAP to powinno wystarczyć. Przyszedł czas na krótsze artykuły mające bardziej postać how-to.
