• Scomposizione del Sistema. 

DNS Server.

I 2 server Administrator.

L'insieme dei nodi del dominio di amministrazione.

• Struttura del Codice. 
• Test. 

Le classi implementate sono :

• DNS : istanzia la classe DNSCommon per creare gli oggetti comuni ai thread che gestiscono le connessioni con i 2 Admin.Si e' gestita la concorrenza tramite il metodo ruoloDisponibile() invocato dai thread AscoltoReg .Questi attendono la connessione degli Admin per la fase di registrazione. Quando si connetteranno si invia loro il ruolo disponibile (secondo una politica FCFS), insieme all'insieme degli indirizzi ip dei nodi da amministrare.

• AdminApp : istanzia la classe Admin che in base agli argomenti passati da linea di comando(NameServer address, NameServer port) tenta una connessione al NameServer . Viene invocato il metodo registrazione() che gestisce il protocollo di comunicazione con il NS . 

• Nodo: Si istanzia un oggetto comune Common ai thread successivamente creati .In questo oggetto si implementano dei metodi che permettono di sincronizzare tra loro i thread.
• Si crea un ClassLoader personalizzato instanziando la classe CaricaClassi(). Questo è il cuore del progetto : infatti si è dovuto implementare un Caricatore di Classi con specifiche di sicurezza, per avere un ambiente sicuro in cui sia possibile implementare le proprie politiche di sicurezza.Solo l'Administrator possiede il diritto di editare le politiche e propagarle ai nodi.
• Questi oggetti vengono passati ai 3 thread : 
• ThreadCaricaClassi : suo compito è caricare delle classi tramite il classloader precedentemente creato.
• ThreadRicevePolitica : rimane in ascolto di una possibile connessione con l'Admin, pronto a ricevere nuove politiche.Quando arrivano le aggiorna nel sistema e chiama il thread StoppaClassi.
• ThreadStoppaClassi : suo compito è stoppare le classi in esecuzione e farle ripartire con le nuove politiche.

Problematiche del progetto:

     Il nodo cruciale del progetto è stato implementare un SecureClassLoader in grado  di caricare le classi on demand e su cui applicare una propria politica di sicurezza.

    Si è usato il modello di sicurezza del Java Development Kit 1.2 che costituisce una architettura per l'implementazione del principio del minimo privilegio.Questa prevede la specificazione da parte dello sviluppatore di una norma di sicurezza, in base alla quale concedere alle applicazioni diversi gradi di accesso alle risorse, a seconda della fonte dei programmi stessi e dell'identità di chi li ha firmati. Per specificare una norma di sicurezza è sufficiente modificare l'apposito file di configurazione java.policy(<java.home>\lib\security\java.policy) 

    Il contenuto del file della norma di sicurezza è costituito da una serie di istruzioni, definite voci di assegnazione, che identificano i permessi associati al codice, in base alla sua provenienza e all'identità dei suoi firmatari.Nel nostro caso, inizialmente si è lasciato il java.policy originale nei Nodi da amministare, poi si è simulato il fatto che l'Administrator abbia editato le politiche e quindi si sono propagate ai nodi (pol2.policy).In questo file di nuove politiche si sono cambiate le voci di assegnazione, in particolare si è fatto in modo che nessuna classe  potesse scrivere su un un file appartenente al path specificato(path="D:/code/Test5").

grant CodeBase "file:D:/code/Test5" {
permission java.io.FilePermission "D:\\Code\Test6","read, delete, execute"; };

    Così quando il Nodo riceve la nuova politica dal MasterAdministrator , stoppa tutte le classi caricate dal SecureClassLoader, aggiorna la politica(*) e le rimette in esecuzione dall'inizio. Si è constatato che al momento di ricaricare le classi, la classe che deve leggere un file in ingresso e copiarlo su un altro non ha piu' i permessi per farlo e la JVM effettivamente avverte negando il permesso di scrittura.

Problemi riscontrati:

     Non si è riusciti ad implementare un metodo che facesse il refresh della nuova politica a run-time. L'unica soluzione trovata è stata quella di terminare il processo in esecuzione sul nodo e farlo ripartire con il comando:

java -Djava.security.manager -Djava.security.policy="url newpolitica" NodoApp

Sorgenti zippati:

Riferimenti bibliografici :

per il meccanismo di class loading e protection domain si è fatto riferimento a :

Li Gong "JDK 1.2 Security Architecture" .

Li Gong "Java Security:present and near future" . 

Li Gong "Secure Java Class Loading".

Roland Schemers "Implementing protection domains in the JDK 1.2".

per la programmazione client/server e threads.

Bruce Eckel "Thinking in Java ".

Jamie Jaworski "Java 2:tutto e oltre" .

Jim Farley "Java distributed computing" .