3. Specifica dei Requisiti



3.1 Gestione dei nomi

Il progetto è stato pensato per lavorare in un’organizzazione limitata, ad esempio un’azienda o un’università.

Poiché in tutte le organizzazioni di questo tipo sono presenti determinati confini di località (ad esempio uffici, distretti, dipartimenti…...) introdurremo un Sistema di Nomi Gerarchico, tipo il DNS (Domain Name System) utilizzato in Internet. Dividiamo quindi in domini limitati lo spazio di nomi degli utenti che utilizzano il servizio. La suddivisione in domini è puramente logica e non avviene secondo principi di effettiva vicinanza fisica (ad es. suddivisione in reti o sottoreti).

Lo spazio dei nomi dei domini appare dunque come una struttura ad albero: il dominio “radice” di partenza viene suddiviso in sottodomini di primo livello. La suddivisione può poi avvenire per ciascun sottodominio.

Nell’esempio (una possibile organizzazione universitaria) il dominio radice (indicato con “.”) ha tre sottodomini di primo livello, mentre il dominio “phys” ne ha due (“students” e “admin”). Da notare che ogni sottodominio fa parte del dominio di livello superiore. L’unica limitazione per quanto riguarda lo spazio dei nomi è che questi non possono essere ripetuti in domini che derivano dallo stesso dominio di livello superiore.

Per quanto riguarda gli utenti essi sono indicati da un nome unico nell’ambito del dominio di appartenenza, seguito dal simbolo "@", e dal cammino assoluto che dal dominio radice porta al dominio di appartenenza.

E’ rispettato il requisito di trasparenza: gli utenti sono individuati da nomi logici e non fisici, la corrispondenza tra nomi logici e fisici (indirizzo IP) è realizzata dal DNS.

La comunicazione avviene più frequentemente tra utenti dello stesso ufficio o dipartimento (ecc.), e solo in alcuni casi coinvolge utenti in ambiti differenti. Il DNS gerarchico e il partizionamento dei nomi permettono anche una maggiore efficienza nelle comunicazioni locali a scapito di un peggioramento di quelle “globali”, che comunque sono molto meno frequenti. Rispettiamo così il requisito di scalabilità del sistema.

 

3.2 Come avviene la comunicazione

Il principio di località ci permette di effettuare un partizionamento del database delle chiavi pubbliche.

Ogni dominio è responsabile del mantenimento delle chiavi pubbliche dei propri utenti, perciò avremo un Authentication Server (AS) che mantiene l’associazione

<nome logico - chiave pubblica >

per ogni utente registrato.

Un client (all’interno di un dominio) si rivolge al DNS per ottenere l’indirizzo dell’AS a cui far riferimento per le informazioni richieste.

Ottenuta la risposta il cliente ha a disposizione l’indirizzo dell’AS e può iniziare il protocollo di comunicazione.

In pratica:

 

3.3 Replicazione

La replicazione è realizzata dinamicamente ovvero più AS che svolgono il servizio agendo su una copia della tabella.

Vantaggi di questa realizzazione:

Il tutto avviene in modo trasparente al client.

In prima istanza il problema è comunque stato limitato implementando solo la distribuzione e non anche la registrazione (inserimento) di chiavi pubbliche.