UNIVERSITA’ DEGLI STUDI DI MESSINA
FACOLTA’ DI SCIENZE MM.FF.NN.
CORSO DI LAUREA IN INFORMATICA
____________________________________________________________________
IL PROCESSO TELEMATICO:
REALIZZAZIONE CON J2EE
____________________________________________________________________
Tesi di Laurea Universitaria di:
Alessandro Grosso
Relatore:
Prof. Francesco Pagano
Correlatore:
Prof. Aristotele Malatino
____________________________________________________________________
Anno Accademico 2004 - 2005
INDICE
1. Introduzione Tesi............................................................................................... 2
2. Analisi del problema.............................................................................................3
2.1 Descrizione problema…………………………………………………………. ..3
2.1.2 Contesto…………………………………………………………………….. ..3
2.1.3 Architettura……………………………………………………………...........3
2.2 Flusso informativo……………………………………………………………....8
2.3 Casi d’uso……………………………………………………………….…….. 10
3. Contesto applicativo........................................................................................... 13
3.1 Tecnologie.......................................................................................................... 13
3.1.1 J2EE............................................................................................................... 13
3.1.2 Sicurezza........................................................................................................ 18
3.1.3 Firma digitale................................................................................................. 27
3.2 Strumenti............................................................................................................ 35
3.2.1 WSAD (IDE di sviluppo) .............................................................................. 35
3.2.2 WAS (application server) .............................................................................. 36
3.2.3 Oracle DB e repository (database) ................................................................ 37
3.2.4 OID (directory service) ................................................................................. 37
4. Implementazione Progetto................................................................................ 38
4.1 La web application............................................................................................. 38
4.2 Strutture dati....................................................................................................... 41
4.2.1 l’atto.............................................................................................................. 41
4.2.2 la busta.......................................................................................................... 46
4.2.3 le basi di dati................................................................................................. 49
4.3 Trasmissione busta............................................................................................. 59
4.3.1 upload al PdA................................................................................................ 59
4.3.2 inoltro GC..................................................................................................... 62
4.3.3 inoltro UG..................................................................................................... 65
4.4 Autenticazione.................................................................................................... 67
4.5 Sicurezza............................................................................................................. 73
4.5.1 Architettura.................................................................................................... 73
4.5.2 Smart card..................................................................................................... 74
Riferimenti.............................................................................................................. 79
- bibliografia............................................................................................................. 79
- leggi....................................................................................................................... 81
- risorse web............................................................................................................. 82
-1-
1. INTRODUZIONE
Un ambiente professionale della nostra società che sta attualmente attraversando
una progressiva ma lenta fase di rinnovo degli strumenti adoperati si trova nel
contesto della giustizia italiana. Più precisamente, il processo civile. L’applicazione
delle attuali tecnologie informatiche come la telematica e la crittografia stanno
permettendo di cambiare il modo di operare e lavorare in molti settori. Si ha qui un
passaggio dal processo civile al processo telematico. Il cambiamento non riguarda
le caratteristiche intrinseche o il significato e ruolo di tale strumento giuridico a
disposizione del cittadino, bensì l’innovazione riguarda gli strumenti e il sistema
informativo che sta alla base dello scambio di dati e della comunicazione tra
avvocati e uffici giudiziari.
Questo libro è il risultato finale di un lavoro iniziato quasi un anno fa sul Processo
Civile Telematico. Partendo dalle basi ho attraversato varie fasi per sviluppare un
progetto e arrivare così a questo libro. Infatti, il mio lavoro, dopo uno studio di base
mi ha portato all’approfondimento dell’argomento sotto i vari profili giuridici ma
soprattutto informatici. Partendo da una cultura personale pressoché inesistente sul
processo civile e da una brevissima esperienza di programmazione lato server ho
affrontato man mano i vari scenari che hanno imposto il problema.
Il libro contiene la teoria studiata e l’applicazione della teoria studiata concretizzata
nella web application sviluppata. I vari strumenti usati e le tecnologie adoperate per
sviluppare il progetto vengono descritte e commentate in modo soggettivo
nell’ambito del sistema. I principi e i concetti che fanno parte del progetto sono a
loro volta definiti e spiegati nelle varie sezioni di questo libro. E stata osservata
particolare attenzione agli aspetti prettamente implementativi del progetto.
Il lavoro che ha implicato questo progetto mi ha permesso di sviluppare conoscenze
sul processo civile come strumento giuridico, ma soprattutto di approfondire gli
studi sulle tecnologie offerte dalla piattaforma J2EE.
-2-
2. ANALISI DEL PROBLEMA
•
2.1 – DESCRIZIONE PROBLEMA
2.1.1 CONTESTO
Il progetto Processo Telematico ha per oggetto la realizzazione di un sistema
informativo integrato dell’ufficio giudiziario civile incentrato sulla creazione e
gestione di un fascicolo elettronico, in grado di supportare in modo completo un
processo civile telematico, fondato sul concetto di documento elettronico.
L’archiettettura generale del Processo telematico viene proposta dal Ministero della
Giustizia. Esso è effettivamente un progetto in cui sono coinvolti molti soggetti. Per
la realizzazione di tale progetto, esso riunisce e crea una collaborazione tra figure
professionali quali l’informatico e l’avvocato e chiunque altro sia direttamente o
indirettamente fruitore del futuro servizio.
2.1.2 ARCHITETTURA
Ciò che segue è la descrizione dell’architettura di base prevista dal Ministero della
giustizia, dentro la quale trova posto il progetto sviluppato. Il progetto globale del
Ministero è attualmente in fase di realizzazione.
Il Processo telematico prevede il seguente scenario operativo:
-3-
-4-
Dove:
•
PdA = Punto di accesso
•
GC = Gestore centrale
•
UG = Ufficio Giudiziario
Nella prima fase di sperimentazione, il contesto applicativo, oggetto di analisi e
realizzazione, è limitato al solo Sistema Informativo del Contenzioso Civile (SICC)
presso i Tribunali Ordinari e i Soggetti Abilitati Esterni saranno limitati ai soli
Avvocati.
L’Avvocato può, già a partire dalla prima fase sperimentale:
•
redigere e firmare l’atto di parte: a tal fine si avvale di uno strumento di
redazione (Redattore Atti) integrato con strumenti software per la firma,
cifratura e imbustamento;
•
depositare l’atto di parte (ricevendo la relativa attestazione temporale e
successivamente la ricevuta elettronica di avvenuta presa in carico da parte
dell’Ufficio Giudiziario);
•
ricevere comunicazioni da parte dell’Ufficio Giudiziario nella propria “Casella
di Posta Elettronica del Processo Telematico” (CPEPT);
•
effettuare consultazioni dei fascicoli di propria pertinenza tramite l’evoluzione
del PolisWeb.
L’Avvocato interagisce con il S.I.C. necessariamente per il tramite di un Punto di
Accesso Esterno (PdA), presso cui è registrato come utente nel Registro Locale
degli Indirizzi Elettronici (ReLIndE).
Il PdA è quindi l’unico fornitore dei servizi di interfacciamento del “dominio
giustizia”
per
gli
Avvocati,
autorizzato
ad
operare
su
provvedimento
dell’Amministrazione. Questo in quanto offre ai propri Utenti una schermatura dei
protocolli e dei formati di interfaccia previsti dal PCT per il colloquio con gli Uffici
Giudiziari (UG), salvaguardando i principi di sicurezza e di riservatezza (tramite
autenticazione forte) alla base della specifica problematica applicativa.
-5-
Si precisa che il Punto di accesso è un’entità esterna al S.I.C. (Sistema Informativo
Civile) e non è pertanto fornito dal Ministero della Giustizia, che renderà invece
pubbliche (nelle Regole Tecniche) le relative specifiche. Pertanto il PdA non è
oggetto di fornitura da parte del RTI: il Consiglio dell’Ordine presso ogni sede
pilota indicherà la disponibilità di un PdA per la fase di sperimentazione; in caso
non vi sia questa disponibilità, il RTI renderà comunque disponibile una versione
prototipale in modo da non bloccare la sperimentazione.
Presso il PdA è attivo un Registro Locale degli Indirizzi Elettronici (ReLIndE), che
viene acceduto in fase di autenticazione, in fase di prelievo o consultazione dei
messaggi provenienti dal SIC e in fase di deposito degli atti, per eseguire, se in
possesso dell’albo elettronico del Consiglio dell’Ordine di appartenenza
dell’Avvocato, la certificazione dello status del professionista.
Per quanto attiene alla ricezione di comunicazioni di cancelleria, il PdA fornirà
all’avvocato una casella di posta elettronica certificata in aderenza alle specifiche
dettate dal Centro Tecnico della RUPA, opportunamente adattate per il Processo
Telematico.
Il Gestore Centrale (GC) svolge servizi di cooperazione allo scambio di dati che,
pur non entrando nel merito delle richieste ricevute, consentono di assicurare la
correttezza della composizione delle buste prodotte e di tracciare tutti i flussi
applicativi, verificando il completamento dei relativi cicli logici.
Provvede cioè ad indirizzare le richieste inoltrate dai PdA, e originate dagli
Avvocati, verso gli UG destinatari e viceversa a smistare ai relativi PdA le risposte
o le comunicazioni provenienti dagli UG, sopperendo, grazie ad una architettura
logica e fisica particolarmente robusta, alla eventuale indisponibilità temporanea dei
relativi sistemi di colloquio.
Il GC assolve alla funzione di attestare temporalmente l’evento di ricezione di una
richiesta di deposito di un atto, fornendo in un messaggio di risposta indirizzato alla
CPEPT dell’Avvocato: questa è pertanto da considerarsi la data e l’ora di deposito
dell’atto.
Il GC esegue inoltre, in fase di deposito di un atto, la certificazione sostitutiva del
difensore, nei casi in cui il PdA mittente non sia tenuto, o non sia stato delegato, alla
-6-
gestione dell’albo dell’Ordine professionale di appartenenza dell’Avvocato
mittente. A tal fine è previsto che ciascun Consiglio dell’Ordine inoltri al GC
l’elenco aggiornato dei propri iscritti all’albo.
L’entità rappresentata come Ufficio Giudiziario coincide tecnicamente con il
cosiddetto Gestore Locale, ossia l’insieme di tutti i servizi applicativi del Processo
Telematico esposti sia verso il Gestore Centrale sia verso i soggetti abilitati ed i
sistemi interni.
In particolare all’interno di questa componente vengono realizzati tutti i sottosistemi
per:
• la gestione delle fasi di controllo e accettazione dell’atto di parte;
• l’invio di eventuali eccezioni al mittente;
• la gestione dei diritti di visibilità sui dati;
• l’invio dei biglietti di cancelleria.
Il Gestore Locale gestisce, infine, l’interfacciamento tra il Repository Documentale
(la base dati documentale, contenente tra l’altro il fascicolo informatico) e il SICC
(gestione registri del Contenzioso Civile) per tutto ciò che concerne le operazioni a
disposizione dei soggetti abilitati interni.
L’operatore di cancelleria e il Magistrato si interfacciano alle funzionalità del
Processo Telematico attraverso l’applicativo SICC. Le evoluzioni del SICC
permetteranno infatti l’accesso al fascicolo informatico non più solo come storico
degli eventi, ma anche nel merito del contenuto degli atti di parte.
Il Cancelliere in particolare, potrà intervenire, attraverso componenti specifiche
previste dalle evoluzioni del SICC, per gestire le eventuali situazioni di eccezione
che si possono verificare in fase di ricezione, controllo e accettazione degli atti di
parte.
-7-
•
2.2 – FLUSSO INFORMATIVO
Il presente paragrafo descrive i principali flussi del sistema, rappresentando le
interazioni tra le principali componenti di ciascun sottosistema, seguendo l’iter
logico della redazione e del deposito di un atto. Tengo a sottolineare che questa è la
struttura e il workflow secondo quanto previsto dal Ministero per l’architettura
generale, Il flusso informativo del progettino realizzato viene descritto nel capitolo
quattro dedicato all’implementazione.
I flussi del Processo Telematico possono essere classificati per tipologia in invii
documentali e consultazioni. Dal punto di vista applicativo, la loro principale
differenza è legata all’utilizzo di un differente protocollo di trasporto nella tratta tra
PdA e GC. In particolare, per gli invii documentali, è previsto l’utilizzo di un
meccanismo asincrono, basato sul protocollo SMTP, mentre per le consultazioni, si
prevede l’utilizzo di soli meccanismi sincroni, basati su HTTPS.
Gli avvocati che sono gli attori principali nella generazione del flusso di dati devono
essere muniti di smart card contenente:
•
il certificato per la firma elettronica,
-8-
•
il certificato di autenticazione, per la connessione al Punto di Accesso,
entrambi rilasciati da un certificatore accreditato, in modo da garantire che quelle
determinate credenziali siano riferite ad una persona fisica la cui identità è garantita
dall’insieme dei processi di identificazione attuati dal certificatore stesso.
Allo scopo di mantenere distinte le due funzioni di firma e di autenticazione
(quest’ultima in sostanza necessaria per accedere al Punto di Accesso ed effettuare
operazioni di deposito e consultazione), si è scelto di imporre che ciascun certificato
abbia un PIN di sblocco distinto; pertanto, in pratica, le opzioni sono due:
•
utilizzo di due diverse smart card (una per la firma e l’altra per l’autenticazione);
•
unica smart card purché dotata di due diversi PIN di accesso ai due certificati di
firma e autenticazione.
È opportuno far presente che al momento sul mercato non è ancora disponibile la
seconda possibilità, anche se qualche produttore di smart-card dichiara che la stanno
sperimentando.
Dal punto di vista pratico, dunque, gli Avvocati opereranno su client dotati di
dispositivo di lettura della smart card e, nel momento di connessione al PdA, per il
deposito o la consultazione, inseriranno il proprio PIN (relativo al certificato di
autenticazione) e presenteranno le proprie credenziali con cui verranno autenticati
dal servizio, creando così un canale sicuro basato su protocollo SSLv3.
Gli UG saranno inoltre dotati di chiave e certificati di cifratura1 per consentire che
gli atti depositati vengano cifrati sul client dell’avvocato, con il certificato pubblico
dell’UG destinatario, e che solo quest’ultimo possa procedere a decifrare e leggere
gli atti stessi.
I PdA e il GC sono attestati su rete pubblica (SPC) e specificatamente su
Interdominio RUPA; pertanto l’interazione tra le due entità, tanto in caso di utilizzo
del protocollo sincrono (per le consultazioni dei procedimenti giudiziari) che
asincrono (per gli di invii documentali), fruisce delle garanzie di sicurezza offerta
da tale rete. La tratta GC - UG sfrutta la Rete Unitaria della Giustizia (RUG).
In entrambi i casi si ipotizza comunque di instaurare sui protocolli sincroni una
connessione sicura (SSLv3) mediante mutua autenticazione dei server.
-9-
•
2.3 – CASI D’USO
I diagrammi illustrati in questa sezione definiscono alcune dei contesti applicativi
del sistema.
I diagrammi sono basati sul linguaggio standard UML (Unified Modeling
Language), che è una notazione per analizzare, specificare, visualizzare e
documentare lo sviluppo delle fasi di un progetto sviluppato segendo il paradigma
ad oggetti.
In particolare i diagrammi che seguono sono relativi all’architettura di base proposta
dal Ministero della Giustizia e sono estratti da documenti già esistenti.
La figura che segue è un diagramma di sequenza che evidenzia le varie fasi di
creazione della busta MIME, che contiene l’atto che deve essere trasmesso
attraverso il sistema.
- 10 -
- 11 -
La figura successiva è un diagramma di sequenza che illustra le procedure che
vengono eseguite durante l’inoltro della busta dal Gestore Centrale all’Ufficio
Giudiziario.
- 12 -
3. CONTESTO APPLICATIVO
•
3.1 - TECNOLOGIE
3.1.1 J2EE
La piattaforma di riferimento per la progettazione e lo sviluppo dell’applicazione è
quella offerta dalla SUN, J2EE (Java 2 Enterprise Edition). J2EE non è un
framework, bensi un insieme di specifiche che definiscono un’intera architettura
standard per la progettazione, l’implementazione, il deploy e l’esecuzione di
applicazioni distribuite lato server. L’implementazione di tali specifiche viene fatta
dai vari produttori di piattaforme J2EE.
L’architettura generale della programmazione lato server definita nelle specifiche si
compone di vari elementi strutturali definiti sottostanti ed illustrati nella figura
seguente.
Figura 3.1 Archittetura J2EE
- 13 -
Un application server è un software che, come dice il nome stesso, fornisce l’uso di
applicazioni. Più correttamente è un software atto ad ospitare e quindi ad offrire un
ambiente di esecuzione per programmi sviluppati per il web. In effetti un
application server permette l’installazione (deploy) e la gestione al suo interno di
applicazioni di terzi. Esso è solito essere un back-end per un web server, dal quale
vengono inoltrate le richieste dei client per l’esecuzione di un particolare
programma contenuto in un application server. In quanto un ambiente di runtime
per web applications offre una varietà di servizi generali di cui possono fare uso le
applicazioni ospitate come la gestione sicurezza (es: autenticazione), connessioni a
database, messaging asincrono, servizio di naming, gestione transazione, ecc…
Mentre per il deployer dell’application, offre tools di deployment, di configurazione
e monitoraggio dell’applicazione installata.
Un container è un ambiente d’esecuzione standardizzato per specifici tipi di
componenti come le servlet o gli ejb. Specificatamente si parla di web container per
quelli contenenti servlet e jsp, mentre si parla di ejb container per quelli che
ospitano gli ejb. Uno o più container solitamente si trovano all’interno degli
application server. Il container fornisce vari servizi direttamente ai componenti che
vengono eseguiti e gestiti al suo interno come la gestione del ciclo di vita, sicurezza
e multithreading. I vari container sono standard, descritti quindi nelle specifiche.
Un componente è del codice costruito, strutturato e compilato dallo sviluppatore in
base ad un modello standard definito da una specifica (es: ejb). Esso segue ed
applica i principi della programmazione ad oggetti, in effetti un container è costruito
per funzionare ed eseguire oggetti appartenenti solo ad una super classe, quindi tutti
i componenti per quel specifico container vengono costruiti seguendo uno specifico
modello (da qui il modello a componenti). Ogni oggetto (componente) nel container
deriva dalla super classe per cui è stato realizzato il container. I vari modelli di
componenti sono definiti dalle specifiche.
- 14 -
Un modulo è un raggruppamento di componenti e altre risorse destinati allo stesso
container. Questo raggruppamento rappresenta un’applicazione o parte di essa.
Esso, concretamente, è un archivio compresso (jar) che racchiude al suo interno
oggetti compilati (i componenti), risorse (pagine html, immagini,ecc..) e un
descrittore di deployment. Vi sono definiti tre tipi di moduli nella specifica J2EE,
questi sono: modulo web (.war), modulo ejb (.jar) e modulo client (.jar). Grazie
all’atomicità che si ha con il modulo, si può facilmente trasportarlo, una volta
creato, dall’ambiente di sviluppo all’application server. Ogni modulo può essere
usato come applicazione enterprise stand alone oppure essere aggregato con altri
moduli per formare un applicazione enterprise assemblata da più moduli.
Una applicazione enterprise è un applicazione appunto formata da uno o più moduli
configurati. Essa,a sua volta, ha un suo proprio descrittore di deployment.
L’applicazione enterprise quindi è un altro archivio compresso (.ear) che ingloba i
vari moduli costituenti ed il suo descrittore. La figura 3.2 illustra la struttura di
un’applicazione enterprise J2EE.
Un descrittore di deployment (DD) non è niente altro che un file xml. Il suo
contenuto rappresenta la configurazione per l’installazione in ambiente di runtime
del modulo o dell’applicazione enterprise cui appartiene. Il deployment descriptor,
configurandolo
opportunamente,
permette
di
definire
il
comportamento
dell’applicazione o modulo in fase di runtime. La configurazione riguarda vari
aspetti del deployment come la struttura dell’applicazione, la sicurezza, ecc.. Ad
esempio per quanto riguarda la sicurezza è possibile definire il tipo di
autenticazione richiesta oppure definire quali gruppi di utenti può accedere alle
varie parti dell’applicazioni,ecc.. Le specifiche definiscono la struttura dei
deployment descriptor standard obbligatori con i relativi dtd. Essi sono i seguenti:
application.xml per l’applicazione enterprise, web.xml per un modulo web e ejbjar.xml per un modulo ejb.
- 15 -
Figura 3.2 struttura di un’applicazione J2EE
J2EE delinea anche alcuni ruoli che si trovano coinvolti nell’intera fase di
progettazione, sviluppo e messa in produzione di un’applicazione. Essi sono i
seguenti: Application Component Provider, Application Assembler, Deployer,
Server Provider, Container Provider, System Administrator. E da osservare
comunque che questi ruoli non vengono per forza tutti assegnati a persone distinte
ma alcuni ruoli, specie nelle piccole aziende di sviluppo, possono essere assegnati
ad un’unica persona. Di seguito viene data una breve descrizione del compito di
ciascuna di queste figure.
L’application component provider produce il codice di base all’interno di
un’applicazione J2EE. Esso progetta e scrive il codice dei componenti riusabili
all’interno di diverse applicazioni, solitamente si tratta di uno sviluppatore di EJB e
altri componenti lato server.
L’application Assembler ha il compito di mettere insieme dei componenti
ottenendo così un’applicazione J2EE completa. Egli utilizza dei descrittore
dichiarativi per costruire l’applicazione (i deployment descriptor). Di solito è un
- 16 -
esperto in un determinato dominio applicativo, in maniera tale da fornire soluzioni
per problemi specifici.
Il deployer è colui che si occupa dell’installazione dell’applicazione in uno
specifico ambiente operativo (application server J2EE) del quale è esperto.
Il J2EE Server/Container Provider è il/i venditore/i del database, dell’application
server e del web server. Essi implementano un prodotto J2EE (le specifiche)
fornendo i container dei componenti, le API della piattaforma J2EE e eventuali
interfaccie non definite dalla specifica J2EE. Inoltre fornisce appositi strumenti per
il deployment e la gestione dell’applicazione.
Il System Administrator è il responsabile della configurazione e amministrazione
dell’infrastruttura di rete e di calcolo dell’azienda proprietaria. Egli supervisiona
l’esecuzione delle applicazioni controllandone il comportamento usando strumenti
di supporto.
Lo sviluppo di applicazioni enterprise con la piattaforma J2EE usa il linguaggio
Java come linguaggio di programmazione. Questo permette di sfruttare al massimo
le caratteristiche proprie del linguaggio orientato ad oggetti per sviluppare
applicazioni estendibili e con codice facilmente riusabile. Java è indipendente dalla
macchina su cui viene eseguito, questo perché il codice java viene compilato
(bytecode) per una virtual machine (processore virtuale) che è disponibile per la
quasi totalità dei sistemi operativi. Tutto ciò ha permesso che si sviluppassero
application server uniformi sulle varie architetture di calcolatori il cui sistema
operativo avesse una virtual machine adeguata per Java. Il risultato è il panorama di
oggi, cioè l’esistenza di application server J2EE su Linux, come su Solaris, come su
Windows, ecc.. . Attenzione però, ogni application server non implementa per forza
l’intera specifica J2EE, questo lascia avvolte dei vuoti che fanno la differenza tra un
application server e l’altro. Un altro punto a fare la differenza è l’implementazione
di servizi non definiti nelle specifiche (estensioni proprietarie oppure di standard di
- 17 -
pubblico dominio) ma non per questo non utili. Quest’ultimo fattore è comunque
compromettente al fine della trasportabilità di un applicazione enterprise che ne
faccia uso.
3.1.2 SICUREZZA
La sicurezza ha svolto un ruolo fondamentale nello sviluppo delle soluzioni al
problema. Infatti gran parte del lavoro è stato dedicato alla sicurezza nel contesto
applicativo. In questo luogo la sicurezza non viene affrontata tanto nella sua
componente fisica come architettura dell’intero sistema Processo Telematico, bensì
nelle caratteristiche di alcuni elementi prettamente software oggetto di sviluppo e
gestione.
Infatti la sicurezza nell’ambito del mio progetto ha riguardato sia l’utilizzo, da parte
dell’utente, del sistema, quindi una sicurezza prettamente di interfaccia, sia quella
relativa alla protezione dei dati all’interno dei vari componenti del sistema.
Per quanto riguarda la sicurezza che rappresenta la firma digitale ho preferito
dedicare un paragrafo intero più avanti nel libro. In queste righe vengono affrontati
in particolare modo i concetti di sicurezza in una web application e vengono
illustrati quale è la logica di gestione della sicurezza che le specifiche J2EE
impongono.
La piattaforma J2EE definisce meccanismi di sicurezza per i vari oggetti che la
compongono. Si parla di sicurezza in particolare riferita a due aspetti fondamentali
della programmazione web. Si tratta del controllo degli accessi alle applicazioni e
risorse varie, e della protezione dei dati durante il loro trasporto. Questi due aspetti
globalmente possono essere entrambi affrontati sotto due ottiche: programmatico e
dichiarativo. Programmatico vuol dire che la sicurezza viene gestita direttamente
dallo sviluppatore a livello di codice ed è parte integrante stessa del codice
dell’applicazione. Dichiarativa vuol dire che la politica di sicurezza adottata viene
realizzata al di fuori del codice, più esattamente nei deployment descriptor dove
- 18 -
vengono specificati i requisiti di sicurezza che devono avere i componenti per
essere eseguiti. Nella filosofia dichiarativa i requisiti dichiarati nel deployment
descriptor devono essere soddisfatti dall’application server.
Le due tecniche presentano vantaggi e svantaggi. Il programmatico offre maggior
flessibilità di implementazione dei meccanismi di sicurezza contro una più elevata
complessità per il programmatore nello sviluppo dell’applicazione che deve tener
conto di questo aspetto dato che è lui stesso a dover codificare gli aspetti di
sicurezza
dell’applicazione.
Il
dichiarativo,
al
contrario
presenta
una
semplificazione per lo sviluppatore nella scrittura del codice in quanto egli non deve
preoccuparsi dell’aspetto sicurezza che viene definito configurando appunto i file
esterni. In ogni caso il dichiarativo si affida ai meccanismi di sicurezza
implementati sul application server, quindi la responsabilità della sicurezza viene
trasferita al deployer.
Le due filosofie comunque vengono applicate ai componenti in modo leggermente
diverso in base proprio al tipo di componente trattato. Questo perché ogni modello
di componente ha un ciclo di vita ed una logica di base diversa rispetto ad un altro
(es:una servlet e un ejb). Una cosa molto importante da sottolineare, nella filosofia
dichiarativa, è che i servizi di sicurezza e protezione vengono si implementati e
offerti dai vari application server in modo più vario e diversificato a seconda del
produttore, ma hanno comunque un interfaccia di accesso standard descritta dalle
specifiche. Questo permette a qualsiasi applicazione J2EE di usufruire dei servizi
standard di un application server in modo del tutto trasparente alla loro
implementazione e quindi facilita il porting dell’applicazione tra due application
server J2EE compliant.
La web application realizzata è basata su servlet e pagine JSP, quindi qui di seguito
vengono descritti le possibilità esistenti per garantire un opportuno livello di
sicurezza a questi componenti seguendo la filosofica dichiarativa.
- 19 -
I domini di sicurezza si basano su tre direttive: l'autenticazione dell'utente remoto,
la cifratura dei dati e l'autorizzazione dell’utente all'accesso ai vari servizi.
AUTENTICAZIONE
La specifica SUN prevede, per i servizi a disposizione sull'Application Server, di
poter impostare diversi criteri di sicurezza. Tali criteri sono impostabili nei vari
deployment descriptor che accompagnano le Web Applications o gli Enterprise Java
Beans, oppure in apposite Access Control Lists (ACL) che regolamentano l'accesso
agli altri servizi (ad esempio: uso di un datasource, accesso in lettura o modifica
all'albero JNDI...).
Le modalità a disposizione degli application servers per accertare l'autenticità
dell'utente collegato sono definite nella specifica e si riassumono nelle seguenti 4
parole chiavi definite nel Document Type Descriptor (DTD) della generica Web
Application:
· BASIC
Il server invia una richiesta di autenticazione che viene interpretata dal Browser.
Quest'ultimo presenta all'utente una finestra di popup nella quale inserire username
e password che vengono spediti al server e quest'ultimo può verficarne la
rispondenza con la coppia username/password definita nel proprio registro utenti.
· DIGEST
Questa modalità prevede l'invio della coppia username/password successivamente
ad un procedimento di "Hashing". Questo procedimento consiste nell'applicare un
algoritmo crittografico "one-way" che renda virtualmente impossibile la decodifica.
In questa modalità, simile alla BASIC, si ha il vantaggio di proteggere l'invio della
password.
- 20 -
· FORM
In questo caso il server invia una pagina HTML configurabile contenente una Form
Web dove vengono richieste username e password, la quale va a richiamare, una
volta inviate le informazioni, una servlet di autenticazione fornita dall’application
server e dipendente dal registro utenti configurato sul application server.
Questo metodo è usato quando si vuole presentare all'utente una finestra curata
graficamente realizzata in HTML piuttosto della banale finestrella popup del
browser prevista dalla modalità BASIC
· CLIENT-CERT
In questo caso il server richiede al Browser client l'invio di un certificato digitale
che sarà sottoposto ad opportuno riconoscimento. Il certificato digitale è
sostanzialmente un documento contente la chiave pubblica del client ed i suoi dati
di identificazione (nome,cognome,codice fiscale,ecc..). Esso viene firmato
digitalmente da una Certification Authority riconosciuta e ritenuta fidata
dall’application server cosi essa garantisce che la chiave pubblica corrisponde ai
dati del proprietario dichiarato sul certificato. La certification Authority è un ente
riconosciuto da entrambe le parti come fonte autorevole di validazione della chiave
pubblica; una sorta di "notaio" che certifica (da cui il nome certificato) la validità
della chiave pubblica.
CIFRATURA
Tramite il parametro "transport-guarantee" è possibile impostare il livello di
sicurezza desiderato per la comunicazione tra il client e il server.
I valori ammessi sono i seguenti:
- 21 -
· NONE: la comunicazione avviene in chiaro
· INTEGRAL: viene garantita la non manomissione della comunicazione
· CONFIDENTIAL: viene garantita la riservatezza del dato mediante cifratura
In molti casi, un valore di INTEGRAL o CONFIDENTIAL implica una
Trasmissione su Secure Socket Layer (SSL).
Richiedendo un meccanismo di cifratura, a fronte dei benefici di sicurezza, si
introduce un overhead (sovraccarico) necessario per l'applicazione dell'algoritmo di
cifratura. Questo si traduce con un leggero decadimento delle prestazioni di
comunicazione.
AUTORIZZAZIONI
Nelle Web Applications, i servizi, che siano pagine statiche o dinamiche, possono
essere soggetti ad autorizzazione di accesso su base dichiarativa. Le regole di
accesso vengono definite nel deployment descriptor del modulo che accompagna la
Web Application, come definito dalla specifica Servlet e JSP della SUN.
In tale file è possibile specificare quali "ruoli", possono accedere alla singola URL
(indirizzo univoco di una risorsa). E' anche possibile utilizzare i caratteri jolly per
definire criteri per gruppi di risorse.
Prima di entrare nel dettaglio delle impostazioni di sicurezza relative
all'autorizzazione è opportuno chiarire il concetto di "ruolo".
Nella piattaforma J2EE sono identificati due categorie di servizi principali:
JPS/Servlets e EJB.
Tali servizi, sviluppati spesso da teams diversi e comunque in un arco temporale
significativamente ampio, prevedono spesso la possibilità di accesso da parte di
diverse
categorie
di
utenti
che
prendono
il
nome
di
ruoli.
I servizi di tipo JSP/Servlet o i vari metodi degli EJB possono quindi essere filtrati
- 22 -
dal sistema di gestione della sicurezza che bloccherebbe l'accesso da parte di utenti
non appartenenti ai ruoli ammessi nel deployment descriptor generando una
Security Exception.
Oltre ad aver definito i ruoli autorizzati è però necessario configurare una
equivalenza (mapping) dei ruoli con i relativi utenti o gruppi di utenti definiti
(chiamati "principals") nella piattaforma di accoglienza del componente(gli utenti
del application server). Questo "mapping" avviene nel "custom deployment
descriptor", ovvero un file XML peculiare per l'ambiente J2EE scelto per il
"deployment". La struttura di questo file non è definita secondo uno standard nelle
specifiche e perciò ogni application server ne definisce uno.
Il discorso si amplia nel caso degli Enterprise Java Beans che, essendo dei moduli
software richiamabili remotamente, espongono i diversi metodi necessari
all'implementazione della business logic a differenza delle servlet o delle JSP che
devono
unicamente
gestire
una
HTTP
Request.
Per ciascuno di questi metodi, è pessibile definere, sempre nell'apposito deployment
descriptor, che in questo caso è il file "META-INF/ejb-jar.xml", l'elenco dei "ruoli"
che possono usarli.
I servizi dell'application server che non sono JSP, servlets e EJB, sono invece
generalmente resi disponibili previo controllo da parte dell'application server stesso
tramite delle Access Control Lists (ACL).
Si tratta di liste di utenti o gruppi di utenti che dispongono di determinati permessi
sulle risorse detti "privilegi".
Riassumendo per capire i principi di sicurezza in un application server nei confronti
di una web application bisogna aver ben capito i concetti che vengono usati nel
deployment descriptor dell’applicazione stessa. Essi sono elencati di seguita con
una breve descrizione.
- 23 -
Web resource: componente di un modulo (es: pagina HTML, pagina JSP,
immagine GIF, ecc..)
Web resource collection: insieme di web resource identificate in base ad uno o più
URL pattern (es: /* oppure /index.html) ed uno o più http-method, tipi di accesso
(es: GET, PUT, POST, ecc..) che devono essere protetti.
Security-role: ruolo definito nel deployment descriptor che rappresenta un insieme
di utenti che hanno determinati poteri d’accesso in comune nella web application
Security-constraint: determina quali security-role possono accedere ad una
determinata web resource collection. Viene specificato nel deployment descriptor
del modulo
User-data-constraint: determina come devono essere accedute le web resources
legate ad un security-constraint: confidenzialità, integrità, nessuna protezione (le
prime due indicano che sarà usato SSL o altro protocollo sicuro offerto
dall’application server per la trasmissione delle risorse)
Figura 3.3 utenti e sicurezza in J2EE
- 24 -
SSL
Il protocollo usato per rendere sicuri i canali di comunicazione nell’ambito
dell’intero progetto è l’SSL v3 (Secure Socket Layer versione 3). Mi sembra
doveroso scrivere ciò che è stato appreso su questo protocollo al fine di rendere
completa la descrizione delle tecnologie usate nel progetto.
La descrizione si riferisce alle specifiche della versione 3.0 del SSL di Netscape
Communication Corporation (Società ideatrice del protocollo). E un protocollo che
garantisce la privacy delle comunicazioni su Internet, esso permette infatti alle
applicazioni client/server di comunicare in modo da prevenire le intrusioni, le
manomissioni e le falsificazioni dei messaggi. Il protocollo SSL provvede alla
sicurezza del collegamento garantendo tre funzionalità fondamentali:
• Privatezza del collegamento. La crittografia è usata dopo un handshake iniziale per
definire una chiave segreta. Per crittografare i dati è usata la crittografia simmetrica
(vedi paragrafo sulla Firma digitale).
• Autenticazione. L'identità nelle connessioni può essere autenticata usando la
crittografia asimmetrica, o a chiave pubblica (per es. RSA, DSS, etc.). Così i clients
sono sicuri di comunicare con il corretto server, prevenendo ogni interposizione. E'
possibile la certificazione sia del server che del client.
• Affidabilità. Il livello di trasporto include un check dell'integrità del messaggio
basato su un apposito MAC (Message Authentication Code) che utilizza funzioni
hash sicure (es: SHA, MD5, etc.). In tal modo si verifica che i dati spediti tra client
e server non siano stati alterati durante la trasmissione.
SSL è un protocollo aperto e non proprietario, La versione 3 del protocollo è stato
esaminato
pubblicamente
e
pubblicato
come
Internet
draft
document.
Successivamente, quando è stato raggiunto un ampio consenso per standardizzare il
protocollo (come accade in Internet prima nasce lo "standard de facto" e poi quello
effettivo), è stato formato nell’IETF, il TLS working group, che studia standard
- 25 -
comuni. La prima versione del TLS (1.0) viene vista essenzialmente come una
SSLv3.1, ed è veramente vicino e quindi compatibile alla precedente SSLv3.
Lo scopo primario del SSL Protocol è fornire riserbo ed affidabilità alle
comunicazioni. Il protocollo è composto da due strati (vedi figura 3.4): a livello più
basso, interfacciato su di un protocollo di trasporto affidabile come il TCP, c'è il
protocollo SSL Record. Questo è usato per l'incapsulamento dei vari protocolli di
livello superiore. Sul protocollo SSL Record si interfaccia l'SSL Handshake
Protocol che permette al server ed al client di autenticarsi a vicenda e di negoziare
una cipherSuite (insieme di algoritmi per rendere la comunicazione sicura composta
da: key exchange, bulk encryption e hash) prima che il livello applicazione
trasmetta o riceva il suo primo byte. Un vantaggio del SSL è la sua indipendenza
dal protocollo di applicazione: un protocollo di livello più alto, come HTTP oppure
LDAP può interfacciarsi sul protocollo SSL in modo trasparente.
Figura 3.4 SSL è un protocollo a due strati
Per sfruttare la protezione offerta da SSL è necessario che un sito web disponga di
un server in cui sia integrata la tecnologia SSL. Anche il client deve supportare SSL
per poter stabilire una connessione sicura con un server SSL. Tutti i moderni
browser supportano SSLv3/TLSv1. Con questi mezzi è possibile usare, per
esempio, HTTPS, cioè HTTP con SSL, e scambiare informazioni con un client per
mezzo di HTTPS. Poichè HTTP+SSL e http sono differenti protocolli ed usano
- 26 -
porte diverse, lo stesso sistema server può far girare contemporaneamente sia il
server HTTP+SSL che quello http. Ciò significa che un server può offrire alcune
informazioni a tutti gli utenti senza sicurezza, ed altre solo in modo sicuro: ad
esempio un catalogo può essere "non sicuro" mentre gli
ordini ed i pagamenti devono essere protetti.
Il browser può essere qualunque, purché supporti il protocollo SSL e, quindi, il nuovo
metodo di accesso URL HTTPS per connessioni con un server che usa SSL. Https è il
protocollo che si ottiene interfacciando http su SSL, si dovrà usare "https://" per gli URL
HTTP con SSL, mentre si continuerà adusare "http://" per gli URL senza SSL. La porta di
default per "https" è la numero 443, come stabilito dalla Internet Assigned Numbers
Authority.
3.1.3 FIRMA DIGITALE
In un sistema come quello oggetto di questo studio è fondamentale l’autenticità e
l’integrità dei dati che vengono trasmessi. In altre parole è necessario essere certi
dell’autore dei documenti e garantire che essi non vengano alterati per nessun
motivo pena la non validità del documento. Queste due esigenze vengono
soddisfatte dalla cosiddetta firma digitale. Prima di entrare nel dettaglio di come
essa viene usata nell’ambito del progetto, vengono discussi i concetti generali su i
quali essa si basa e il suo funzionamento, questo per comprendere meglio perché
essa può essere ritenuta affidabile.
La firma digitale è basata sui principi della crittografia, più precisamente della
crittografia a chiave pubblica.
CRITTOGRAFIA
La crittografia è una tecnica attraverso la quale si rendono illeggibili i dati originali,
permettendo al destinatario di recuperarli attraverso un procedimento noto solo a
- 27 -
lui. Si distinguono due forme fondamentali: la crittografia simmetrica, ovvero, a
chiave segreta, e quella asimmetrica, nota meglio come crittografia a chiave
pubblica.
La crittografia simmetrica è quella più semplice da comprendere, e si basa su un
algoritmo che modifica i dati in base a una chiave (di solito una stringa di qualche
tipo), che permette il ripristino dei dati originali soltanto conoscendo la stessa
chiave usata per la cifratura. Per utilizzare una cifratura simmetrica, due persone si
devono accordare sull'algoritmo da utilizzare e sulla chiave. La forza, o la debolezza
di questo sistema, si basa sulla difficoltà o meno che ci può essere nell'indovinare la
chiave, tenendo conto anche della possibilità elaborative di cui può disporre chi
intende spiare la comunicazione.
Figura 3.4 crittografia simmetrica
La crittografia asimmetrica o a chiave pubblica è un metodo molto più complesso,
che però ha il vantaggio di essere più pratico quando riguarda la comunicazione con
molte persone. Il principio di funzionamento si basa sul fatto che esistono due
chiavi complementari, e un algoritmo in grado di cifrare con una chiave e di
decifrare utilizzando l'altra. In pratica, la cifratura avviene a senso unico attraverso
la chiave di cui dispone il mittente di un messaggio, mentre questo può essere
decifrato solo con l'altra che possiede solo il destinatario. Le due chiavi vengono
chiamate chiave pubblica e chiave privata, attribuendogli implicitamente un ruolo
specifico. In pratica, chi vuole mettere in condizioni i propri interlocutori di inviare
dei messaggi, o altri dati cifrati, che poi possano essere decifrati solo da lui o da lei,
dovrà costruire una propria coppia di chiavi, e dovrà distribuire la chiave pubblica.
Chi vuole inviare informazioni cifrate a questa persona, può usare la chiave
- 28 -
pubblica diffusa dal destinatario, e solo chi ha la chiave complementare, ovvero la
chiave privata, può decifrarle. In questa situazione, evidentemente, la chiave privata
deve rimanere segreta a tutti, tranne che al suo proprietario; se venisse trafugata
permetterebbe di decifrare i messaggi che potrebbero essere intercettati.
Figura 3.4 crittografia asimmetrica o a chiave pubblica
La cifratura può anche essere ibrida, utilizzando in pratica entrambe le tecniche.
Per attuarla, di solito si utilizza prima la cifratura simmetrica, utilizzando una
chiave determinata in modo casuale ogni volta, e per questo definita chiave di
sessione. Questa chiave viene allegata al messaggio, o ai dati trasmessi, e viene
cifrata a sua volta (eventualmente assieme agli stessi dati già cifrati) attraverso il
sistema della chiave pubblica, ovvero quello che si basa sulla coppia di chiavi
complementari. Il destinatario di questi dati dovrà fare il percorso inverso,
decifrando la chiave di sessione con la sua chiave privata, e quindi decifrando il
documento utilizzando la chiave di sessione che ha ottenuto dopo il primo
passaggio.
FUNZIONAMENTO FIRMA
A differenza della firma “tradizionale” la firma digitale è diversa per ogni
documento. Essa ha lo scopo di certificare l'autenticità e l’integrità dei dati. Per
ottenere questo risultato occorre garantire, in qualche modo, che l'origine di questi
sia autentica, e che i dati non siano stati alterati dopo l’apposizione della firma. Qui
vengono descritti i passi per firmare un documento. Essi sono due:
•
calcolo di un “riassunto” o “digest” del documento (hash)
- 29 -
•
cifratura dell’hash con chiave privata (firma)
Per dimostrare che un documento elettronico non è stato alterato, si utilizza la
tecnica del codice di controllo (digest), che in pratica è un numero (o una stringa),
che viene calcolata in base al contenuto del documento stesso. Gli algoritmi che
effettuano questo calcolo vengono anche chiamati “funzioni di hash”. L'algoritmo
che genera questo codice di controllo è tanto più buono quanto è minore la
probabilità che due documenti diversi generino lo stesso codice di controllo. Questo
valore è una sorta di “riassunto” matematico del documento elettronico originale, e
può permettere al destinatario di verificare che il documento è giunto intatto,
attraverso il ricalcolo del codice di controllo che deve risultare identico.
La firma elettronica richiede qualcosa in più: si deve poter dimostrare che l'origine è
autentica, e che il codice di controllo non è stato alterato. Evidentemente, per non
creare un circolo vizioso, serve qualcosa in più. Per questo si utilizza di solito la
cifratura del codice di controllo assieme ai dati, oppure solo del codice di controllo,
lasciando i dati in chiaro. Per la precisione, si utilizza la crittografia a chiave
pubblica, chi esegue la firma (cifratura del digest), deve usare la propria chiave
privata (quella segreta), in maniera tale che tutti gli altri possano decifrare il digest
unicamente attraverso la sua chiave pubblica.
Di solito la chiave privata viene usata solo per cifrare il digest, soprattutto perché la
crittografia a chiave pubblica è abbastanza pesante computazionalmente. Per cifrare,
eventualmente, anche il messaggio e garantire così anche la riservatezza dei dati, si
usa la crittografia simmetrica, la cui chiave usata viene comunicata al destinatario
cifrandola con la chiave pubblica di quest’ultimo. La figura 3.5 descrive la firma di
un documento.
- 30 -
Figura 3.5 funzionamento firma digitale applicata ad un documento trasmesso in
chiaro
Naturalmente, una firma elettronica di questo tipo può essere verificata solo se si
può essere certi che la chiave pubblica attribuita al mittente che ha firmato il
documento, appartenga effettivamente a quella persona. In altre parole, un
impostore potrebbe diffondere una chiave pubblica corrispondente a una chiave
privata di sua proprietà, indicandola come la chiave del signor Tizio, e così potrebbe
inviare documenti falsi a nome di questo signor Tizio, che in realtà non
ne è il responsabile. Per risolvere questo problema sono state create le PKI (Public
Key Infrastructure).
Prima di parlare di PKI è bene definire l’oggetto che associa e contiene le
informazioni sul mittente (autore della firma) e la sua chiave pubblica e permette di
pubblicare quest’ultima in un formato standard. Stiamo parlando del certificato
digitale.
Il certificato è il mezzo di cui dispone il destinatario per avere la garanzia
sull’identità del suo interlocutore e per venire in possesso della chiave pubblica di
- 31 -
quest’ultimo. Concretamente esso è un file in uno dei formati standard (es: X.509)
che contiene la chiave pubblica, informazioni sul proprietario (soggetto) della
relativa chiave privata, informazioni sull’intervallo di validità del certificato,
informazioni sull’autorità emittente e firma dell’autorità emittente, oltre ad altri
dati. Il certificato in formato X.509, contiene in uno standard riconosciuto, una serie
di campi per dati obbligatori ai quali possono essere aggiunte ulteriori estensioni per
riportare
informazioni
aggiuntive.
L’autorità
emittente,
anche
chiamata
Certification Authority (CA) è il garante per l’associazione chiave pubblicasoggetto del certificato. In altre parole prova (certifica) che il soggetto dichiarato
nella certificato digitale è il proprietario della chiave pubblica dichiarata nel
certificato, e quindi della relativa chiave privata in suo possesso usata per firmare i
documenti. In termini pratici il certificato del soggetto viene firmato con la chiave
privata dell’autorità di certificazione. Così per un eventuale persona che vuole
verificare la validità e autenticità di una firma, gli è sufficiente verificare l’autorità
emittente del certificato legato alla firma e in base alla fiducia che egli ripone in
questa autorità considerare il certificato, e quindi anche la firma, attendibile oppure
no.
PKI (Publica Key Infrastructure)
Il meccanismo di certificazione appena descritto è alla base di una infrastruttura a
chiave pubblica (PKI). Quindi lo scopo di una PKI è di garantire l’associazione tra
chiave pubblica e soggetto dichiarati nel certificato digitale. Una PKI è un insieme
di apparati, regole di sicurezza, procedure operative e servizi che rendono possibile
la gestione affidabile ed efficiente di applicazioni per la firma digitale,
l’autenticazione, la protezione della riservatezza e la marcatura temporale dei
documenti informatici. Come dice il nome stesso, si basa sulla crittografia
asimmetrica a chiave pubblica e svolge le seguenti funzioni principali.
•
generazione e distribuzione di coppie di chiavi digitali;
•
verifica dell’identità dei richiedenti i certificati;
•
emissione e pubblicazione dei certificati;
- 32 -
•
gestione del ciclo di vita dei certificati (sospensione, revoca, rinnovo)
In ambito pubblico sono le Certification Authority ad implementare una PKI, ma
essa può anche essere implementata per un uso locale come all’interno di una
azienda. Ovviamente implementando una PKI ad uso locale, le operazioni basate su
questa PKI hanno senso e validità solo all’interno dell’azienda stessa. Le CA
pubbliche, in Italia, sono quelle inscritte e pubblicate nel albo dei certificatori tenuto
dal CNIPA (Centro Nazionale per l’Informatica nella Pubblica Amministrazione).
USO DELLA FIRMA DIGITALE
La firma digitale, per essere apposta ad un file, richiede alcuni presupposti. Come è
deducibile da quanto descritto in precedenza è necessario che l’utente sia in
possesso di una coppia di chiave generate secondo un algoritmo di crittografia
asimmetrica (RSA o DH-DSS). Un altro requisito obbligatorio è che l’utente
disponga di un dispositivo hardware o software in grado di usare la chiave privata
per cifrare dei dati con l’algoritmo appropriato. Altro requisito è che la chiave
privata utilizzata per la firma dei documenti informatici venga conservata in
maniera sicura e segreta dal titolare che ne è responsabile. Per ragioni di sicurezza,
la chiave privata si trova nello stesso ambiente dove viene eseguito l’algoritmo di
firma. Per dispositivo software di firma si intende una libreria che implementi
direttamente gli algoritmi di cifratura e che faccia uso della chiave privata
memorizzata, e possibilmente anche protetta da cifratura simmetrica con pwd, in un
file (keystore). Il tutto avviene in un unico PC evitando che la chiave privata venga
trasportata fuori. Per dispositivo hardware di firma si intende un dispositivo come
ad esempio la smart card che contiene la chiave privata ed applica essa stessa
l’algoritmo di cifratura per la firma grazie al suo chip integrato. Anche qui il tutto
avviene in un unico dispositivo senza che sia compromessa la riservatezza della
chiave. La diffusione della chiave pubblica, invece, consente a tutti i possibili
destinatari dei documenti informatici di disporre della chiave necessaria per la
verifica dei documenti. Per individuare in maniera sicura il sottoscrittore del
documento, deve essere legata in maniera certa al titolare della corrispondente
chiave privata.
- 33 -
SMART CARD
Per la normativa italiana con dispositivo di firma si intende "un apparato elettronico
programmabile solo all’origine, facente parte del sistema di validazione, in grado
almeno di conservare in modo protetto la chiave privata e generare al suo interno le
firme digitali".
Uno degli strumenti che è possibile utilizzare come dispositivo di firma è la smart
card crittografica.
La smart card è simile, per forma e dimensioni, ad una tradizionale carta di credito.
A differenza di quest’ultima, incorpora un processore in grado di memorizzare e
elaborare dati ed informazioni, a cui è possibile accedere tramite un codice di
sicurezza riservato e personale (PIN). Il processore della smart card permette
appunto di eseguire gli algoritmi di firma digitale e crittografia usando la chiave
privata memorizzata al suo interno. Inoltre è uno strumento di memorizzazione
molto sicuro, oltre che facilmente portabile e legato al Titolare. La coppia di chiavi
asimmetriche viene generata e memorizzata direttamente al suo interno nella fase di
inizializzazione della carta. Per tutte le ragioni elencate sin qui le smart card
crittografiche, opportunamente protette da PIN di accesso, sono state individuate
come un valido supporto, in quanto oltre a permettere la generazione delle chiavi al
loro interno e l’ applicazione della firma digitale, dispongono di sistemi di sicurezza
che impediscono l’esportazione e la copia della chiave privata, fuori dalla smart
card in cui è stata generata.
La smart card si collega con il computer mediante un apposito lettore ed il relativo
software di interfaccia che le permette di interagire con tutte le applicazioni
realizzate per far uso della smart card. Una descrizione più dettagliata della smart
card adoperata, del suo uso e dei suoi meccanismi di interfacciamento con sistema
operativo
e
software
viene
fatta
nel
l’implementazione del progetto.
- 34 -
capitolo
successivo
riguardante
• 3.2 STRUMENTI
3.2.1 WSAD (IDE di sviluppo)
L’IDE (Integrated Development Environment) usato per sviluppare il progetto di
tesi è il prodotto commerciale offerto dalla IBM, WebSphere Studio Application
Developer v 5.1.2. WSAD (l’abbreviativo) è uno dei prodotti della famiglia
WebSphere Studio che è stato sviluppato sopra il workbench Eclipse.
Il workbenk eclipse è un ambiente di sviluppo progettato dalla IBM e rilasciato alla
comunità degli opensource. E una piattaforma universale che fornisce frameworks,
servizi e strumenti per costruire altri strumenti. WSAD è un ambiente integrato per
lo sviluppo, testing, debugging e deployment delle applicazioni, infatti esso in unico
prodotto fornisce supporto per ogni fasi dello sviluppo dell’applicazione. Esso è
sviluppato in java ed offre tutti i tool e i servizi per sviluppare qualsiasi tipo di
applicazione. I servizi e strumenti che esso mette a disposizione dello sviluppatore
spaziano da quelli dedicati allo sviluppo di applet java allo sviluppo di intere
applicazione J2EE, dalla creazione di file e schemi xml alla gestione di file di
configurazione server, dalla creazione di comandi SQL alla interrogazione di
database direttamente dall’IDE, ecc… Grazie alla possibilità di cambiare la
prospettiva della GUI di WSAD è possibile facilmente passare da un tipo di
sviluppo e prospettiva dati ad un altro. Esso offre molteplici wizard che facilitano e
velocizzano la creazione di codice e permette lo sviluppo organizzato in team grazie
al supporto per CVS (Concurrent Versions System).
Inoltre è uno strumento completo per lo sviluppo di applicazioni web e applicazioni
enterprise. Esso infatti, oltre al supporto per la creazione dei vari componenti come
pagine JSP, servlet, EJB, mette a disposizione un intero ambiente di test
comprendente vari application server tra i quali TomCat v 4.1 e WAS v5.1
(Websphere Application Server), server monitor delle richieste HTTP, strumento di
debug della applicazione enterprise, editor di file di configurazione, strumenti per lo
sviluppo dei web services, ecc…
- 35 -
Tra tutti questi aspetti positivi vi sono anche alcuni lati negativi che tengo a
sottolineare. Essi riguardano la notevole quantità di RAM necessaria e un piuttosto
intenso consumo della risorsa processore che appesantisce parecchio la macchina su
cui è installato l’ambiente di sviluppo. Questi due lati negativi sono comunque
diretta conseguenza che l’intero IDE è sviluppato in java. Un ultimo aspetto
negativo è che nonostante sia un ambiente nato per rendere più veloce e semplice lo
sviluppo di un’applicazione, l’apprendimento iniziale per usare tale strumento non è
così intuitivo e veloce, questo dipende anche dall’immensa mole di servizi e tool
che esso offre.
3.2.2 WAS (application server)
L’application server usato nell’ambito del progetto è WebSphere Application Server
v 5.1. Più correttamente è stato usato quello integrato nell’Application Developer.
Questo per una più veloce fase di sviluppo. Infatti il server integrato nell’IDE
consente allo stesso tempo lo sviluppo, il testing e il debugging delle applicazioni in
fase di sviluppo.
WAS è scritto in java, la virutal machine che mette a disposizione per eseguire le
applicazioni ospitate è un’implementazione della IBM relativa alle specifiche di
J2SE 1.4.1. Il server si basa sull’architettura J2EE 1.3 fornendo e implementando in
modo standard la maggior parte dei servizi descritti nella specifica. Esso, oltre alle
librerie classiche di un ambiente J2EE offre anche delle estensioni per permettere la
gestione di nuovi componenti.
- 36 -
3.2.3 ORACLE DB E REPOSITORY (database)
Il database scelto per l’implementazione del progetto è Oracle 9i (v9.2.0.1). E un
DBMS (DataBase Management System) completo, esso fornisce un sistema di basi
di dati relazionale e anche ad oggetti. Il server Oracle contiene molte funzionalità.
Una JVM è installata per consentire l’esecuzione di procedure sotto forma di classi
Java. Vi è implementato anche un servlet container che permette l’uso di servlet e
JSP direttamente sul Server Oracle.
Inoltre il database fornisce un supporto ai dati XML. Esso in effetti definisce sia un
tipo di dato XML nativo sia una adeguamento dei tipi SQL già esistenti per potere
contenere questo genere di dati. Un’altra caratteristica è che Oracle ha il supporto
come database ad oggetti.
Una delle funzionalità utilizzate all’interno del progetto, oltre le classiche tabelle, è
il repository . Esso permette la conservazione di file e dati in modo simile ad un file
system. Il repository è parte del database XML, infatti esso è ottimizzato per
contenere questo tipo di dati.
L’istanza server Oracle fornisce e controlla l’accesso alle tabelle della sorgente di
dati e anche al repository.
3.2.4 OID (directory service)
Il servizio di directory usato è quello della Oracle, Oracle Internet Directory (OID).
Esso si basa su un architettura standard LDAP e contiene precaricati alcuni dei
schemi standard più usati. Il server viene acceduto secondo il protocollo LDAP v. 2
e 3 ma può anche essere configurato in modalità sicura tramite SSL. Infatti è
possibile creare un ulteriore istanza del server per accettare connessioni in SSL.
Il directory service ha una sua propria istanza server, mentre per conservare i dati fa
uso del database Oracle. Il server LDAP si connette al database server come
normale utente per prelevare e memorizzare dati relativi alla directory. Ovviamente
nel database vi sono tabelle dedicate a contenere i dati del directory service.
- 37 -
4. IMPLEMENTAZIONE PROGETTO
•
4.1 LA WEB APPLICATION
Questo capitolo tratta la parte pratica della tesi. Qui viene discusso il piccolo
progettino realizzato frutto dei vari studi effettuati. La messa in pratica di alcuni
concetti studiati sulla sicurezza è avvenuta con l’implementazione del progetto sotto
forma di web application.
L’applicazione realizzata non è un sistema completo per l’oggetto della tesi, ma
piuttosto un ambiente creato per implementare alcune soluzioni a problematiche
connesse direttamente al sistema Processo Telematico. I paragrafi successivi
descrivono ciò che è stato realizzato con particolare attenzione alla fase di sviluppo
dell’applicazione stessa. Prima di definire a livello generale l’architettura
dell’applicazione, è bene dare una definizione di due concetti che descrivono
l’architettura stessa: Layer e Tier. Ogni applicazione distribuita viene realizzata
effettuando una suddivisione della stessa in layer. Un layer rappresenta uno strato
di suddivisione orizzontale. L’applicazione deve essere vista composta da più layer.
Ciascun di essi ha un ruolo particolare nell’ambito dello sviluppo dell’applicazione
ed all’interno può contenere uno o più componenti. Da notare che i layer sono
semplicemente astrazioni e non corrispondono ad una distribuzione fisica
dell’applicazione. Una tipica separazione in layer in un applicazione web è la
seguente:
•
presentation layer, contiene i componenti che si occupano di gestire
l’interfacciamento dell’applicazione verso l’utente;
•
business logic layer, contiene i componenti che interagiscono tra di loro per
risolvere un determinato problema dell’applicazione;
•
data layer, è utilizzato dal business logic layer per effettuare i salvataggi di
stato in maniera persistente, è costituito essenzialmente da uno o più
database.
- 38 -
Per definire la separazione fisica dei layer si introduce il concetto di Tier. Un tier
rappresenta uno strato di suddivisione fisico. L’applicazione deve essere vista come
un insieme di strati sovrapposti, ognuno dei quali è un tier fisicamente separato
dagli altri.
L’applicazione è stata progettata e sviluppata seguendo un’architettura two-tier. I tre
layer tipici di una web application sono stati suddivisi in due tier. Più esattamente il
presentation layer e il business logic layer sono stati riuniti in un tier e il data layer
nell’altro tier.
L’intera web application è basata su JSP e Servlet. Ovviamente, affiancate da varie
librerie di supporto usate per vari compiti all’interno dell’applicazione. Le pagine
JSP unitamente alla JSTL (Java Standard Tag Library) sono state usate unicamente
per la parte di presentazione (presentation layer). Per quanto riguarda la business
logic è stata implementata interamente in Servlet ed altre classi appositamente
create. Nel data layer troviamo il database, il repository e il servizio di directory.
L’architettura di base del processo telematico è stata riprodotta (simulata) facendo
interpretare i ruoli dei principali componenti (PdA, GC, UG) a delle servlet. A
grandi linee, il flusso informativo principale dell’applicazione trae origine
dall’interazione dell’utente, tramite browser, con le pagine JSP le quali, a loro volta
comunicano con la catena di servlet che infine vanno a inserire e modificare dati
nelle basi di dati.
Gli obiettivi realizzati dall’applicazione sono i seguenti:
•
riprodurre parte del flusso informativo del Processo Telematico
•
realizzazione sistema di autenticazione
•
elaborazione dei dati nei vari componenti principali
•
protezione canali di trasmissione
La web application creata è stata chiamata PTelematWeb, in seguito nel libro verrà
fatto riferimento ad essa anche con il suo nome. Per motivi di semplicità, la web
application simula il flusso dati tra un solo PdA ed un solo UG, questo permettendo
di approfondire e incentrare gli sforzi sugli altri obiettivi come l’autenticazione al
PdA e l’elaborazione dei dati.
- 39 -
- 40 -
• 4.2 STRUTTURE DATI
4.2.1 L’ATTO
L’obiettivo primario della realizzazione del Processo Telematico è la trasmissione
di atti usando le moderne tecnologie informatiche garantendo un elevatissimo
livello di sicurezza nella riservatezza e autenticità dei documenti. Ciò impone come
presupposto la redazione degli atti non più in modo cartaceo bensì in modo digitale.
Questo è realizzato grazie a del software specifico progettato per essere usato
dall’avvocato che vuol fare uso del nuovo sistema di comunicazione. La redazione
dell’atto diventa una procedura che deve essere resa il più possibile user-friendly
per l’utente, questo però garantendo la massima correttezza e validità dei
documenti.
Il formato dati per conservare il contenuto degli atti è l’XML. E stato scelto per le
sue caratteristiche di formato standard, strutturato e testuale che rende agevole la
portabilità tra i vari applicativi software che devono gestire i dati. Inoltre
importantissima caratteristica di XML è la possibilità di rendere un documento xml
validabile rispetto ad un altro documento che ne definisce e ne impone la struttura
dei dati che il file xml deve o può ammettere. Stiamo parlando di un file DTD
(Document Type Definition). Alcuni esempi di atti di cui sono state ufficializzate e
rese pubbliche, da parte del Ministero della Giustizia, le loro strutture sono:
•
atto introduttivo (citazione e ricorso),
•
nota di iscrizione a ruolo,
•
comparsa di costituzione e risposta,
•
memoria generica,
ecc…
Il modello proposto per ciascun atto tiene conto della normativa di riferimento del
codice di procedura civile (cpc). Quindi l’atto diventa composto da più campi e
sezioni (insieme di campi), alcuni obbligatori ed altri opzionali inoltre è importante
sottolineare che la linea-guida seguita in fase di analisi nella definizione di tali
campi, è stata quella di optare comunque per il carattere opzionale di ogni altro
- 41 -
campo e sezione, liberamente componibile dall'avvocato nella successione
argomentativa dallo stesso ritenuta più idonea. La strutturazione dei diversi modelli
DTD (Document Type Definition) è pubblicata con apposito decreto ministeriale.
REDAZIONE ATTO
Lo sviluppo del software per la redazione degli atti e la creazione della busta non è
lo scopo della tesi, ma capire a fondo come l’atto generico viene creato e come la
busta per la trasmissione dello stesso con eventuali allegati viene generata, è
fondamentale ai fini dello sviluppo del progetto. Inoltre qui viene descritta anche
l’operazione di firma degli atti e allegati.
Il software di redazione viene fornito dal Ministero della Giustizia ai soli fini della
sperimentazione, il suo nome è Redattore Atti v1.1. Esso è uno strumento che si
integra in Microsoft Word e che consente la predisposizione dell'atto per la
successiva trasformazione in formato XML. L’atto inizialmente viene redatto
direttamente dall’ambiente del Redattore Atti che propone una serie di wizard
(procedure guidate) che permettono di inserire i dati in base al tipo di atto prescelto.
Successivamente l’atto può essere aperto e modificato attraverso gli strumenti
applicativi disponibili in Word, nelle sue parti obbligatorie ed opzionali. Durante
l’installazione del Redattore Atti, sul sistema viene installato un modulo estensione
per integrare le funzionalità del Redattore Atti direttamente in Word. Le
funzionalità disponibili in fase di redazione nell’ambiente MS Word, sono attivabili
in diversi modi, per esempio attraverso una barra degli strumenti, un menu o
abbreviazioni da tastiera. Le funzionalità native di MS Word sono utilizzate durante
la redazione o modifica dell’atto mentre quelle non consentite sono disabilitate
all'utente. L'ambiente di editing è lo stesso di un normale documento Word, e viene
proposto all'utente dopo un apposito data-entry (wizard) per i dati configurati come
obbligatori nel modello di atto scelto.
Il Sistema, avendo a disposizione un modello (DTD) ed un documento di default
per l'atto che l'utente ha deciso di redigere, presenterà nell'ambiente di redazione un
documento con:
- 42 -
•
una intestazione contenente tutti i dati definiti come obbligatori nel modello
stesso;
•
una serie di sezioni (il cui ordine è definito nel modello, ma può essere
modificato in fase di dataentry iniziale) riempibili opzionalmente a cura
dell'utente Avvocato;
•
una formula testuale pre-determinata per ogni sezione, che potrà essere
modificata e/o cancellata dall'utente solo sull'Atto stesso senza lasciare parti
di testo inconsistenti o righe vuote se non espressamente inserite.
Il Documento Word è, così, organizzato come un insieme gerarchico di Sezioni e
Campi, secondo una struttura ad albero: l'intero documento costituisce il Campo
radice (root, comune a tutti gli Atti) che può contenere testo e/o Campi figli, e così
via, ricorsivamente, esattamente come avviene per i documenti XML. Pertanto ogni
parte del Documento appartiene ad un Campo e ogni Campo ne può contenere altri.
I Campi del Documento corrispondono biunivocamente ai nodi dell'XML.
Il Sistema permette inoltre all'utente Avvocato di inserire all'interno di ciascuna
sezione uno o più campi strutturati (suggeriti dal sistema stesso), e di norma
opzionali, la cui compilazione, nel caso di dati complessi, è guidata tramite una
finestra di inserimento che controlla l'obbligatorietà o l'opzionalità dei dati stessi
contenuti nel campo.
Durante la fase di redazione vera e propria, l'applicativo esercita un costante
controllo sull'attività dell'utente al fine di sincronizzare il contesto alla posizione
corrente di redazione nel Documento: in ogni istante, lo Strumento di Redazione
abilita esclusivamente le funzioni valide nel nodo corrente.
Inoltre, impedisce modifiche alla struttura, al fine di garantire la creazione di file
XML validi rispetto ai requisiti definiti per il singolo Atto con l'ausilio dei DTD.
L'atto in formato XML, conforme ai DTD previsti dall'Amministrazione, è ottenuto
a partire dal formato Word mediante l'esecuzione di procedure di trasformazione
automatica. Il formato dell'Atto XML include, oltre alle marcature “semantiche”,
ove previsto, anche le informazioni di formattazione del testo.
- 43 -
La logica progettuale è “application to application”, ossia mira alla realizzazione di
un'integrazione tra applicazioni in modo tale da consentire loro di interagire e
scambiarsi dati in modo autonomo.
FIRMA ATTO
L'atto redatto ed eventualmente anche alcuni allegati devono essere firmati e cifrati
per l'Ufficio Giudiziario di destinazione. A questa operazione provvede l’utente
tramite l’uso del Redattore Atti e un apposito apparato fisico e logico come la smart
card, il lettore smart card, appositi driver del lettore e librerie dll della smart card.
Le caratteristiche di questo apparato vengono descritte più avanti in questo capitolo
nella sezione riguardante la sicurezza. La firma digitale di un documento generico
viene ampiamente discussa nella sezione “Sicurezza” del capitolo 3 “Contesto
applicativo” di questo libro. Qui viene discussa la struttura della firma applicata
nell’ambito del Redattore Atti. La modalità di apposizione della firma in questo
contesto, denominata firme indipendenti (meccanismo “aggiungi una firma”),
prevede che uno o più soggetti firmano digitalmente lo stesso documento. L'ordine
di apposizione delle firme degli N firmatari non è significativo, ed il file generato si
presenta con un'unica estensione p7m. La struttura è quindi PKCS#7 in cui sono
contenute le N firme che si riferiscono quindi, al medesimo documento. Non è
possibile utilizzare tale meccanismo per stabilire l'ordine in cui le firme stesse sono
state apposte: una alterazione dell'ordinamento delle firme non pregiudica la validità
della busta crittografica PKCS#7.
Tale meccanismo è valido sia per l'apposizione di una firma singola che per
l'apposizione di firme multiple. La figura 4.2 rappresenta la struttura PKCS#7 del
file firmato.
- 44 -
Figura 4.2 struttura PKCS#7 di un file firmato
Tali oggetti vengono aggregati in una struttura MIME (Atto.msg). Di seguito viene
illustrata la struttura del file MIME contenente l’indice dei file contente i riferimenti
ai documenti atto ed allegati (IndiceBusta.xml), l’atto firmato (CorpoAtto.xml.p7m)
e i suoi eventuali allegati firmati e non (allegato.pdf.p7m).
Figura 4.3 struttura MIME contenente l’atto, i suoi allegati e l’indice degli stessi
- 45 -
4.2.2 LA BUSTA
La struttura MIME descritta nel paragrafo precedente viene prima cifrata in un
unico file e dopo aggregata a informazioni per l’inoltro dei dati. Questi oggetti (file
cifrato e informazioni di inoltro) vengono aggregati, ai fini del deposito in
un'opportuna struttura dati denominata “busta MIME”, contenente quindi un file
con le informazioni di instradamento della busta (InfoInoltro.xml), e un file cifrato
contenente a sua volta tutti i documenti, atti e allegati che saranno trasmessi
(Atto.enc). Questo avviene sempre tramite il Redattore Atti. Da notare che dopo la
spedizione e durante il passaggio di tale busta per il Punto d’Accesso essa può
essere opzionalmente firmata da quest’ultimo. La figura che segue illustra la
struttura generale della busta MIME.
Figura 4.4 struttura busta MIME
La busta così composta è pronta per essere inviata all’Ufficio Giudiziario
specificato.
Il file cifrato “Atto.enc” ha al suo interno il contenuto principale che l’utenteavvocato desidera trasmettere. Infatti Atto.enc contiene l’oggetto MIME definito nel
paragrafo precedente(Atto.msg), la chiave di sessione (crittografia simmetrica) con
cui è stato cifrato l’oggetto MIME e un riferimento al certificato digitale del
destinatario contenente la chiave pubblica dell’ufficio destinatario con cui è stata
cifrata la chiave di sessione. La figura 4.5 illustra la struttura generale del file
- 46 -
Atto.enc che è il risultato ottenuto a seguito del processo di cifratura dell’oggetto
mime Atto.msg. L’elemento “Issuer Dname” è il Distinguished Name della CA che
ha emesso il certificato dell'ufficio giudiziario destinatario, l’elemento “Serial
Number” è il numero seriale del certificato dell'ufficio giudiziario destinatario. Tali
dati sono necessari per il controllo successivo in fase di decifratura ed identificano il
certificato con cui è stato cifrato l'oggetto.
L'algoritmo utilizzato per l'operazione di cifratura simmetrica del file è il 3DES e le
chiavi simmetriche di sessione vengono cifrate utilizzando la chiave pubblica
contenuta nel certificato del destinatario con il quale si intende corrispondere.
Tale busta sarà successivamente depositata presso l'Ufficio Giudiziario per il
tramite del Punto d’Accesso e del Gestore Centrale.
Figura 4.5 struttura file Atto.enc
La cifratura degli atti in uscita, ossia cifrati a cura del Gestore locale con la chiave
pubblica del soggetto destinatario (avvocato) non è stata implementa nell’ambito di
questo progetto. Comunque in un ipotetica implementazione si applicherebbero le
stesse specifiche sopra riportate. In particolare, per gli atti inviati alla casella di
posta certificata del destinatario, verrebbe utilizzata la medesima struttura di
Atto.enc, che verrebbe allegato al messaggio di posta elettronica certificata.
Il file “InfoInoltro.xml” contiene le informazioni di servizio per il Gestore
Centrale. Tali informazioni consentono al Gestore Centrale il routing del messaggio
verso l’Ufficio Giudiziario specificato. Il file ha la struttura illustrata nella figura
seguente.
- 47 -
Figura 4.6 struttura file InfoInoltro.xml
L’elemento IdMsgPdA riporta l'identificativo univoco del messaggio, generato dal
PdA. Al momento della creazione della busta sulla postazione client dell’avvocato
tali elementi non hanno valore. I campi dell’identificativo sono:
•
CodicePdA: è il codice identificativo del PdA.
•
Anno: è l'anno di generazione del messaggio.
•
IdMsg: è un progressivo numerico univo nell'ambito dell'anno.
L’elemento Mittente contiene il sottoelemento CodiceFiscale. Esso è il codice
fiscale dell'avvocato che ha originato il messaggio e quindi anche firmato l’atto.
L’elemento mittente può avere un attributo “ruolo”.Esso indica il ruolo assunto dal
mittente (ad esempio “avvocato”).
L’elemento Destinatario contiene il sottoelemento CodiceUG. Esso è il codice
identificativo dell'UG destinatario.
L’elemento IdMsgMitt contiene il valore identificato assegnato dall'Avvocato
all'atto informatico (il nome del file “busta MIME” sulla macchina client).
- 48 -
4.2.3 LE BASI DI DATI
L’applicazione si appoggia a varie strutture per la conservazione dei dati persistenti.
Sono state usate tre forme diverse di supporto per i dati: database, repository e
service directory. A seconda del tipo di informazione è stato usato un o l’altro tipo.
Tutti e tre i software sono prodotti Oracle, il repository e la directory si appoggiano
al database Oracle. Per capire meglio, è bene ricordare che ogni contenitore fisico di
dati ha il proprio software che si occupa di fornire l’accesso ai propri dati. Quindi
possiamo fare una distinzione netta tra i dati memorizzati e il software che li
gestisce. Quando parliamo di database solitamente ci riferiamo all’insieme di queste
due componenti. Adesso, per chiarire meglio come sono stati organizzati i
contenitori di dati nell’ambito del progetto, parlerò di istanza o server quando mi
riferirò al software che gestisce i dati. E stata fatta questa distinzione per poter
spiegare meglio, in seguito, il significato di repository e service directory che si
appogiano al database.
Il database Oracle è un object-relational database, per conservare i dati esso è
basato sul modello relazionale ed offre allo stesso tempo il supporto come database
ad oggetti. L’istanza server Oracle fornisce e controlla l’accesso alle tabelle della
sorgente di dati.
Il repository è integrato nel database Oracle. Ciò vuol dire che il software per
accedere al repository è parte dell’istanza del database, inoltre i dati vengono
memorizzati in delle speciali tabelle relazionali dedicate del database. Quindi la
struttura fisica di memorizzazione per il repository è quella del database relazionale.
Il software d’accesso come detto prima è parte dell’istanza server per il database
Oracle. L’accesso al repository può avvenire usando diversi protocolli quali HTTP,
WebDAV e FTP. Quest’ultimo è stato usato nel progetto.
Il directory service ha una sua propria istanza server, mentre per conservare i dati
fa uso del database. Il servizio di directory è basato e può essere acceduto tramite il
protocollo standard LDAP versioni 2 e 3. Il server LDAP (directory service) si
connette al database server come normale utente per prelevare e memorizzare dati.
- 49 -
Ovviamente nel database vi sono tabelle dedicate a contenere i dati del directory
service. Più avanti in questo paragrafo viene descritta la struttura dei dati una
directory service.
Ai fini dell’implementazione del progetto sono state attivate due istanze del
database Oracle (ciascuna con la sua propria basi di dati fisica), di cui una dedicata
come supporto al server LDAP, e un’istanza del server LDAP.
Il database, nell’ambito del progetto viene usato per memorizzare i dati del
passaggio della busta MIME attraverso i vari componenti, PdA, GC e UG. Il
repository è il contenitore finale dei file nell’ UG e quindi viene usato solo da
questo. Il directory server viene usato in ambito di autenticazione, infatti esso serve
per contenere i dati sugli utenti.
La struttura logica del repository è quella di un file system gerarchico. La struttura
realizzata per il progetto è illustrata nella figura seguente.
Figura 4.7 struttura repository per PTelematWeb
- 50 -
La struttura dei dati in LDAP è un grafo diretto aciclico (DAG), ma comunemente
viene utilizzata la struttura ad albero. La struttura dell'albero e dei nodi non presenta
particolari limiti, più in dettaglio:
•
da ogni nodo possono partire infiniti rami,
•
ogni nodo può avere dati con strutture diverse,
•
la struttura dei dati del singolo nodo è liberamente definibile ed è object
oriented,
•
uno stesso oggetto può essere riferito in due nodi diversi dell'albero con un
meccanismo simile ai soft link dei file system.
La struttura dati nella directory service viene chiamato DIT (Directory Information
Tree). La struttura di una particolare DIT viene descritta tramite un directory
Schema. Il directory Schema contiene le informazioni su come è organizzato il
DIT. Un nodo dell’albero è un contenitore di dati e viene chiamato directory entry o
più semplicemente entry. Ogni entry è formata da uno o più oggetti, gli oggetti
vengono dichiarati in opportuni file di configurazione con sintassi non standard.
Tali file vengono generalmente indicati col nome di schemi e definiscono degli
objectClass. Un objectClass è un modello di oggetto che determinano il nome, il
tipo, la semantica e la sintassi degli attributi che possono essere presenti in
un’istanza dell’objectClass. L’attributo contiene il singolo dato. Esistono degli
objectClass e degli attributi standard definiti in alcune RFC che vengono
implementate in tutti gli schemi dei vari service directory esistenti. Le entry sono
formate da:
•
Distinguished Names (DN): Una lista di coppie nome-valore che individua la
posizione del
nodo all'interno dell'albero, ad esempio:ou=pda, o=ptelemat, c=it. L'ultima
coppia individua la radice dell'albero, la prima distingue il figlio dai fratelli,
le altre individuano un percorso nell'albero, la prima coppia viene chiamata
Relative Distinguished Name (RDN).
•
Uno o più objectClass che definiscono il tipo di dati contenuti. Tutti gli
attributi del nodo si
ottengono mediante la composizione degli objectClass dichiarati nell’entry.
- 51 -
•
I dati del nodo come coppie attributo-valore, che rispettano le definizioni
degli objectClass. Si deve osservare che possono essere generalmente
presenti più coppie attributo-valore con lo stesso attributo.
Questa descrizione è la vista logica dei dati contenuti in una qualsiasi directory
standard LDAP che ha un client LDAP. L’effettiva conservazione dei dati varia da
produttore a produttore, nel caso del nostro servizio di directory (Oracle Internet
Directory) la memorizzazione fisica avviene in un database Oracle.
La figura seguente illustra la semplice struttura adottata nell’ambito del progetto.
Figura 4.8 DIT per PTelematWeb
Per ragioni di limitate risorse hardware nell’ambiente di sviluppo è stato usato un
unico database per la registrazione delle informazioni sul passaggio delle buste nei
vari componenti del sistema. Questo database, per ottenere comunque una
separazione dei dati dei rispettivi PdA, GC e UG, è stato suddiviso in 3 schemi ed
altrettanti tablespace (file fisici contenenti le tabelle). La struttura delle diverse
tabelle all’interno del database sono state create con il tool grafico della Oracle
Enterprise Manager. Per i due tablespace di PdA e GC è stato creato anche un
oggetto per la generazione di valori sequenziali. Il termine tecnico per questi oggetti
è sequenza. Ogni sequenza permette la generazione di numeri univoci e
opzionalmente anche sequenziali all’interno dello schema in cui viene creato.
Questi sono necessari nel PdA perché esso ha la necessità di assegnare un
identificativo univoco ad ogni busta che viene uploadata al Punto d’Accesso, inoltre
- 52 -
sono anche necessari nell’UG perché i fascicoli formati nel repository hanno
bisogno di un valore univoco per il numero di ruolo relativo che viene assegnato
loro alla creazione di un nuovo fascicolo.
La base di dati viene acceduta dall’applicazione mediante un datasource che fa uso
del driver JDBC. Questo viene descritto più in dettaglio più avanti.
Le righe e gli schemi successivi illustrano come sono stati organizzati i dati
all’interno delle varie strutture e descrivono anche la loro natura. La descrizione del
loro utilizzo e flusso all’interno dell’applicazione viene effettuata nelle sezioni
successive di questo capitolo. Le convenzioni usate nello descrivere i vari schemi
sono le seguenti: ogni tabella viene dichiarata su una riga e nelle parentesi che
seguono vi è l’elenco delle colonne di cui è composta, uno o più nomi di colonna
con sottolineatura continua rappresentano la chiave primaria, uno o più nodi di
colonna con sottolineatura tratteggiata rappresentano una chiave esterna. Gli
eventuali
vincoli
come
NOT
NULL
oppure
UNIQUE
vengono
successivamente assieme al tipo di ogni colonna.
Per capire meglio ecco un esempio:
nomeTabella(colonnaChiavePrim, secondaColonna, terzaColonnaChiaveEst)
- 53 -
scritti
PDA
La figura seguente rappresenta lo schema E/R dal quale è stato costruita la struttura
delle tabelle nello schema del Punto d’Accesso.
Figura 4.9 schema E/R PdA
PdA
TRASMISSIONE
DESTINAZIONE
POST_SEQUENZA
Le tabelle:
Trasmissione(anno, idmsg, codicefiscale, codiceug, orapartenza)
Destinazione(codiceug, descrizione)
Post_Sequenza(valore)
Tipo colonne:
tutte di tipo VarChar2 tranne la colonna orapartenza che è di tipo Date. Questa
colonna ha il valore settato come valore di default SYSTIMESTAMP.
Descrizione:
Nella tabella trasmissione vengono memorizzati i log di tutte le buste “uploadate” e
inoltrate dal PdA verso il GC. La tabella destinazione è un elenco normalmente
fisso di tutte le destinazioni possibili. La sequenza fornisce il valore assegnato ad
ogni valore della colonna idmsg. La tabella Post_Sequenza, anche chiamata più
avanti come tabella ausiliaria, viene usata dal codice dell’applicazione per
- 54 -
memorizzare temporaneamente il nuovo valore estratto dalla sequenza prima che
esso venga assegnato alla colonna idmsg per ciascun nuovo record.
Relazioni:
Destinazione-Trasmissione, relazione di tipo uno-a-molti, ad ogni trasmissione
corrisponde una sola destinazione (UG) e una destinazione può essere l’obiettivo di
più trasmissioni.
Sequenze:
Invio_Seq ha i seguenti parametri settati: crescente, no cache e order.
GC
La figura seguente rappresenta lo schema E/R dal quale è stato costruita la struttura
delle tabelle nello schema del Gestore Centrale.
Figura 4.10 schema E/R GC
GC
PROVENIENZA
TRASMISSIONE
DESTINAZIONE
RIFIUTI
Le tabelle:
Trasmissione(idmsg, codicepda, anno, codicefiscale, codiceug, data_ora_arrivo,
data_ora_partenza)
Provenienza(codicepda, descrizione)
- 55 -
Destinazione(codiceug, descrizione)
Rifiuti(codicepda, anno, idmsg, descrizioneerrore)
Tipo colonne:
tutte di tipo VarChar2 tranne le colonne data_ora_arrivo e data_ora_partenza che
sono di tipo Date. La colonna data_ora_arrivo ha il valore settato come valore di
default SYSTIMESTAMP, mentre il valore della colonna data_ora_partenza viene
stabilito
nel
codice
dell’applicazione
e
quindi
inserito
successivamente
all’inserimento del nuovo record.
Descrizione:
Nella tabella trasmissione vengono memorizzati i log di tutte le buste arrivate e
inoltrate dal GC verso l’UG. Le tabelle Provenienza e Destinazione contengono
rispettivamente le provenienze (codice dei PdA) e le destinazioni (codici degli UG)
ammissibili. La tabella Rifiuti contiene i log delle buste arrivate al GC ma non
inoltrate per un qualche motivo descritto nella colonna descrizioneerrore
Relazioni:
Provenienza-Trasmissione, relazione di tipo uno-a-molti, ad ogni trasmissione
corrisponde una sola provenienza (PdA) e una provenienza può essere l’origine di
più trasmissioni.
Destinazione-Trasmissione, relazione di tipo uno-a-molti, ad ogni trasmissione
corrisponde una sola destinazione (UG) e una destinazione può essere l’obiettivo di
più trasmissioni.
Rifiuti-Provenienza, relazione di tipo uno-a-molti, ad ogni busta rifiutata
corrisponde una sola provenienza (PdA) e una provenienza può essere l’origine di
più trasmissioni.
- 56 -
UG
La figura seguente rappresenta lo schema E/R dal quale è stata costruito la struttura
delle tabelle nello schema dell’Ufficio Giudiziario.
UG
POST_SEQUENZA
PARTE
PARTE
DIFENSORE
FASCICOLO
EVENTI
ATTI
Reposit
ory
Figura 4.11 schema E/R UG
Le tabelle:
RegistroBuste(codice, codicepda, anno, idmsg, data_ora_arrivo, nomefile)
Fascicolo(anno, numruolorelativo, ufficio, sezione, giudice, oggetto, stato,
datacreazione)*
Parte(codice, ragionesociale, cognome, indirizzo, tipo, anno, numruolorelativo)*
Difensore(codice, codicefiscale, nome, cognome, indirizzo)*
DifesaParte(codicedifesa, codiceparte)*
Atti(codice, anno, numruolorelativo, tipo, datadeposito)*
- 57 -
Eventi(codice, anno, numruolorelativo, dataora, descrizione)*
Post_Sequenza(valore)
Tipo colonne:
Le colonne di queste tabelle sono tutte principalmente di tipo VarChar2 a parte
quelle che contengono dedicate alla memorizzazione di timestamp. In particolare la
colonna data_ora_arrivo della tabella RegistroBuste ha come valore di default
SYSTIMESTAMP.
Descrizione:
La tabella RegistroBuste conserva i log di tutte le buste pervenute all’UG. Le
tabelle Atti, Parte, Difesaparte, Difensore e Eventi sono tutte legate direttamente o
indirettamente alla tabella fascicolo. Infatti queste tabelle servono per organizzare e
suddivedere le varie informazioni contenute all’interno dei fascicoli. La tabella
Difesaparte associa il difensore alla parte. Post_Sequenza è la tabella ausiliaria
usata dal codice dell’applicazione per memorizzare temporaneamente il nuovo
valore estratto dalla sequenza prima che esso venga assegnato ad un fascicolo.
Relazioni:
Fascicolo-Atti, relazione di tipo uno-a-molti, ad ogni fascicolo possono
corrispondere più atti e ogni atto corrisponde ad un solo fascicolo.
Fascicolo-Parte, relazione di tipo uno-a-molti, ad ogni fascicolo possono
corrispondere più parte e ogni parte corrisponde ad un solo fascicolo.
Fascicolo-Eventi, relazione di tipo uno-a-molti, un fascicolo può generare più eventi
e ogni evento è legato ad un solo fascicolo.
Parte-Difensore, relazione di tipo molti-a-molti, una parte parte può avere più
difensori e un difensore può difendere più parti.
Nota: la tabella DifesaParte è stata necessaria nella fase di trasformazione dal
modello concettuale a quello logico (relazionale). Infatti, la precedente relazione
molti-a-molti tra le entità Difensore e Parte, per le regole di normalizzazione, è
- 58 -
dovuta essere spezzata per creare due nuove relazioni uno-a-molti inserendo l’entità
DifesaParte tra le due entità precedentemente citate.
Sequenze:
RuoloRelativo_Seq ha i seguenti parametri settati: crescente, no cache e order.
* Le tabelle marcate con l’asterisco sono inutilizzate nel progetto che è stato
implementato.
• 4.3 TRASMISSIONE BUSTA
In questa sezione viene discusso il percorso che la busta MIME compie all’interno
della web application. Dalla fase di upload da parte dell’utente fino all’arrivo
all’UG. Vengono illustrate quali tecniche sono state usate per la comunicazione tra i
vari componenti come le JSP e le Servlet. Sono descritte le manopilazioni che
subisce la busta durante il suo percorso. Il tutto spiegato sotto un’ottica da
sviluppatore. La spiegazione segue una logica sequenziale e temporale illustrando i
vari passi che vengono eseguiti man mano che la busta viene inoltrata e elaborata
attraverso l’applicazione e il database.
4.3.1 UPLOAD AL PDA
Una volta che l’avvocato si è autenticato al sistema accede alla propria home page.
Essa contiene il menu delle operazioni che può eseguire:
•
Trasmetti busta
•
Consulta propri fascicoli
•
Ricerca fascicoli
Nell’ambito del progetto è stato sviluppato solo la trasmissione della busta, quindi
le altre due funzioni sono disabilitate.
- 59 -
L’upload della busta dal computer dell’utente al Punto d’Accesso a cui si è
autenticato, si traduce in termini tecnici nel progetto come l’upload dal browser
client alla servlet PdA. Il caricamento della busta dal client è stato fatto usando una
form HTML con i tag appositi per l’upload di file previsti in HTML 4.
<FORM method="post" enctype="multipart/form-data" action="/PdA">
<INPUT type="file" name="percorso" size="20" >
</FORM>
il tag <INPUT type=”file”> corrisponde al livello di interfaccia utente sia ad un text
box per inserire manualmente il path della busta su computer locale, sia al button
Sfoglia che permette di selezionare il file della busta che si vuol trasmettere. Infatti
esso apre una finestra standard per la selezione di un file all’interno del file system
locale. Questa form ha impostato come valore di action la servlet PdA, premendo il
button invia la request POST viene inoltrata alla servlet in questione. Con il metodo
del file upload HTML il file da trasmettere viene allegato come parametro della
request. Il canale di trasmissione è ovviamente http ma con protezione SSL. Quindi
i dati della trasmissione sono cifrati rendendo sicuro l’upload.
Figura 4.12 form HTML che permette l’upload della busta
Quanto descritto fino adesso è solo quello che succede lato client, adesso viene
spiegato cosa succede lato server, quindi alla ricezione della busta. Abbiamo già
- 60 -
detto che è la servlet PdA che si occupa di ricevere la busta e più precisamente di
gestire la request.
Una request HTTP viene incapsulata a livello di HTTP servlet come un oggetto
della classe HTTPServletRequest. Una response HTTP viene incapsulata
nell’oggetto di classe HTTPServletResponse. Il metodo doPost(…) della servlet ha
come argomento proprio questi due oggetti. Il compito della servlet è:
•
ricevere la busta MIME
•
eseguire il parsing della richiesta Post per individuare ed estrarne la busta
MIME
•
aprirla e prelevare il file InfoInoltro.xml
•
verificare la correttezza della destinazione
•
settare alcuni tag in questo file
•
salvare il file InfoInoltro.xml modificato e rimetterlo nella busta MIME
•
conservare sul database traccia del suo passaggio
•
inoltrare la nuova busta
La ricezione della busta uploadata dalla jsp inviodoc.jsp avviene in automatico
perché gestita dall’application server con il protocollo HTTP, infatti il primo
compito della servlet è leggere la busta dalla richiesta Post. Ciò viene fatto
eseguendo un parsing manuale della request Post (che altro non è che una struttura
MIME di tipo “multipart/form-data”). La busta viene estratta in un array di byte. Per
estrarre il file InfoInoltro.xml contenuto nella busta è stata realizzata una classe
apposita “AnalizzatoreBustaMime” che fa uso delle api della Sun per parsare un file
MIME (package javax.mail. e javax.mail.internet).Questa classe insieme alla classe
AnalizzatoreDatiInoltro vengono descritti più accuratamente nel paragrafo Inoltro
GC. Tramite un’istanza di AnalizzatoreBustaMime viene estratto il file
InfoInoltro.xml in una variabile stringa. In seguito viene usata un’estensione (classe
derivata) della classe AnalizztoreDatiInoltro (AnalizzatoreDatiInoltroPdA) per
verificare la validità dei dati contenuti nel file xml e settare alcuni valori che deve
definire il Punto d’Accesso. Questi valori vengono assegnati ad ogni busta che
viene trasmessa dal PdA e servono per identificarla univocamente. I tre valore
settati sono gli elementi figli del tag principale IdMsgPdA: CodicePdA, Anno,
- 61 -
IdMsg (vedi figura 4.6). Il CodicePdA è stato scelto inizialmente arbitrariamente e
rimane invariato in tutte le buste trasmesse dallo stesso PdA. In questo caso, dato
che il progettino tratta un solo Punto d’Accesso ed un solo Ufficio Giudiziario il
valore di questo dato è ininfluente. Il valore del tag anno viene ovviamente dedotto
e settato dal corrente timestamp fornito dall’application server del PdA. Il valore del
tag IdMsg viene fornita dal database. Infatti, esso viene interrogato per prelevare un
valore univoco non ancora assegnato. Una volta settati questi parametri, il nuovo
file InfoInoltro.xml deve andare a sostituire il precedente file contenuto nella busta.
Ciò viene fatto usando la classe che abbiamo precedentemente usato per prelevarlo
(AnalizzatoreBustaMime).
A questo punto la servlet deve registrare il passaggio di questa busta dal server. Una
connessione al database viene presa dalla sessione che è stata creata nella servlet
PreHomepage subito dopo l’autenticazione al sistema. Tale connessione viene
passata al metodo dell’AnalizzatoreDati che si occupa della conservazione dei dati
sul database. I dati vengono conservati nella tabella Trasmissione illustrata nella
sezione riguardante il database in questo libro. Una volta registrato correttamente il
log relativo alla busta in questione, essa viene reinserita nella request e inoltrata al
Gestore Centrale (la servlet GC).
4.3.2 INOLTRO GC
Prima di andare a descrivere il ruolo della servlet GestoreCentrale andiamo a
spiegare il ruolo di due classi di cui si è parlato e che vengono usate anche in questa
servlet, la classe AnalizzatoreBustaMime e la classe AnalizzatoreDatiInotro con
relative sottoclassi. Sono state scritte queste due classi per organizzare meglio il
codice all’interno dell’applicazione e in modo che si evitasse di andare a ripetere del
codice che viene utilizzato più volte all’interno delle varie servlet principali. In
effetti alcune operazioni sono ripetute e hanno aspetti che possono essere regolati da
parametri come ad esempio l’estrapolazione dei dati dalla busta Mime, il
- 62 -
salvataggio di tali dati nelle varie tabelle ecc… Quindi anche per migliorare la
leggibilità del codice sono state realizzate queste classi che vengono utilizzate
direttamente nei metodi doGet() e doPost() delle servlet. Esse sono state
implementate con un interfaccia la più semplice possibile, definendo pochi e concisi
metodi.
La classe AnalizzatoreBustaMime permette di gestire un flusso di dati MIME, e in
particolare quello della busta in oggetto. La classe creata incapsula le classi del
package javax.mail.internet e javax.mail di J2EE 1.3 per gestire file MIME,
fornendo così un’interfaccia semplificata e diretta per le operazioni da eseguire sulla
busta. Il costruttore della classe prende in input un InputStream nel quale vi è la
busta, i metodi implementati sono i seguenti: getFileInfoInoltro(), getFileAtto(),
setFileInfoInoltro(). I nomi dei metodi sono autodescrittivi, c’è solo da osservare
che il file InfoInoltro.xml viene estratto e settato come String mentre per il file
Atto.enc viene usato un array di byte.
La classe AnalizzatoreDatiInoltro permette di gestire il contenuto del file xml
InfoInoltro. Essa nel codice non viene usata direttamente ma bensì tramite due sue
dirette sottoclassi, AnalizzatoreDatiInotroPdA e AnalizzatoreDatiInoltroGC (vedi
figura 4.13). Queste classi usano le classi JDom e il parser Xerces per manipolare il
file xml. I metodi della superclasse sono i seguenti: getDatoInoltro(),
setDatoInoltro(), validaDati(). Essi servono per cambiare i dati contenuti nel file e
per verificare la loro correttezza rispetto al DTD di InfoInoltro.xml. Sono state
create le due sottoclassi in modo da implementare un nuovo metodo (salvaInDB())
che permette il salvataggio di questi dati nelle rispettive tabelle di Database del
Punto d’Accesso e del Gestore Centrale.
- 63 -
Figura 4.13 schema sottoclassi della classe AnalizzatoreDatiInoltro
Il codice della servlet GestoreCentrale interpreta il ruolo del Gestore Centrale. Essa
riceve la request HTTP inoltra dal PdA. Il compito della servlet è:
•
ricevere la busta MIME
•
parsing della richiesta Post per estrarne la busta MIME
•
verificarne l’integrità al livello generale
•
verificare la correttezza della destinazione
•
registrazione del passaggio della busta
•
inoltrarla alla destinazione specificata
La busta si trova sempre all’interno della request Post, quindi viene estratta in
memoria. Viene verificata la sua integrità al livello generale, cioè viene eseguito un
controllo sulla composizione della busta che verifica che vi siano sia il file
InfoInoltro.xml, sia il file Atto.enc. Quindi viene aperto InfoInoltro.xml e viene
letta e controllata la validità della destinazione. In seguito viene registrato nel
database traccia del suo passaggio grazie al metodo salvaInDB() della classe
AnalizzatoreDatiInoltroGC. La connessione al database non è quella usata dalla
servlet PdA, ma una nuova prelevata dal datasource nel metodo init() della servlet.
Viene prelevata una nuova connessione per sottolineare il fatto che nella realtà il
Punto d’Accesso e il Gestore Centrale sono due entità divise fisicamente e quindi
- 64 -
ognuna ha la propria connessione al proprio database. Se è tutto in ordine la busta
viene inoltrata alla destinazione finale (l’Ufficio Giudiziario). Da notare, come
precisato precedentemente, che è stato realizzato un unico UG nell’ambito del
progetto. Se vengono rilevati errori durante l’elaborazione del GC la busta
semplicemente non viene inoltrata.
4.3.3 INOLTRO UG
La servlet UG è il punto d’arrivo della busta MIME. Essa accede sia al database sia
al repository per depositare la busta. La servlet esegue le seguenti operazioni:
•
ricevere la busta MIME
•
parsing della richiesta Post per estrarne la busta
•
creazione nome file univoco per la busta
•
salvataggio in repository
•
registrazione log dell’arrivo
•
conservare sul database traccia del suo passaggio
•
comunicazione all’utente dell’operazione effettuata
Dopo l’analisi della request Post per estrarne la busta, viene fatto il solito controllo
di integrità generale (controllo sulla composizione della busta). A questo punto la
busta si trova in memoria ed è necessario conservarla nel repository intatta, così per
come è arrivata. Comunque prima di ciò bisogna formulare il nome di riferimento
con cui il file (la busta) verrà conservata all’interno del repository. Ovviamente
questo dovrà essere univoco all’interno della directory del repository dove essa
verrà conservata (vedi figura 4.7). Il nome da assegnare alla busta viene creato
seguendo il formato: “numUnivoco_CodicePdA-IdMsg.eml”. Il numUnivoco viene
stabilito dalla sequenza sul database, il CodicePda e l’IdMsg vengono l’atti dal file
InfoInoltro.xml. Per ottenere il valore univoco dalla sequenza del database è stata
creata una classe apposita SequenzaDB che viene descritta alla fine di questo
paragrafo. Una volta creato il nome della busta è possibile conservare la busta nel
repository. L’upload avviene tramite FTP, usando le classi della libreria opensource
- 65 -
“commons-net” della Apache. In questo caso non vi è la necessità della protezione
del canale di trasmissione dato che il repository si trova sulla stessa macchina. In
seguito viene registrato il log sul database dell’arrivo della busta e della sua
conservazione in repository. Questo vuol dire che sul database insieme al record del
log viene registrato il riferimento (nome assegnato) alla busta che si trova nel
repository. La decifratura del file cifrato Atto.enc non è stata eseguita nel progetto
perché questo file è cifrato con una chiave criptata con la chiave pubblica
dell’Ufficio Giudiziario di destinazione. Viene comunque descritta la serie di passi
che l’applicazione avrebbe dovuto compiere. Dopo la decifratura del file cifrato, il
suo contenuto (atto, indice, allegati, ecc..) dovrebbe essere conservato nella
directory Temp del repository. In seguito viene verificata la firma digitale apposta
all’atto e quelle eventualmente apposte agli allegati. Se tutto è valido i vari files
vengono smistati e conservati nelle apposite directory del repository (vedi figura
4.7).
La classe SequenzaDB viene usata in questa servlet per prelevare un valore univoco
dal database. Un valore non può essere prelevato direttamente in un interrogazione
SQL al database, questo perché una sequenza Oracle può essere usata solo per
inserire valori direttamente all’interno delle tabelle del database tramite istruzioni
SQL di manipolazione (Insert o Update). La soluzione è stata creare una tabella
ausiliaria nel quale effettuare temporaneamente l’inserimento del nuovo valore
crescente della sequenza e subito dopo andare a prelevarlo con un interogazione
SQL (max(valore)) per poterlo usare nel codice. La classe prende come parametro
di input la connessione al database nel quale si trova la sequenza e il nome della
sequenza. Il nome della tabella di ausilio è definito di default nella classe ma può
essere impostato diversamente tramite un suo metodo. I metodi principali per
ricavare i valori sono: getNext() e getCurrent. Il primo restituisce un nuvo valore
univoco usando la procedura sopra descritta, mentre il secondo restituisce l’ultimo
valore generato dalla sequenza.
- 66 -
• 4.4 AUTENTICAZIONE
L’autenticazione al sistema è stato un problema ampiamente studiato in questo
progetto. Infatti, in un primo tempo sono stati analizzati i vari meccanismi di
autenticazione disponibili per una web application. Poi sono state studiate le
tecnologie che usano questi sistemi, in effetti è da notare che al fine della
realizzazione di un applicazione web con sistema di autenticazione non è necessario
conoscere a fondo quali sono i meccanismi che permettono al sistema di accettare
una richiesta di accesso da un utente. Questo perché l’autenticazione non è per forza
un aspetto che bisogna direttamente sviluppare, infatti con la filosofia dichiarativa
che offre la piattaforma J2EE è sufficiente sapere quali sono i requisiti che
l’applicazione deve avere per poter usufruire del sistema di autenticazione scelto.
L’autenticazione, diventa quindi un servizio offerto da un software come
l’application server o altro server specializzato nel compito.
La realizzazione dell’aspetto sicurezza e autenticazione, nel progetto sviluppato, si è
basata proprio su queste idee. Prima di tutto vi è da specificare come un utente può
accedere ad una web application qualsiasi e chi si occupa di gestire tali utenti a
livello generale.
La web application viene installata su un application server il quale, come dice il
nome stesso, fornisce ai vari client che si connettono ad esso l’uso di
un’applicazione ospitata. Questa affermazione fa capire subito che il primo soggetto
ad aver a che fare con gli utenti è proprio l’application server. In effetti è lui che
gestisce il servizio implementando direttamente il meccanismo d’autenticazione o
facendo uso di un server remoto specifico per questo compito. Quindi l’application
server si occupa di gestire l’accesso ad esso e di conseguenza anche alle sue
applicazioni installate. Esso in qualche modo (anche facendo ricorso a server di
autenticazione dedicati esterni) si occupa di identificare l’utente e gestire una policy
di accesso alle applicazioni ospitate per definire chi può accedere cosa. Gli utenti
che accedono alle applicazioni ospitate sono già stati in qualche modo filtrati.
Seguendo sempre la filosofia dichiarativa per la sicurezza, nel momento in cui
- 67 -
andiamo a configurare i cosiddetti deployment descriptor per una particolare
applicazione, ciò che facciamo è dire all’ambiente ospitante (l’application server)
come esso si deve comportare nei confronti dell’applicazione ospitata e di quali
servizi essa fa uso.
Oltre la configurazione dell’applicazione nei confronti dei servizi offerti
dall’application server, a seconda di quest’ultimo, è possibile specificare come
vengono implementati questi servizi sul server. Nel nostro caso possiamo andare a
specificare come deve essere implementato il servizio di autenticazione sul server.
In particolare in WebSphere possiamo definire quale registro utente vogliamo usare
per l’intero server. Ciò è configurabile tramite la console di amministrazione del
server. Si può scegliere fra tre tipi di registri utente: sistema operativo, directory
LDAP, personalizzato. Il servizio di directory (Oracle Internet Directory) è stato
usato nel contesto del progetto.
I vari sistemi di autenticazione disponibile sulla piattaforma J2EE sono stati elencati
e descritti quando si parlava di sicurezza nel capitolo 3. Il sistema adottato
nell’applicazione web è quello form-based con l’aggiunta della protezione SSL
come garanzia della riservatezza delle credenziali fornite dall’utente. In particolare
è stato usato anche il meccanismo di mutua autenticazione SSL. A questo punto è
bene chiarire il significato dell’uso di queste tecnologie combinate insieme. Il
meccanismo dell’autenticazione form-based fa uso di un nome utente e di una
password che vengono trasmesse in chiaro al server. Il compito di SSL è la cifratura
del canale di trasmissione tra browser e server, quindi delle credenziali trasmesse.
La mutua autenticazione prevede che sia il client sia il server si autenticano alle
relative controparti. Il processo di autenticazione SSL prevede come fase iniziale lo
scambio dei certificati delle rispettive parti. In seguito ogni parte (il browser e il
server) decide se ritenere valida l’identità del soggetto in base ad una propria policy
di attribuzione di fiducia o meno alle autorità certificatici. Dopodiché se le parti si
accettano viene creato il canale SSL. Da notare che l’uso dell’autenticazione
mediante certificati digitale è parte integrante opzionale solo del protocollo SSL e
quindi non può essere eseguita senza di questo. Le credenziali (nome utente e
- 68 -
password) vengono verificate tramite interrogazione al server LDAP. La figura
successiva mostra a grandi linee i componenti nel processo di autenticazione per il
sistema
Figura 4.1 autenticazione con OID
L'obiettivo finale è quello di fornire accesso alla servlet solo se l'utente fornisce le
corrette credenziali: si deve quindi utilizzare un meccanismo che permetta
l'autenticazione
e
la
autorizzazione
all'accesso
a
determinate
risorse.
Prendendo spunto dal meccanismo degli utenti e gruppi tipico di Unix, Java utilizza
un sistema di autenticazione ed autorizzazione basato sui ruoli: solo dopo aver
accertato che un utente appartiene ad un determinato ruolo, si potrà fornire l'accesso
solo alle risorse (statiche o dinamiche) autorizzate per quel determinato ruolo. Una
volta accertata l'identità dell'utente, il servlet container agisce utilizzando il concetto
di security constraint, associando il ruolo ad un insieme di risorse.
E necessario capire come avviene l’uso del servizio di autenticazione del server da
parte dell’applicazione. Questo è definito in maniera standard nelle specifiche J2EE,
infatti l’accesso ai servizi J2EE di un application server deve avvenire allo stesso
modo su tutti i server J2EE compliant. La specifica prevede per l’autenticazione
form-based la realizzazione di una pagina di login HTML o JSP contenente un form
html con dei parametri standard:
- 69 -
<FORM method="post" action="j_security_check">
<INPUT type="text" name="j_username" size="20">
<INPUT type="password" name="j_password" size="20">
<INPUT type="submit" name="action" value="entra">
</FORM>
L’azione di questo form deve corrispondere alla servlet “j_security_check”, essa è
la servlet messa a disposizione dal server per effettuare l’autenticazione. La servlet
prova a fare l’autenticazione al registro utenti del server se questa ha esito positivo
l’accesso alla risorsa protetta viene consentito altrimenti l’utente viene redirezionata
alla
pagina
di
errore
specificata
nella
configurazione.
Per
configurare
un’applicazione ad usare l’autenticazione form-based bisogna specificare nel suo
deployment descriptor l’intento di voler usare questo meccanismo e specificare la
pagina di login e la pagina di errore che verrà presentata all’utente quando
necessario. Le risorse (pagine HTML, JSP, servlet, ecc..) che devono essere protette
e quindi essere accedute solo previa autenticazione e verifica dei permessi deve
essere elencato sempre nel deployment descriptor. Per un approfondimento teorica
sulla protezione delle risorse e i permessi degli utenti ad accedervi si rimanda alla
discussione affrontata nel capitolo tre nella sezione sicurezza.
Per quanto riguarda l’adozione di tale meccanismo all’interno della web application
è stato necessario usare un accorgimento per il corretto funzionamento. Viene
presentata la pagina di login nel momento in cui un utente richiede una determinata
risorsa protetta, una volta aver verificato con esito positivo le credenziali dell’utente
la servlet j_security_check inoltra l’utente alla risorsa precedentemente richiesta.
Ma cosa succede, come nel nostro caso, quando la pagina protetta restituita dopo
l’autenticazione non viene richiesta esplicitamente dall’utente? Ciò accade al primo
accesso al sistema, infatti l’utente non richiama subito una pagina protetta bensì
direttamente la pagina di login. La servlet non sa in quale pagina inoltrare l’utente,
una volta effettuato il login, e magari viene rimandato alla pagina di default
dell’applicazione (la pagina index.htm). Nel progetto la pagina in cui inoltrare
- 70 -
l’utente dipende proprio dal tipo di utente che si autentica. Quindi è necessario
stabilire al volo in che pagina inoltrare l’utente subito dopo l’autenticazione della
servlet ma prima dell’inoltro alla pagina di default. Questo viene reso possibile
grazie ai cosiddetti filtri. Un filtro è un classe che può essere legata ad una o più
servlet e permette di eseguire operazioni subito prima o subito dopo l’esecuzione di
una servlet. Nel nostro caso è stato implementato un filtro che ha il compito di
conservare nella sessione il nome utente inserito al momento del login in modo che
la successiva servlet (PreHomepage) in base ad esso possa stabilire se dirottare
l’utente sulla homepage dedicata all’amministratore oppure a quella dell’avvocato.
La figura seguente spiega il flusso applicativo nel processo di autenticazione.
Figura 4.2 l’autenticazione
Gli utenti del sistema vengono conservati nel registro utenti che in questo caso è la
directory LDAP. Le informazioni che è necessario archiviare nei nodi dipendono
dal singolo sistema di autenticazione, da eventuali informazioni aggiuntive per la
gestione dell'autorizzazione e da informazioni ausiliarie che si desidera associare
agli utenti per la gestione. Possono essere previste anche ulteriori informazioni non
strettamente necessarie per l'autenticazione ma utili per altri scopi.
Come spiegato nella sezione “Le basi di dati” di questo capitolo i dati all’interno
della directory vengono memorizzati in degli attributi che sono raggruppati in
istanze di objectClass contenute nei nodi del DIT (struttura ad albero della
directory). Nell’implementazione della struttura del DIT si è dovuto costruire una
struttura relativamente semplice ma nella quale i nodi dedicati alla conservazione
- 71 -
degli utenti contenessero gli objectClass adeguati. La scelta è ricaduta
sull’objectClass standard inetOrgPerson (RFC 2798). Ricordiamo che gli
objectClass seguono gli stessi principi di derivazione ed ereditarietà della
programmazione orientata agli oggetti. Quindi questo objectClass è un estensione
(sottoclasse) di altri objectClass progettati per contenere dati sugli utenti come
l’objectClass Person. inetOrgPerson che è stato realizzato per completare il
precedente con gli attributi che negli anni si sono resi necessari, tra questi uno dei
più interessanti è userCertificate per la conservazione di certificati digitali.
I sistemi che utilizzano LDAP come base di dati per l'autenticazione, come nel
nostro caso, hanno tipicamente tre parametri configurabili per l'accesso e la ricerca
dei dati:
•
un nodo di inizio della ricerca che viene poi effettuata su tutti i figli. Talvolta
è possibile specificare la profondità con la quale effettuare la ricerca.
•
un filtro di ricerca in base al quale selezionare i nodi contenenti informazioni
utili al sistema di autenticazione, i filtri possono utilizzare lo standard LDAP
(RFC 2254) che permette strutture anche sofisticate o più semplicemente
solo sul tipo di objectClass del nodo.
•
Informazioni su come mappare gli attributi contenuti nel nodo con i dati
necessari al
sistema di autenticazione, ad esempio quale attributo è lo userid e quale è la
password.
Il mapping delle credenziali dell’utente agli attributi contenuti nel nodo può
avvenire, a seconda del tipo di credenziali, in diversi modi.
Ad esempio nel caso della nostra applicazione le credenziali di un utente sono il
nome utente e la password. Quindi è stato settato nella configurazione del registro
utenti (directory LDAP) del application server che l’attributo uid e l’attributo
userPassword in un’entry utente devono essere confrontati con le credenziali al
momento dell’autenticazione. Sul application server è stato anche settato un nodo
- 72 -
da dove iniziare le ricerche delle entry utente ed un filtro per selezionare solo le
entry che rappresentano effettivamente degli utenti.
Nel caso le credenziali sono certificati esistono due tipi di mapping.
Un metodo consiste nel selezionare uno o più attributi del certificato e confrontarli
per eseguire l’autenticazione con gli attributi contenuti nella directory.
L’altro metodo invece mappa il subject del certificato al corrispondente DN nella
directory
• 4.5 SICUREZZA
4.5.1 ARCHITTETURA
E stata implementata la sicurezza in modo prettamente dichiarativo per la web app.
questo tramite i servizi di sicurezza J2EE offerti dall’application server. Questo
paragrafo spiega quali sono stati i canali protetti relativi all’interazione dell’utente
con il server, l’application server con il database e con il servizio di directory.
Il protocollo che ha reso possibile la riservatezza dei dati all’interno del progetto è
SSLv3. Esso infatti è stato applicato sui due protocolli di comunicazioni usati,
HTTP e LDAP. I due protocolli diventano così protocolli sicuri di trasmissione
perché alla loro base viene usato SSL per cifrare i dati. Essi vengono quindi
chiamati rispettivamente HTTPS e LDAPS.
Il supporto lato client per SSL viene offerto dal browser (MS Explorer o Mozilla).
Dal lato server il supporto viene offerto dall’application server tramite
un’architettura a provider. In effetti è possibile installare e specificare quale di
questi deve essere utilizzato. Questi, come nel nostro caso dove è prevista la mutua
autenticazione client server, vanno configurati per poter usare i contenitori delle
chiave privati e dei certificati digitali presenti sul server.
- 73 -
Il server, per la gestione e conservazione dei certificati e delle chiave private proprie
fa uso di opportuni “key store” che sono dei file protetti da password e cifrati. In
particolare WebSphere si basa su due file, trust file e key file.
Il trust file contiene tutti i certificati cui ritiene attendibile il soggetto. In particolare,
vi sono tutti i certificati root delle autorità di certificazione a cui il server da fiducia,
ma vi possono essere anche certificati di utenti specifici.
Il key file contiene le proprie chiave private unitamente ai loro relativi certificati.
Esso viene usato esclusivamente dal server in tutti quei processi che necessitano
l’uso della chiave privata come ad esempio l’autenticazione server SSL.
La robustezza del sistema per l’autenticazione basata su certificati digitali sta nel
fatto che solo l’utente che possiede anche la chiave privata relativa al certificato
presentato è in grado di completare un’autenticazione.
Figura 4.3 schema autenticazione SSL
4.5.2 SMART CARD
I protocolli nel progetto che fanno uso di certificati digitali, come l’SSL, sono stati
interfacciati ad un dispositivo di crittografia esterno. Stiamo parlando della smart
card. In particolare è stata usata la nuovissima Carta Nazionale dei Servizi (CNS)
distribuita dall’ente certificatore delle camere di commercio.
- 74 -
Prima di proseguire è bene chiarire cosa sia una smart card. Una smart card è una
scheda di plastica delle dimensioni di una carta di credito in cui è inserito un
microprocessore. La smart card può essere considerato un vero è proprio computer
essendo dotata anche lei di memoria (ROM, RAM e EEPROM), software e capacità
elaborativi.
La CNS contiene un certificato di autenticazione, le cui caratteristiche sono stabilite
dalle regole tecniche, inoltre essa contiene anche un certificato per la firma digitale.
Nell’ambito del progetto è stata usata sia per l’autenticazione SSL, sia attraverso il
software Redattore Atti per la firma dei documenti.
Per poter effettivamente utilizzare queste funzionalità all’interno dell’applicazione
sono necessari altri componenti. Prima di tutto è necessario un lettore/scrittore di
smart card compatibile con il protocollo di comunicazione PC/SC. E stato usato il
lettore ACR38 e relativi driver PC/SC che hanno servono per interfacciare la
periferica con il PC, permettendo così la comunicazione tra la carta e il sistema
operativo. Inoltre perché un applicazione si interfacci in modo standard alla card
potendo far cosi uso delle sue funzionalità è necessaria una libreria che fornisca le
api della specifica smart card. Vi sono due principali tipi di architetture standard:
cryptoki (o PKCS11) e cryptoApi (MS CAPI).
Le PKCS#11 sono delle Application Programming Interface (API) che interfacciano
dispositivi crittografici, non solo smart card ma tutti i dispositivi che memorizzano
chiavi e sviluppano calcoli crittografici.
Forniscono una interfaccia standard che è indipendente dal dispositivo crittografico
per cui sono state sviluppate. Rendono le applicazioni in cui la crittografia è trattata
con queste API largamente indipendenti dai dispositivi.Vincolano all’utilizzo del
dispositivo crittografico per cui sono state sviluppate ovvero non consentono a
smart card di differenti fornitori di poter operare sulla stessa piattaforma
applicativa.
Il compito della smart card è fungere da contenitore sicuro per la chiave privata e
anche da unico ambiente per l’uso della chiave privata negli algoritmi. Essa
- 75 -
contiene anche i certificati di sottoscrizione e autenticazione. Tutte le operazioni di
crittografia vengono eseguite direttamente all’interno di essa. Ad esempio per la
firma di un file, ne viene calcolato l’hash e in seguito applicata la cifratura con la
chiave privata. L’uso della chiave privata è protetto tramite un PIN che l’utente
deve fornire ogni qualvolta viene richiesta un’operazione che comporti il suo uso.
Questo è un ulteriore PIN oltre a quello della smart card stessa.
- 76 -
- 77 -
- 78 -
RIFERIMENTI
BIBLIOGRAFIA
-Il processo civile telematico
di Francesco Buffa [Giuffrè Editore]
-IBM WebSphere v5.0 Security Websphere Handbook (sg246573)[IBM-Redbooks]
-Enterprise Java Security: Building Secure J2EE Applications 2004[Addison
Wesley]
-IBM Websphere Studio App Developer 5 Programming Guide - 2003[IBMRedbooks]
-Java Servlet Programming 2001 2ed [OReilly]
-XML in a Nutshell 2nd Ed 2002[Oreilly]
-Understanding and Deploying LDAP Directory Services 2nd Ed 2003[Addison
Wesley]
-Inside Java 2 Platform Security 2nd Ed 2003[Addison Wesley]
-Understanding PKI 2nd Ed 2002[Addison Wesley]
-Smart Cards: The Developers Toolkit[Prentice Hall]
-Internet Directory Administrator's Guide (a96574)[Oracle9i]
- 79 -
-Database Administrator guide for windows[Oracle9i]
-RFC 822 - Standard for the format of ARPA Internet text messages
-RFC 959 - FTP (File Transfer Protocol)
-RFC 2045 - MIME Part One (Format of Internet Message Bodies)
-RFC 2046 - MIME Part Two (Media Types)
-RFC 2047 - MIME Part Three (Message Header Ext for Non-ASCII Text)
-RFC 2048 - MIME Part Four (Registration Procedures)
-RFC 2049 - MIME Part Five (Conformance Criteria and Examples)
-RFC 2246 - The TLS Protocol Version 1_0
-RFC 2251 - LDAP v3 (Ligthweight Directory Access Protocol)
-RFC 2252 - LDAP v3 (Attribute Syntax Definitions)
-RFC 2253 - LDAP v3 (UTF-8 String representation of DN)
-RFC 2254 - LDAP v3 (The String Representation of LDAP Search Filters)
-RFC 2255 - LDAP v3 (The LDAP URL Format)
-RFC 2256 - LDAP v3 (X_500 User Schema for use with LDAPv3)
-RFC 2798 - Definition of the inetOrgPerson LDAP Object Class
-RFC 2829 - LDAP v3 ( Authentication Methods for LDAP)
-RFC 2830 - LDAP v3 (Extension for Transport Layer Security)
-RFC 3377 - LDAP v3 (Technical Specification)
-RFC 2315 - PKCS_7 (Cryptographic Message Sintax v1_5)
-RFC 2630 - CMS (Cryptographic Message Syntax) [Obsolete]
-RFC 2632 - S-MIME v3 (Certificate Handling)
-RFC 2633 - S-MIME v3 (Message Specification)
-RFC 3363 - CMS (Cryptographic Message Syntax)
-RFC 3369 - CMS (Cryptographic Message Syntax)
-RFC 3850 - S-MIME v3_1 (Certificate Handling)
-RFC 3851 - S-MIME v3_1 (Message Specification)
-RFC 3852 - CMS (Cryptographic Message Syntax)
-RFC 2459 - Internet X_509 Public Key Infrastructure Certificate and CRL Profile
- 80 -
-RFC 2559 - Internet X_509 Public Key Infrastructure Operational Protocols
LDAPv2
-RFC 2587 - Internet X_509 Public Key Infrastructure LDAPv2 Schema
-RFC 3280 - X_509 PKI Certificate and CRL Profile
-RFC 2617 - HTTP Authentication - Basic and Digest Access Authentication
LEGGI
-C.P.C.
Codice di Procedura Civile
-D.M. 14 ottobre 2004
Regole tecnico-operative per l'uso di strumenti informatici e telematici nel processo
civile
-D.P.R. 13-2-2001 n.123
Regolamento sull’uso di strumenti informatici e telematici nel processo civile, nel
processo amministrativo e nel processo dinanzi alle sezioni giurisdizionali della
corte dei conti
-D.M. 24 maggio 2001
Regole procedurali per la tenuta dei registri informatizzati degli uffici
-D.M. 27 marzo 2000 n. 264
Regolamento tenuta dei registri presso gli uffici giudiziari
-D.P.R. 28 dicembre 2000, n. 445
Testo Unico delle disposizioni legislative e regolamentari in materia di
documentazione amministrativa
- 81 -
RISORSE WEB
-http://www.processotelematico.giustizia.it
dal Ministero della Giustizia
-http://www.interlex.com
rivista giuridica online
-http://www.card.infocamere.it/
autorità di Certificazione
-http://www.jdom.org
classi java per manipolazione dati XML
-http://jakarta.apache.org/commons/
Apache components dove sono state trovate alcune classi utili come quella per
l’FTP..
-http://java.sun.com/j2ee/index.jsp
architettura J2EE
-http://java.sun.com/products/servlet/index.jsp
sito della sun sulle servlet
-http://java.sun.com/products/jsp/index.jsp
-sito della sun sulle jsp
-http://forums.oracle.com/forums/forum.jsp?forum=47
sito di Oracle Forum per OID (Oracle Internet Directory)
-http://forums.oracle.com/forums/forum.jsp?forum=154
- 82 -
sito di Oracle, Forum su programmazione Java e XML
-http://www.rsasecurity.com
laboratori che hanno definito gli standard PKCS
- 83 -
