RFC 4512 - LDAP: modelli informativi della directory
Gruppo di lavoro sulla rete K. Zeilenga
Richiesta di commenti: 4512 OpenLDAP Foundation
Rende obsoleti: 2251, 2252, 2256, 3674 Giugno 2006
Categoria: Percorso di standardizzazione
Lightweight Directory Access Protocol (LDAP): modelli informativi della directory
Stato del presente memorandum
Il presente documento specifica per la comunità Internet un protocollo
nel percorso di standardizzazione Internet e sollecita discussioni e
suggerimenti per migliorarlo. Per lo stato e il livello di
standardizzazione del protocollo, consultare l'edizione corrente degli
«Internet Official Protocol Standards» (STD 1). La distribuzione del
presente memorandum non è soggetta a limitazioni.
Avviso sul copyright
Copyright (C) The Internet Society (2006).
Sommario
Il Lightweight Directory Access Protocol (LDAP) è un protocollo
Internet per l'accesso a servizi di directory distribuiti che operano
in conformità con i modelli di dati e di servizio X.500. Il presente
documento descrive i modelli informativi della directory X.500 così
come vengono utilizzati in LDAP.
Indice
Introduzione .....................................................3
1.1. Relazione con le altre specifiche LDAP ......................3
1.2. Relazione con X.501 .........................................4
1.3. Convenzioni .................................................4
1.4. Produzioni ABNF comuni ......................................4
Modello delle informazioni utente della directory ................6
2.1. Albero informativo della directory ...................7
2.2. Struttura di una voce .......................................7
2.3. Denominazione delle voci ....................................8
2.4. Classi di oggetti ...........................................9
2.5. Descrizioni degli attributi ................................12
2.6. Voci alias .................................................16
Schema della directory ..........................................22
4.1. Definizioni dello schema ...................................23
4.2. Sottovoci di sottoschema ...................................32
4.3. Classe di oggetti 'extensibleObject' .......................35
4.4. Individuazione del sottoschema ................................35
Modello informativo del DSA (server) ............................36
5.1. Requisiti dei dati specifici del server ....................36
Altre considerazioni ............................................40
6.1. Conservazione delle informazioni utente ....................40
6.2. Nomi brevi .................................................41
6.3. Cache e shadowing ..........................................41
Linee guida per l'implementazione ...............................42
7.1. Linee guida per i server ...................................42
7.2. Linee guida per i client ...................................42
Considerazioni sulla sicurezza ..................................43
Riferimenti normativi ..........................................45
Appendice A. Modifiche .............................................47
A.1. Modifiche rispetto alla RFC 2251 ...........................47
A.2. Modifiche rispetto alla RFC 2252 ...........................49
A.3. Modifiche rispetto alla RFC 2256 ...........................50
A.4. Modifiche rispetto alla RFC 3674 ...........................51
Introduzione
Il presente documento tratta i modelli informativi della directory
X.500 [X.501] così come sono utilizzati dal Lightweight Directory
Access Protocol (LDAP) [RFC4510].
La directory è «un insieme di sistemi aperti che cooperano per fornire
servizi di directory» [X.500]. Le informazioni contenute nella
directory sono collettivamente denominate base informativa della
directory (Directory Information Base, DIB). Un utente della directory,
che può essere una persona o un'altra entità, accede alla directory
tramite un client (o agente utente della directory (Directory User
Agent, DUA)). Per conto dell'utente della directory, il client
interagisce con uno o più server (o agenti di sistema della directory
(Directory System Agents, DSA)). Un server conserva un frammento della
DIB.
La DIB contiene due categorie di informazioni:
1) informazioni utente (ad esempio, informazioni fornite e amministrate dagli utenti). La Sezione 2 descrive il modello delle informazioni utente; 2) informazioni amministrative e operative (ad esempio, informazioni utilizzate per amministrare e/o gestire la directory). La Sezione 3 descrive il modello delle informazioni amministrative e operative della directory.
Questi due modelli, denominati modelli informativi generici della
directory, descrivono come le informazioni vengono rappresentate nella
directory. Tali modelli generici costituiscono un quadro di riferimento
per altri modelli informativi. La Sezione 4 tratta il modello
informativo del sottoschema e il rilevamento del sottoschema. La
Sezione 5 tratta il modello informativo del DSA (server).
Altri modelli informativi X.500 (come i modelli informativi relativi
al controllo degli accessi, alla conoscenza della distribuzione e alla
conoscenza della replica) possono essere adattati all'uso in LDAP. La
specifica di come tali modelli si applichino a LDAP è demandata a
documenti futuri.
1.1. Relazione con le altre specifiche LDAP
Il presente documento è parte integrante della specifica tecnica LDAP
[RFC4510], che rende interamente obsoleta la specifica tecnica LDAP
precedentemente definita dalla RFC 3377.
Il presente documento rende obsolete le Sezioni 3.2 e 3.4 della
RFC 2251, nonché parti delle Sezioni 4 e 6. L'Appendice A.1 riassume le
modifiche a tali sezioni. La parte restante della RFC 2251 è resa
obsoleta dai documenti [RFC4511], [RFC4513] e [RFC4510].
Il presente documento rende obsolete le Sezioni 4, 5 e 7 della
RFC 2252. L'Appendice A.2 riassume le modifiche a tali sezioni. La parte
restante della RFC 2252 è resa obsoleta da [RFC4517].
Il presente documento rende obsolete le Sezioni 5.1, 5.2, 7.1 e 7.2
della RFC 2256. L'Appendice A.3 riassume le modifiche a tali sezioni.
La parte restante della RFC 2256 è resa obsoleta da [RFC4519] e
[RFC4517].
Il presente documento rende interamente obsoleta la RFC 3674.
L'Appendice A.4 riassume le modifiche apportate dopo la RFC 3674.
1.2. Relazione con X.501
Il presente documento include materiale tratto da [X.501], con e senza
adattamenti, nella misura necessaria a descrivere questo protocollo.
Tali adattamenti (e ogni altra differenza qui presente) si applicano a
questo protocollo e soltanto a questo protocollo.
1.3. Convenzioni
Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" nel presente
documento devono essere interpretate come descritto nel BCP 14
[RFC2119].
Le definizioni dello schema sono fornite utilizzando i formati di
descrizione LDAP (come definiti nella Sezione 4.1). Le definizioni qui
riportate sono formattate (con righe mandate a capo) per facilitarne la
lettura. Le regole di corrispondenza e le sintassi LDAP a cui fanno
riferimento tali definizioni sono specificate in [RFC4517].
1.4. Produzioni ABNF comuni
Diverse sintassi del presente documento sono descritte mediante la
forma Backus-Naur aumentata (Augmented Backus-Naur Form, ABNF)
[RFC4234]. Queste sintassi (così come varie sintassi definite in altri
documenti) si basano sulle seguenti produzioni comuni:
Gli identificatori di oggetto (OID) [X.680] sono rappresentati in LDAP
mediante un formato decimale puntato conforme alla seguente ABNF:
numericoid = number 1*( DOT number )
I nomi brevi, noti anche come descrittori, vengono utilizzati come alias
più leggibili degli identificatori di oggetto. I nomi brevi non fanno
distinzione tra maiuscole e minuscole e sono conformi alla seguente ABNF:
descr = keystring
Quando è possibile specificare un identificatore di oggetto oppure un
nome breve, si utilizza la seguente produzione:
oid = descr / numericoid
Sebbene la forma sia generalmente preferibile quando l'uso è
limitato a nomi brevi che fanno riferimento a identificatori di oggetti
dello stesso tipo (ad esempio, descrizioni di tipi di attributo, di
regole di corrispondenza o di classi di oggetti), la forma
dovrebbe essere utilizzata quando gli identificatori possono
identificare più tipi di oggetti o quando non è disponibile un nome
breve (descrittore) non ambiguo.
Le implementazioni SHOULD trattare come non riconosciuti i nomi brevi
(descrittori) utilizzati in modo ambiguo (come discusso sopra).
I nomi brevi (descrittori) sono trattati ulteriormente nella Sezione 6.2.
2. Modello delle informazioni utente della directory
Come afferma [X.501]:
Lo scopo della Directory è contenere, e rendere accessibili, informazioni su oggetti di interesse (objects) presenti in un certo «mondo». Un oggetto può essere qualsiasi cosa identificabile (a cui si possa assegnare un nome). Una classe di oggetti (object class) è una famiglia identificata di oggetti, reali o concepibili, che condividono determinate caratteristiche. Ogni oggetto appartiene ad almeno una classe. Una classe di oggetti può essere una sottoclasse di altre classi di oggetti; in tal caso, i membri della prima classe, la sottoclasse, sono considerati anche membri delle seconde, le superclassi. Possono esistere sottoclassi di sottoclassi, e così via fino a una profondità arbitraria.
Una voce di directory (directory entry), ossia una raccolta di informazioni
dotata di nome, è l’unità informativa fondamentale conservata nella
Directory. Esistono più tipi di voci di directory.
Una voce oggetto (object entry) rappresenta un oggetto specifico. Una voce
alias (alias entry) fornisce un nome alternativo. Una sottovoce (subentry)
contiene informazioni amministrative e/o operative.
L’insieme delle voci che rappresentano la base informativa della directory
(Directory Information Base, DIB) è organizzato gerarchicamente in una
struttura ad albero denominata albero informativo della directory (Directory
Information Tree, DIT).
La Sezione 2.1 descrive l’albero informativo della directory.
La Sezione 2.2 tratta la struttura delle voci.
La Sezione 2.3 tratta la denominazione delle voci.
La Sezione 2.4 tratta le classi di oggetti.
La Sezione 2.5 tratta le descrizioni degli attributi.
La Sezione 2.6 tratta le voci alias.
2.1. L’albero informativo della directory
Come osservato sopra, la DIB è composta da un insieme di voci organizzate
gerarchicamente in una struttura ad albero denominata albero informativo
della directory (DIT); più precisamente, un albero i cui vertici sono le
voci.
Gli archi tra i vertici definiscono le relazioni tra le voci. Se esiste un
arco da X a Y, la voce in X è l’immediata superiore di Y e Y è l’immediata
subordinata di X. Le voci superiori di una voce sono la sua immediata
superiore e le superiori di quest’ultima. Le voci subordinate sono tutte le
sue immediate subordinate e le rispettive subordinate.
Analogamente, la relazione superiore/subordinata tra le voci oggetto può
servire a derivare una relazione tra gli oggetti rappresentati. Le regole di
struttura del DIT possono disciplinare le relazioni tra gli oggetti.
Nota: l’immediata superiore di una voce è detta anche genitore della voce,
mentre l’immediata subordinata è detta anche figlio della voce. Le
voci con lo stesso genitore sono dette sorelle.
2.2. Struttura di una voce
Una voce consiste in un insieme di attributi contenenti informazioni
sull’oggetto rappresentato. Alcuni attributi rappresentano informazioni
utente e sono detti attributi utente (user attributes). Altri rappresentano
informazioni operative e/o amministrative e sono detti attributi operativi
(operational attributes).
Un attributo è formato da una descrizione dell’attributo (un tipo e zero o
più opzioni) e da uno o più valori associati. Spesso un attributo viene
indicato mediante la sua descrizione. Per esempio, l’attributo 'givenName'
è costituito dalla descrizione 'givenName' (il tipo di attributo 'givenName'
[RFC4519] e zero opzioni) e da uno o più valori associati.
Il tipo di attributo determina se l’attributo può avere più valori, la
sintassi e le regole di corrispondenza usate per costruirne e confrontarne i
valori, nonché altre funzioni. Le opzioni indicano sottotipi e altre funzioni.
I valori di attributo sono conformi alla sintassi definita per il tipo di
attributo.
Due valori di uno stesso attributo non possono essere equivalenti. Due
valori sono considerati equivalenti se e solo se corrisponderebbero secondo
la regola di corrispondenza per uguaglianza del tipo di attributo. Se il tipo
di attributo non definisce tale regola, due valori sono equivalenti se e
solo se sono identici. (Per altre limitazioni, vedere la Sezione 2.5.1.)
Per esempio, un attributo 'givenName' può avere più valori; questi devono
essere Directory Strings e non distinguono tra maiuscole e minuscole. Un
attributo 'givenName' non può contenere sia "John" sia "JOHN", poiché tali
valori sono equivalenti secondo la regola di corrispondenza per uguaglianza
del tipo di attributo.
Inoltre, nessun attributo deve avere un valore non equivalente a se stesso.
Per esempio, 'givenName' non può avere come valore una Directory String che
includa il punto di codice REPLACEMENT CHARACTER (U+FFFD), poiché una
corrispondenza che coinvolga tale stringa risulta Undefined secondo la
regola di corrispondenza per uguaglianza dell’attributo.
Quando un attributo viene usato per denominare la voce, uno e un solo valore
dell’attributo viene impiegato per formare il nome distinto relativo
(Relative Distinguished Name). Tale valore è detto valore distintivo
(distinguished value).
2.3. Denominazione delle voci
2.3.1. Nomi distinti relativi
Ogni voce è denominata relativamente alla sua immediata superiore. Questo
nome relativo, detto nome distinto relativo (Relative Distinguished Name,
RDN) [X.501], è composto da un insieme non ordinato di una o più asserzioni
di valore di attributo (attribute value assertions, AVA), ciascuna formata
da una descrizione di attributo con zero opzioni e da un valore di attributo.
Le AVA sono scelte in modo da corrispondere ai valori di attributo della voce
(ciascuno dei quali è un valore distintivo).
Il nome distinto relativo di una voce deve essere univoco tra tutte le
immediate subordinate della sua immediata superiore (cioè tra tutte le
voci sorelle).
Seguono esempi di rappresentazioni testuali di RDN [RFC4514]:
L’ultimo è un esempio di RDN multivalore, cioè composto da più AVA.
2.3.2. Nomi distinti
Il nome pienamente qualificato di una voce, detto nome distinto
(Distinguished Name, DN) [X.501], è la concatenazione del suo RDN e del DN
della sua immediata superiore. Un nome distinto identifica senza ambiguità
una voce nell’albero. Seguono esempi di rappresentazioni testuali di DN
[RFC4514]:
Un alias, o nome alias, è «un nome per un oggetto, fornito mediante l’uso di
voci alias» [X.501]. Le voci alias sono descritte nella Sezione 2.6.
2.4. Classi di oggetti
Una classe di oggetti è «una famiglia identificata di oggetti (o oggetti
concepibili) che condividono determinate caratteristiche» [X.501].
Come definito in [X.501]:
Le classi di oggetti sono usate nella Directory per vari scopi: - descrivere e classificare gli oggetti e le voci che vi corrispondono; - ove opportuno, controllare il funzionamento della Directory; - disciplinare, insieme alle specifiche delle regole di struttura del DIT, la posizione delle voci nel DIT; - disciplinare, insieme alle specifiche delle regole di contenuto del DIT, gli attributi contenuti nelle voci; - identificare classi di voci che l’autorità amministrativa competente deve associare a una determinata politica. Una classe di oggetti (una sottoclasse) può derivare da una classe di oggetti (la sua superclasse diretta), a sua volta derivata da una classe ancora più generica. Per le classi strutturali, il processo termina con la classe di oggetti più generica, 'top' (definita nella Sezione 2.4.1). L’insieme ordinato delle superclassi fino alla classe più alta di una classe di oggetti costituisce la sua catena di superclassi (superclass chain). Una classe di oggetti può derivare da due o più superclassi dirette (superclassi che non appartengono alla stessa catena). Questa caratteristica della relazione di sottoclasse è detta ereditarietà multipla (multiple inheritance).
Ogni classe di oggetti identifica l’insieme degli attributi che devono
essere presenti nelle voci appartenenti alla classe e l’insieme di quelli
che possono essere presenti. Poiché una voce deve soddisfare i requisiti di
ogni classe cui appartiene, una classe di oggetti eredita dalle superclassi
gli insiemi degli attributi consentiti e obbligatori. Una sottoclasse può
rendere obbligatorio un attributo consentito dalla superclasse. Se un
attributo appartiene a entrambi gli insiemi, la sua presenza è obbligatoria.
Ogni classe di oggetti appartiene a uno di tre tipi: astratta (Abstract),
strutturale (Structural) o ausiliaria (Auxiliary).
Ogni classe è identificata da un identificatore di oggetto (object
identifier, OID) e, facoltativamente, da uno o più nomi brevi (descrittori).
2.4.1. Classi di oggetti astratte
Come suggerisce il nome, una classe astratta fornisce una base di
caratteristiche dalla quale si possono definire altre classi che le
ereditano. Una voce non può appartenere a una classe astratta a meno che non
appartenga a una classe strutturale o ausiliaria che eredita da essa.
Le classi astratte non possono derivare da classi strutturali o ausiliarie.
Tutte le classi strutturali derivano, direttamente o indirettamente, dalla
classe astratta 'top'. Le classi ausiliarie non derivano necessariamente da
'top'.
Segue la definizione della classe di oggetti 'top' (vedere la Sezione 4.1.1):
( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
Tutte le voci appartengono alla classe astratta 'top'.
2.4.2. Classi di oggetti strutturali
Come afferma [X.501]:
Una classe di oggetti definita per l’uso nella specifica strutturale del DIT è detta classe strutturale. Le classi strutturali sono usate per definire la struttura dei nomi degli oggetti delle voci conformi. Una voce oggetto o alias è caratterizzata da una e una sola catena di superclassi strutturali, che ha una singola classe strutturale come classe più subordinata. Questa è detta classe strutturale della voce. Le classi strutturali sono correlate alle voci associate: - una voce conforme a una classe strutturale deve rappresentare l’oggetto del mondo reale vincolato da tale classe; - le regole di struttura del DIT fanno riferimento unicamente alle classi strutturali; la classe strutturale di una voce serve a specificarne la posizione nel DIT; - la classe strutturale di una voce, insieme a una regola di contenuto del DIT associata, serve a controllare il contenuto della voce. La classe strutturale di una voce non deve essere modificata.
Ogni classe strutturale è una sottoclasse, diretta o indiretta, della classe
astratta 'top'.
Le classi strutturali non possono essere sottoclassi di classi ausiliarie.
Ogni voce appartiene alla propria classe strutturale e a tutte le classi
della catena di superclassi di quest’ultima.
2.4.3. Classi di oggetti ausiliarie
Le classi ausiliarie servono ad ampliare le caratteristiche delle voci.
Sono comunemente usate per ampliare gli insiemi degli attributi la cui
presenza è obbligatoria o consentita in una voce. Possono descrivere voci o
classi di voci.
Le classi ausiliarie non possono essere sottoclassi di classi strutturali.
Una voce può appartenere a qualsiasi sottoinsieme delle classi ausiliarie
consentite dalla regola di contenuto del DIT associata alla classe
strutturale della voce. Se alla classe strutturale non è associata alcuna
regola di contenuto del DIT, la voce non può appartenere ad alcuna classe
ausiliaria.
L’insieme delle classi ausiliarie cui appartiene una voce può cambiare nel
tempo.
2.5. Descrizioni degli attributi
Una descrizione di attributo è composta da un tipo di attributo (vedere
la Sezione 2.5.1) e da un insieme di zero o più opzioni di attributo
(vedere la Sezione 2.5.2).
Una descrizione di attributo è rappresentata dalla seguente ABNF: