La caratteristica fondamentale di un directory service è quella relativa al fatto che le informazioni da esso gestite sono del tipo “write-once, read-many”, ovvero si tratta della gestione di un database, o DIB (Directory Information Base), sostanzialmente statico, cioè le cui informazioni in esso memorizzato subiscono poche variazioni.
Le informazioni contenute nel DIB sono organizzate in una gerarchia di oggetti, detti anche entry, che costituisce un albero detto DIT (Data Information Tree), la cui entry di base è detta root (o base). Quindi, ogni entry, eccetto la root, avrà un’altra entry dalla quale deriva (la entry padre).
... figura ...
Ogni entry è un’istanza di una o più classi (object class), che a loro volta possono, o meno, contenere degli attributi (attribute). Un attributo è identificato da un nome (eventualmente abbreviato) e contiene delle informazioni (data). Le caratteristiche delle classi, dei loro attributi e delle regole di controllo sui valori delle informazioni in essi contenute, sono descritte per mezzo di definizioni ASN.13, contenute all’interno di opportuni file detti schemi (directory schema). Il server LDAP dovrà essere opportunamente configurato per tener conto dei vari schemi da utilizzare, così da poter utilizzare le relative classi ed attributi.
Dipendentemente dalla definizione della specifica classe, un attributo può essere obbligatorio o facoltativo e può contenere uno o più valori. Una classe è essenzialmente un insieme di attributi.
I server LDAP generalmente forniscono una serie di classi ed attributi predefiniti, ma è possibile anche definirne dei propri secondo la sintassi illustrata nella RFC 2252.
Ogni entry è identificata univocamente da un DN (Distinguished Name) che si compone dei DN delle entry da cui quella considerata deriva nella gerarchia del DIT. Alcune entry a livello di foglia del DIT possono essere degli alias di altre entry, piuttosto che degli oggetti veri e propri.
La sintassi con la quale è specificato un attributo è quella seguente
attributetype (
OID
[NAME name]
[DESC description]
[OBSOLETE]
[SUP parent_OID]
[EQUALITY matching_rule_OID]
[ORDERING matching_rule_OID]
[SUBSTR matching_rule_OID]
[SYNTAX matching_rule_OID]
[SINGLE-VALUE]
[COLLECTIVE]
[NO-USER-MODIFICATION]
[USAGE ???]
)
dove
|
Per definire dei propri attributi è opportuno richiedere alla IANA il rilascio di un proprio OID, e quindi utilizzare sequenze numeriche che abbiano quello come prefisso, per non incorrere in problemi con OID eventualmente definiti da altri; |
attributetype ( 2.5.4.3 NAME ( 'cn' 'commonName' ) SUP name )
La parte SUP name indica che l’attributo in questione deriva dall’attributo name, cioè ne eredita le caratteristiche.
Analogamente, le classi possono essere definite con la seguente sintassi
objectclass (
OID
[NAME name]
[DESC description]
[OBSOLETE]
[SUP parent_OID]
[ABSTRACT | STRUCTURAL | AUXILIARY]
[MUST attribute_OID]
[MAY attribute_OID]
)
Un esempio di definizione della classe country è riportato di seguito
objectclass ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c MAY ( searchGuide $ description ) )
|
Per definire delle proprie classi è opportuno richiedere un OID per la propria azienda dalla IANA e quindi utilizzare sequenze numeriche che abbiano quello come prefisso, per non incorrere in problemi con altri OID eventualmente definiti da altri. |
STRUCTURAL indica che la objectclass in questione contiene delle informazioni e può essere utilizzata come entry nel DIT. Una classe potrebbe essere dichiarata come ABSTRACT, nel qual caso non può costituire una entry nel DIT (è dichiarata soltanto per poterla ereditare da altre classi più specifiche), o come AUXILIARY, nel qual caso può essere utilizzata con altre classi STRUCTURAL per creare una entry nel DIT, ma non da sola.
La parte MUST c indica che l’attributo c è obbligatorio per una entry di questo tipo.
La parte MAY ( searchGuide $ description ) indica che gli attributi searchGuide e description sono facoltativi per entry di questo tipo.
Un altro esempio, riportato di seguito, è quello della classe top, che costituisce la radice di tutte le classi.
objectclass ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
La classe dcObject è invece definita come di seguito riportato
objectclass ( 1.3.6.1.4.1.1466.344 NAME 'dcObject' DESC 'RFC2247: domain component object' SUP top AUXILIARY MUST dc )
Analogamente a quanto avviene per le classi, anche gli attributi possono essere definiti sempre all’interno degli schemi.