21.2.1 La struttura delle informazioni

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

Ad esempio, la definizione dell’attributo commonName è riportata di seguito

attributetype ( 2.5.4.3 NAME ( 'cn' 'commonName' ) SUP name )
La parte 2.5.4.3 NAME ('cn' 'commonName') definisce l’identificatore dell’attributo. 2.5.4.3 è l’OID (Object IDentifier) che identifica univocamente l’attributo e cn e commonName sono degli identificatori mnemonici (univoci) che permettono un più agevole riferimento all’attributo stesso. Il primo nome specificato, in questo caso cn, è detto primary 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 ) )
La parte 2.5.6.2 NAME 'country' definisce l’identificatore della classe. Il valore 2.5.6.2 è l’OID (Object IDentifier) che identifica univocamente la classe, mentre country è un identificativo mnemonico, anch’esso univoco, che semplifica i riferimenti alla classe.

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.

La parte SUP top indica che la classe in questione discende dalla classe top, dalla quale eredità le caratteristiche e gli attributi.

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 )
Come è logico aspettarsi, top non deriva da nessun’altra classe.

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 )
La parte DESC 'RFC2247: domain component object' specifica una breve descrizione sull’uso della classe.

Analogamente a quanto avviene per le classi, anche gli attributi possono essere definiti sempre all’interno degli schemi.