Michele Santomauro - Progetto freESBee

Transcript

UNIVERSITA’ DEGLI STUDI DELLA BASILICATA
FACOLTÀ DI SCIENZE MATEMATICHE, FISICHE E NATURALI
CORSO DI LAUREA SPECIALISTICA IN INFORMATICA
TESI DI LAUREA SPECIALISTICA
POLITICHE DI SICUREZZA E GESTIONE
DELL'IDENTITÀ NEL SISTEMA PUBBLICO DI
COOPERAZIONE APPLICATIVA
Relatore
Prof. Giansalvatore MECCA
Candidato
Michele Santomauro
Matricola 32821
Sommario
Introduzione ............................................................................................................. 1
Capitolo 1 : Architetture SOA ................................................................................. 3
Web Service ......................................................................................................... 5
SOAP................................................................................................................. 6
WSDL ................................................................................................................ 7
UDDI ................................................................................................................. 8
Sicurezza nelle architetture SOA.......................................................................... 9
Sicurezza hardware ........................................................................................ 10
Sicurezza a livello trasporto ........................................................................... 10
Sicurezza del messaggio................................................................................. 11
Capitolo 2 : Cooperazione Applicativa .................................................................. 20
Architetture SOA nella cooperazione applicativa .............................................. 20
Specifiche del CNIPA – Il progetto SPCoop ........................................................ 21
Sistema informativo locale ............................................................................ 21
Porta di dominio ............................................................................................ 22
Accordo di Servizio......................................................................................... 24
Servizi di registro SICA ................................................................................... 25
Busta e-Gov .................................................................................................... 26
Requisiti di sicurezza del progetto ..................................................................... 28
Capitolo 3 : Progetto ICAR ................................................................................... 30
Organizzazione del progetto .............................................................................. 30
OpenSPCoop ...................................................................................................... 31
FreESBee ............................................................................................................ 34
Capitolo 4 : Task INF-3 e relative implementazioni ............................................. 39
I componenti dell’architettura........................................................................... 40
Lo scenario di riferimento .................................................................................. 43
Lo scenario nella cooperazione applicativa ....................................................... 44
Tecnologie di riferimento .................................................................................. 47
Reference Implementation ................................................................................ 47
Tecnologie di riferimento .............................................................................. 51
Integrazione nell’architettura SPCoop........................................................... 51
FreESBee-SP ....................................................................................................... 52
Progetto SIL-VIO............................................................................................. 54
Progetto Shibboleth ....................................................................................... 56
Scenario in cooperazione applicativa ............................................................ 57
Configurazione delle istanze .......................................................................... 64
Tecnologie di riferimento .............................................................................. 66
Capitolo 5 : Sperimentazione dell’architettura SPCoop ........................................ 67
Il caso d’uso “Identificazione assistito” ............................................................. 69
Il caso d’uso “Segnalazione ricovero” ................................................................ 73
Il caso d’uso “Variazione anagrafica” ................................................................ 75
Capitolo 6 : Soluzioni a confronto ......................................................................... 79
Sicurezza in OpenSPCoop e in FreESBee............................................................ 79
Reference Implementation vs FreESBee-SP ...................................................... 80
Schema delle differenze..................................................................................... 83
Appendice .............................................................................................................. 84
Bibliografia ............................................................................................................ 86
Introduzione
L’avvento di internet nella società dell’informazione ha segnato un cambiamento
radicale nel modo di pensare ed agire delle persone, in tutti gli ambiti,
soprattutto in quello professionale. Tale cambiamento ha interessato anche la
pubblica amministrazione, che si è trovata a dover far fronte ad una richiesta
sempre più pressante, da parte dei cittadini e delle imprese, di adozione di
strumenti che permettano, da un lato, di fruire di servizi telematici per la
compilazione di pratiche, e, dall’altro, di snellire le procedure burocratiche per
l’assoluzione delle stesse. Tale compito, ad oggi, è stato assolto dalla pubblica
amministrazione in maniera soddisfacente, sia mettendo a disposizione dei
cittadini una serie di servizi cosiddetti “G2C”, ossia “Government to Citizen”, a
cui è possibile accedere comodamente attraverso internet, sia adottando sistemi
che automatizzano e velocizzano l’elaborazione delle pratiche. Nonostante ciò,
da qualche anno a questa parte, si è via via definita una nuova esigenza, che
riguarda la necessità di mettere tutti gli enti della PA in comunicazione tra loro.
L’obiettivo a cui si vuole arrivare è quello di permettere, ad esempio, ad un
cittadino della regione Lombardia, di origini Lucane, che ha la necessità di avere
un certificato di nascita, di non recarsi necessariamente presso il comune di
nascita per ottenerlo, bensì, può recarsi presso il proprio comune di residenza, il
quale, per conto suo, in maniera telematica, può richiederlo al comune di
nascita. A tale scopo, nel 2005, il CNIPA (Centro Nazionale per l’Informatica nella
Pubblica Amministrazione – http://www.cnipa.it) ha avviato due progetti
paralleli, e stilato le specifiche per : la realizzazione di un’infrastruttura che
permetta l’interoperabilità tra tutte le pubbliche amministrazioni italiane
(progetto SPC - Sistema Pubblico di Connettività), e la cooperazione e la fruizione
dei servizi che le stesse mettono a disposizione (progetto SPCoop - Sistema
Pubblico di Cooperazione). Nell’ambito di questa tesi si approfondiscono soltanto
-1-
gli aspetti relativi ad SPCoop, con particolare attenzione alle tematiche
riguardanti la sicurezza.
-2-
Capitolo 1 : Architetture SOA
SOA è l’acronimo di Service Oriented Architecture, un’architettura software che,
come dice il nome stesso, è orientata ai servizi. La filosofia alla base è quella di
decentrare la “business logic” in unità logiche più piccole, per lo più indipendenti,
in grado di assolvere a specifici compiti, messi a disposizione sotto forma di
servizi. Questi ultimi, infatti, rappresentano il punto di forza di tutta
l’architettura, in quanto permettono l’interoperabilità tra sistemi eterogenei, al
fine di realizzare quello che è il cosiddetto “processo di business”. Per questo
motivo, quindi, non esiste una specifica piattaforma per realizzare questo tipo di
architetture, in quanto gli elementi che ne fanno parte, sono proprio i processi
applicativi già esistenti, opportunamente ristrutturati per l’erogazione di servizi.
Esempio di architettura distribuita
-3-
Le proprietà che contraddistinguono le architetture SOA sono :
•
loose coupling (basso accoppiamento) :
gli elementi che ne fanno parte sono indipendenti gli uni dagli altri
•
message orientation (orientamento ai messaggi) :
la comunicazione tra i componenti avviene attraverso scambio di
messaggi
•
description orientation (orientamento alla descrizione) :
la semantica di ciascun elemento viene descritta attraverso i metadati
e resa pubblica per coloro che vogliono usufruire del servizio reso
•
autonomia :
i componenti sono autonomi
•
riusabilità :
per promuovere il riuso di funzionalità
•
composizione :
i servizi resi da ciascun componente possono essere aggregati e
coordinati per formare una logica complessa
•
neutralità della piattaforma :
i messaggi hanno formati standard (ad esempio XML)
I componenti principali che operano in tali architetture sono :
•
Service Provider : è il componente che fornisce un servizio;
•
Service Consumer : è il componente che richiede un servizio;
•
Service Registry : è l’intermediario che ha il compito di pubblicare le
informazioni circa il servizio messo a disposizione dal
Service Provider.
-4-
L’interazione tra i tre componenti avviene nel seguente modo :
il Service
Provider mette a disposizione dei servizi, le cui caratteristiche vengono
pubblicate dal Service Registry (URL, modalità di accesso ecc). Quando il Service
Consumer ha la necessità di usufruire di un servizio, contatta il Service Registry
ottenendo tutte le informazioni che gli occorrono. Da quel momento in poi può
contattare direttamente il Service Provider ed ottenere i servizi di cui necessita.
Web Service
Di seguito viene riportata la definizione del W3C (World Wide Web Consortium –
http://www.w3.org) :
“E’ un sistema software progettato per supportare l'interoperabilità tra diversi
elaboratori su di una medesima rete; caratteristica fondamentale di un Web
Service è quella di offrire un'interfaccia software (descritta in un formato
automaticamente elaborabile quale, ad esempio, il Web Services Description
Language) utilizzando la quale altri sistemi possono interagire con il Web Service
-5-
stesso attivando le operazioni descritte nell'interfaccia tramite appositi
"messaggi" inclusi in una "busta" (la più famosa è SOAP): tali messaggi sono,
solitamente, trasportati tramite il protocollo HTTP e formattati secondo lo
standard XML.”
Fonte : http://it.wikipedia.org/wiki/Web_service
Questa tecnologia, da quanto si evince anche dalla definizione, si basa su un
certo numero di standard, quali SOAP, WSDL e UDDI, che ne permettono il
funzionamento. Da notare che i Web Service non sono legati alle architetture
SOA, tuttavia rappresentano dei candidati ideali ad essere utilizzati in tale ambito
grazie alla loro indipendenza dalla piattaforma ed al linguaggio e alla modalità
standard per definire l'interfaccia verso l’esterno.
SOAP
E’ l’acronimo di Simple Object Access Protocol e rappresenta uno standard per lo
scambio di messaggi tra componenti distribuiti. Può operare su diversi protocolli,
ma il più utilizzato è quello HTTP. I messaggi sono in formato XML e seguono la
configurazione Head – Body. L’Header è opzionale e contiene informazioni circa il
routing, la sicurezza e le transazioni, mentre il Body è obbligatorio e contiene il
messaggio vero e proprio scambiato tra le due parti (chiamato in gergo Payload).
<?xml version='1.0' encoding='utf-8'?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
…
</soapenv:Header>
<soapenv:Body>
…
</soapenv:Body>
</soapenv:Envelope>
Esempio di messaggio SOAP
-6-
WSDL
E’ l’acronimo di Web Service Description Language e rappresenta un linguaggio
formale, in formato XML, per descrivere l’interfaccia di un Web Service. Un
documento WSDL è composto da cinque elementi:
•
Types : definisce i tipi di dati coinvolti nello scambio dei messaggi (definiti
nel linguaggio XML Schema)
•
Message : specifica le informazioni sui parametri ed i loro tipi circa il
messaggio di input e output
•
PortType : indica le operazioni supportate da un servizio web
•
Binding : stabilisce il protocollo da utilizzare per lo scambio dei messaggi,
HTTP GET/POST, MIME o SOAP
•
Service : riporta l’URL al quale è possibile contattare il servizio
<wsdl:definitions name="Esempio"
targetNamespace="http://namespaces.esempio.com"
xmlns:es="http://www.esempio.com/EsempioWSDL.wsdl"
xmlns:esxsd="http://schemas.esempio.com/ EsempioWSDL.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<wsdl:types>
<xsd:schema targetNamespace="http://namespaces.example.com"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<xsd:element name="…">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="…" type="string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</wsdl:types>
<!—- Messaggio di richiesta -->
<wsdl:message name="messaggioRichiestaEsempio">
<wsdl:part name="body" element="esxsd:…"/>
</wsdl:message>
<!—- Messaggio di risposta -->
<wsdl:message name="messaggioRispostaEsempio">
<wsdl:part name="body" element="esxsd:…"/>
</wsdl:message>
-7-
<wsdl:portType name="portTypeEsempio">
<wsdl:operation name="…">
<wsdl:input message="es:messaggioRichiestaEsempio"/>
<wsdl:output message="es:messaggioRispostaEsempio"/>
<wsdl:fault message="es:messaggioFaultEsempio"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="bindingEsempio" type="es:portTypeEsempio">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="operationEsempio">
<soap:operation soapAction="http://www.esempio.com/Esempi"/>
<wsdl:input>
<soap:body use="literal"
namespace="http://schemas.esempio.com/EsempioWSDL.xsd"/>
</wsdl:input>
<wsdl:output>
</wsdl:output>
<wsdl:fault>
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="servizioEsempio">
<wsdl:documentation>Esempio file WSDL</wsdl:documentation>
<wsdl:port name="…" binding="es:bindingEsempio">
<soap:address location="http://www.esempio.com/Esempio"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Esempio di WSDL
UDDI
E’ l’acronimo di Universal Description, Discovery and Integration e rappresenta lo
strumento attraverso cui è possibile dinamicamente accedere ai servizi
disponibili sulla rete. Si compone di un registro, denominato UBR (UDDI Business
Registry), che contiene informazioni sui servizi disponibili. Tali informazioni sono
organizzate in modo da effettuare diversi tipi di ricerche basate sulla
consultazione di tre cataloghi differenti :
•
White Pages : contenenti informazioni generiche sull'azienda (ad
-8-
esempio la ragione sociale, l'indirizzo, ecc)
•
Yellow Pages : contenente una classificazione dei servizi sottoforma di
tassonomia per poter effettuare le ricerche in base alla
categoria a cui appartiene un servizio
•
Green Pages : contenente informazioni tecniche sui servizi e grazie alle
quali gli stessi possono essere invocati
Esempio di utilizzo del registro UDDI
Sicurezza nelle architetture SOA
I vantaggi offerti da SOA nella realizzazione di infrastrutture complesse, si
scontrano con la complessità di rendere una tale architettura completamente
sicura. Quello della sicurezza è un problema che al giorno d’oggi è molto sentito,
soprattutto nell’ambito informatico. Questo fenomeno è amplificato nelle
architetture SOA, in quanto non si parla più di un singolo sistema, ma di molti
-9-
sistemi indipendenti ed interoperanti, ciascuno dei quali deve agire nel rispetto
dei requisiti di sicurezza, al fine di non pregiudicare la stabilità dell’intera
infrastruttura. Al giorno d’oggi esistono una serie di strumenti, standard e
specifiche (per lo più in via di standardizzazione) il cui scopo è quello di garantire
la massima sicurezza possibile in tali architetture. Di seguito viene illustrato lo
stato dell’arte oggi in tale settore.
Sicurezza hardware
A livello hardware la sicurezza è garantita dai firewall XML, dispositivi in grado di
filtrare il traffico di rete a livello applicativo, agendo fino al livello 7 della pila
ISO/OSI. Il compito di tali apparecchi è quello di filtrare tutto il traffico XML, sia in
ingresso che in uscita, in base a regole prestabilite.
Sicurezza a livello trasporto
Il canale di comunicazione svolge un ruolo molto importante, in quanto ad esso è
affidato il compito di trasportare informazioni, dati e quant’altro, da un mittente
ad un destinatario. Avere a disposizione un canale sicuro limita, ma non evita, la
possibilità di attacchi del tipo MITM (Man in the middle), oppure Spoofing ecc.
Sia TLS (Transport Layer Security) che SSL (Secure Sockets Layer), sono due
protocolli crittografici che permettono di criptare la comunicazione tra sorgente
e destinazione a livello trasporto. TLS è uno standard IETF (Internet Engineering
Task Force) e rappresenta l’evoluzione di SSL, precedente protocollo sviluppato
da Netscape Corporation. L’utilizzo tipico che ne viene fatto è nelle applicazioni
client – server, più precisamente attraverso i browser web, infatti, viene
utilizzato soprattutto quando si eseguono operazioni come transazioni online,
inserimento di dati personali per l’accesso ad un servizio (nome utente e
password) ecc. Il funzionamento è basato sulla validazione, da parte del client (e
- 10 -
quindi del browser), della firma digitale contenuta in opportuni certificati che
risiedono sul server stesso. Ovviamente tali certificati sono validi soltanto se
vengono rilasciati da autorità preposte allo scopo, definite Certification
Authority. HTTPS rappresenta l’utilizzo del protocollo HTTP in un canale sicuro
criptato con SSL, il cui principio di funzionamento si basa sul concetto di
crittografia a chiave pubblica e privata ed i cui dettagli esulano dallo scopo di
questa tesi. Per quanto tali protocolli risultino essere impeccabili, in realtà sono
anch’essi vulnerabili ad attacchi, infatti, recenti studi, hanno dimostrato che una
vulnerabilità di tali protocolli è rappresentata dall’attività di rinegoziazione che
client e server effettuano periodicamente.
Sicurezza del messaggio
Dal momento che la sola sicurezza a livello trasporto non basta a garantire che la
comunicazione sia esente da rischi, è stato necessario definire altre specifiche
che permettono di salvaguardare la sicurezza dell’intero messaggio. Nell’ambito
dei web service, le specifiche che garantiscono la sicurezza dei messaggi SOAP è
parte di WS-*, termine con cui si indica l’insieme di specifiche che riguardano i
Web Service. Alcune di esse sono già diventate standard, altre, invece, sono in
fase di standardizzazione. Quelle più rilevanti sono :
•
WS-Security
o XML Signature
o XML Encryption
•
SAML (Security Assertion Markup Language)
•
XACML (eXtensible Access Control Markup Language)
- 11 -
Di seguito vengono analizzate nel dettaglio :
WS-Security, XML Signature e XML Encryption
E’ uno standard, promosso dalla OASIS (http://www.oasis-open.org), come
estensione di SOAP per rendere sicuri i messaggi scambiati tra Web Service.
Permette di garantire l’integrità e la confidenzialità grazie all’utilizzo di altri due
standard, XML Signature ed XML Encryption, entrambi promossi, invece, dal
consorzio W3C (http://www.w3.org). Il primo definisce le modalità con cui
apporre la firma digitale su un documento XML, mentre il secondo specifica
come criptare un messaggio XML. WS-Security prevede vari formati di firma e
vari algoritmi per la crittografia dei dati, come, ad esempio : certificati X.509,
Kerberos, USERID/Password, Asserzioni SAML, ecc. Tutte le informazioni
vengono riportate nell’header di un messaggio SOAP, pertanto vengono
elaborate a livello applicazione. Un esempio di messaggio SOAP con WS-Security
è il seguente :
<soap:Envelope …>
<soap:Header>
…
</soap:Header>
<soap:Body>
…
</soap:Body>
</soap:Envelope>
<soap:Envelope>
<soap:Header>
<wsse:Security
soap:mustUnderstand="1">
<wsu:Timestamp …>
<wsu:Created>…</wsu:Created>
<wsu:Expires>…</wsu:Expires>
</wsu:Timestamp>
<wsse:BinarySecurityToken …>
…
</wsse:BinarySecurityToken>
<xenc:EncryptedKey …>
<xenc:EncryptionMethod …>
<ds:DigestMethod/>
</xenc:EncryptionMethod>
<KeyInfo …>
<wsse:SecurityTokenReference>
<X509Data>
<X509IssuerSerial>
<X509IssuerName>
…
</X509IssuerName>
<X509SerialNumber>
…
</X509SerialNumber>
</X509IssuerSerial>
</X509Data>
</wsse:SecurityTokenReference>
- 12 -
</KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>
…
</xenc:CipherValue>
</xenc:CipherData>
<xenc:ReferenceList>
<xenc:DataReference …/>
</xenc:ReferenceList>
</xenc:EncryptedKey>
<ds:Signature>
<ds:SignedInfo>
<ds:CanonicalizationMethod …/>
<ds:SignatureMethod …/>
<ds:Reference>
<ds:Transforms>
<ds:Transform …/>
</ds:Transforms>
<ds:DigestMethod …/>
<ds:DigestValue>
…
</DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
…
</ds:SignatureValue>
<ds:KeyInfo>
<wsse:SecurityTokenReference>
<wsse:Reference …/>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
</soap:Header>
<soap:Body …>
<xenc:EncryptedData …>
<xenc:EncryptionMethod …/>
<xenc:CipherData>
<xenc:CipherValue>
…
</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedData>
</soap:Body>
</soap:Envelope>
Come si può notare dall’esempio, l’aggiunta della firma, unitamente alla
crittografia dei dati, aggiunge un overhead sia nel trasporto, sia nell’elaborazione
del messaggio stesso, in quanto, nel primo caso, la dimensione fisica risulta di
gran lunga maggiore di quella del messaggio originale, mentre, nel secondo caso,
- 13 -
è necessario un lavoro in più per decriptare ciò che si è ricevuto e verificare la
firma.
SAML
E’ l’acronimo di Security Assertion Markup Language. Rappresenta lo standard
per l’autenticazione e l’autorizzazione tra domini differenti attraverso l’uso di
messaggi XML. E’ promosso dalla OASIS e ad oggi è alla versione 2.0 . L’obiettivo
a cui cerca di assolvere SAML è quello di fornire una soluzione versatile, ma allo
stesso tempo funzionale, al problema del Multiple Sign On. Infatti,
ordinariamente, il service consumer è costretto all’autenticazione su ciascun
dominio nel quale intende richiedere l’erogazione di un servizio. Il motivo per cui
si è resa necessaria questa standardizzazione è dovuto al fatto che, le modalità e
le tecniche utilizzate per realizzare il Single Sign On, sono varie, ad esempio
attraverso l’uso dei cookie, il che portava in una direzione di disomogeneità, che
quindi rendeva impossibile l’interoperabilità tra sistemi eterogenei. Grazie a
questa soluzione, ciascun Service Consumer ha a disposizione un proprio profilo,
col quale richiedere l’accesso e l’erogazione di servizi ai vari domini. Questi ultimi
sono in grado di validare tale profilo ed erogare il servizio, qualora esso risulti
essere coerente con le politiche di sicurezza definite per quel dato servizio. In
questo modo l’operazione di Sign On viene effettuata soltanto una volta, per
l’acquisizione del profilo, ed utilizzata tutte le volte che viene richiesto. Il
meccanismo di funzionamento è basato sulle “asserzioni”, cioè pezzi di codice
XML che contengono proprio le informazioni che descrivono il richiedente, come,
l’identificativo univoco ed i relativi attributi. Lo standard prevede che tali
asserzioni vengano inserite all’interno della sezione WS-Security, che a sua volta
è contenuta nell’header di un messaggio SOAP.
- 14 -
Un esempio di asserzioni estratto da un messaggio è il seguente :
<saml:Subject>
<saml:NameID Format="…">…</saml:NameID>
<saml:SubjectConfirmation Method="…">
<saml:SubjectConfirmationData Address="127.0.0.1" InResponseTo="…"
NotOnOrAfter="20010-12-31T18:10:58.030"
Recipient="http://sp.unibas.it" />
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2008-11-28T18:05:58.030"
NotOnOrAfter="2008-11-28T18:10:58.030">
<saml:AudienceRestriction>
<saml:Audience>http://sp.unibas.it </saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2008-11-28T18:05:57.643"
SessionIndex="…"
SessionNotOnOrAfter="2008-11-28T18:35:57.643Z">
<saml:SubjectLocality Address="127.0.0.1" />
<saml:AuthnContext>
<saml:AuthnContextDeclRef>
</saml:AuthnContextDeclRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<saml:Attribute FriendlyName="title" Name="idTitle"
NameFormat="…">
<saml:AttributeValue xmlns:xs="…" xmlns:xsi="…"
xsi:type="…">
Borsista
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute FriendlyName="organizationUnit"
Name="idOrganizationUnit" NameFormat="">
<saml:AttributeValue xmlns:xs="…" xmlns:xsi="…" xsi:type="…">
Unibas
</saml:AttributeValue>
</saml:Attribute>
- 15 -
</saml:AttributeStatement>
</saml:Assertion>
L’immagine riportata di seguito mostra, invece, lo schema delle interazioni che
avvegono tra i vari componenti :
XACML
E’ l’acronimo di eXtensible Access Control Markup Language e rappresenta lo
standard, promosso dalla OASIS, che comprende :
•
un linguaggio per definire le policy, in formato XML, circa i requisiti di
accesso alle risorse, come, ad esempio, nome dell’organizzazione di
appartenenza, ruolo ricoperto all’interno dell’organizzazione, ecc;
•
un modello di processamento delle informazioni contenute nel profilo del
richiedente ed inviate assieme al messaggio di richiesta.
- 16 -
I componenti previsti dallo standard per realizzare il modulo di processamento
sopra menzionato sono :
•
PAP (Policy Administration Point) : è il componente in cui vengono
memorizzate e gestite le policy.
•
PDP (Policy Decision Point) : è il componente incaricato di valutare i
requisiti del profilo e decidere se permettere
o negare la fruizione del servizio richiesto.
•
PEP (Policy Enforcement Point) : è il componente che intercetta la
richiesta dell’utente ed esegue le azioni
decise dal PDP.
•
PIP (Policy Information Point) : è il componente di supporto al PDP che
fornisce informazioni aggiuntive come, ad
esempio, informazioni provenienti da
directory LDAP.
Un esempio di policy, richiesta e risposta è il seguente :
<Policy …>
<Target>
<Subjects>
<AnySubject/>
</Subjects>
<Resources>
<Resource>
<ResourceMatch …>
<AttributeValue …>
…
</AttributeValue>
<ResourceAttributeDesignator …/>
</ResourceMatch>
</Resource>
</Resources>
<Actions>
<AnyAction/>
</Actions>
</Target>
<Rule …>
<Target>
<Subjects>
<AnySubject/>
- 17 -
</Subjects>
<Resources>
<AnyResource/>
</Resources>
<Actions>
<Action>
<ActionMatch>
<AttributeValue …>
…
</AttributeValue>
<ActionAttributeDesignator/>
</ActionMatch>
</Action>
</Actions>
</Target>
<Condition>
<Apply …>
<SubjectAttributeDesignator …/>
</Apply>
<AttributeValue …>…</AttributeValue>
</Condition>
</Rule>
</Policy>
Policy
<Request>
<Subject>
<Attribute …>
<AttributeValue>
…
</AttributeValue>
</Attribute>
<Attribute>
<AttributeValue>
…
</AttributeValue>
</Attribute>
</Subject>
<Resource>
<Attribute>
<AttributeValue>
…
</AttributeValue>
</Attribute>
</Resource>
<Action>
<Attribute>
<AttributeValue>
…
</AttributeValue>
</Attribute>
</Action>
</Request>
<Response>
<Result>
<Decision>…</Decision>
<Status>
<StatusCode …/>
</Status>
</Result>
</Response>
Risposta
Richiesta
- 18 -
Attualmente XACML
ACML è alla versione 2.0, ma è in fase di approvazione la nuova
versione 3.0 che comprende una serie di miglioramenti riguardo nuove tipologie
di profili, nuovi attributi e datatypes, meccanismi di delega ecc. Di seguito è
riportato uno schema di interazione tra i componenti :
- 19 -
Capitolo 2 : Cooperazione Applicativa
L’idea della realizzazione di un’infrastruttura che permetta l’interoperabilità tra
le varie pubbliche amministrazioni italiane si concretizza nel 2005, con due
progetti denominati, rispettivamente, SPC ed SPCoop. L’ente promotore
dell’iniziativa è il CNIPA, Centro Nazionale per l’Informatica nella Pubblica
Amministrazione, che definisce una serie di specifiche per la realizzazione di
entrambi i progetti. Il primo è l’acronimo di Sistema Pubblico di Connettività, e
riguarda la realizzazione di un’infrastruttura di rete privata che colleghi tutte le
amministrazioni italiane. Il secondo, invece, è l’acronimo di Sistema Pubblico di
Cooperazione, e riguarda la realizzazione di un’infrastruttura software che
permetta la comunicazione e lo scambio di dati e/o informazioni tra i sistemi
informativi delle varie amministrazioni. Per quanto i due progetti siano partiti
insieme, viene da se che il completamento del primo è propedeutico al secondo,
in quanto non ci può essere scambio di informazioni, se prima non c’è un canale
di comunicazione che si fa carico del trasporto delle stesse. In questa tesi si
analizzano soltanto le caratteristiche di SPCoop, perché oggetto di studio.
Architetture SOA nella cooperazione applicativa
Lo sviluppo delle architetture SOA ha dato un notevole impulso alla definizione
delle specifiche del sistema SPCoop, in quanto, come si vedrà in seguito,
rientrano appieno tutti gli elementi, precedentemente visti, che compongono tali
architetture, ovviamente adattati per renderli più consoni al caso che si sta
trattando.
- 20 -
Specifiche del CNIPA – Il progetto SPCoop
Le specifiche pubblicate dal CNIPA riguardo il progetto SPCoop sono dieci, tutti
documenti che definiscono il quadro tecnico – implementativo dell’intera
infrastruttura. Gli elementi fondamentali che caratterizzano tale architettura
sono :
•
Sistema informativo locale
•
Porta di dominio
•
Accordo di servizio
•
Servizi di registro SICA
•
Busta e-Gov
Sistema informativo locale
Nel seguito sarà definito SIL. Come si intuisce dal nome, è il componente
attraverso cui si fa riferimento ai sistemi informativi di cui è dotata ciascuna
pubblica amministrazione. Rappresenta quindi l’endpoint da cui si originano,
rispettivamente, le richieste e le risposte per l’erogazione un servizio. A seconda
dei casi, tale componente si definisce fruitore, se effettua una richiesta ad un
altro componente; altrimenti, erogatore, se fornisce un servizio ad un altro SIL.
Nell’ottica delle architetture SOA tali elementi non sono altro che dei servizi web
che si scambiano messaggi in un formato XML “particolare”, così come vedremo
più avanti.
- 21 -
Esempio di SIL all’interno dell’infrastruttura
Porta di dominio
Nel seguito sarà indicata con il termine PdD. Rappresenta l’unico punto
d’ingresso nell’architettura SPCoop. E’ ad essa che vengono indirizzate tutte le
richieste e le risposte provenienti dai SIL, pertanto svolge una funzione di
gateway per tutti i messaggi in transito. Ogni dominio ne possiede una. Al suo
interno è composta a sua volta da un’architettura complessa che svolge
operazioni cosiddette di “imbustamento” e “sbustamento”, rispettivamente,
delle richieste e delle risposte; tale funzionalità sarà descritta nel dettaglio più
avanti. Oltre a queste due che sono le funzionalità principali della PdD, ci sono
anche altre funzionalità secondarie, ma non meno importanti, quali la tracciatura
del log dei messaggi in transito, la gestione della sicurezza del messaggio, la
verifica dei livelli di qualità offerti dalla stessa porta ecc. I due elementi più
importanti che compongono tale componente sono : la Porta Delegata (nel
seguito PD) e la Porta Applicativa (nel seguito PA). Entrambe sono i punti che
interfacciano i SIL con la PdD, e quindi con l’infrastruttura SPCoop.
- 22 -
La PD è l’elemento invocato dal SIL fruitore quando ha la necessità di usufruire di
un servizio. I compiti che deve svolgere sono due : prendere in consegna la
richiesta e trasformarla in un messaggio standard, conforme alle specifiche
SPCoop, e viceversa, cioè far pervenire il messaggio di risposta al richiedente.
La PA è invece incaricata di trasformare il messaggio, conforme alle specifiche
SPCoop, in un formato conforme allo standard SOAP, e di far pervenire, quindi, la
richiesta ad un SIL erogatore, ed il viceversa per la risposta.
Anche in questo caso, dal punto di vista di SOA, sia la PD che la PA sono dei
servizi web che inviano e ricevono messaggi da e verso altri servizi web,
rappresentati dai SIL.
Esempio delle porte di dominio all’interno dell’infrastruttura
- 23 -
Accordo di Servizio
Di seguito AS, è a tutti gli effetti un contratto, in formato XML, tra fruitore ed
erogatore, che definisce le modalità di erogazione e fruizione di un servizio. Le
informazioni contenute in un AS sono :
•
tipo e funzionalità del servizio
•
schema dei messaggi di richiesta e risposta
•
requisiti di sicurezza
•
requisiti di qualità
Ciascun AS si riferisce soltanto a due soggetti : l’erogatore ed il fruitore, il che
significa che se un soggetto intende usufruire di servizi messi a disposizione da
vari altri soggetti erogatori, deve stipulare un AS con ciascuno di essi. A causa di
questo fenomeno, la ridondanza di informazioni comuni, all’interno di ciascun
AS, potrebbe essere notevole, pertanto i documenti del CNIPA prevedono la
suddivisione di ciascun accordo in due parti : la parte comune e la parte specifica.
Nella parte comune sono riportate informazioni riguardanti il servizio, che
pertanto possono essere riutilizzabili tra più accordi. La parte specifica, invece,
prevede soltanto gli elementi caratteristici che differenziano ciascun accordo
dagli altri, come, appunto, i soggetti erogatore e fruitore.
Parte Comune
Parte Specifica
- 24 -
Dal punto di vista tecnologico, un AS è composto da vari WSDL : WSDL
Concettuale, WSDL Logico Fruitore e WSDL Logico Erogatore .
Servizi di registro SICA
Acronimo di Servizi di Interoperabilità, Cooperazione ed Accesso; sono, come dice
la parola stessa, componenti che forniscono servizi di supporto alla cooperazione
applicativa. Le attività che essi devono svolgere sono : la registrazione e la ricerca
degli Accordi di Servizio e dei soggetti SPCoop, la gestione ed il monitoraggio dei
livelli di servizio offerti, ecc.
Le informazioni gestite riguardano quindi :
•
i soggetti che operano in SPCoop
•
i servizi erogati da tali soggetti
•
gli accordi di servizio per l’accesso ai servizi
All’interno dell’architettura, tali componenti sono organizzati a livello gerarchico,
infatti, è previsto un Registro SICA Generale, che contiene tutte le informazioni
necessarie all’erogazione di servizi, e più Registri SICA Secondari, che, invece,
contengono parte delle informazioni contenute su quello generale. Questo
approccio è stato scelto perché permette di garantire una ridondanza delle
informazioni, utile nel caso in cui qualche registro non sia disponibile, ed allo
stesso tempo una rapidità nell’erogazione dei servizi, proprio grazie al fatto che
solo una parte delle informazioni risiede su ciascun registro, snellendo quindi le
attività di ricerca e registrazione. Nella specifica è previsto che ciascuna Porta di
Dominio contatti il registro per ottenere informazioni circa i soggetti ed i servizi
previsti nell’ Accordo di Servizio.
- 25 -
Esempio del registro SICA all’interno dell’infrastruttura
Busta e-Gov
Rappresenta il messaggio scambiato all’interno dell’architettura SPCoop tra PdD.
Non è altro che un messaggio SOAP “elaborato”, cioè è un messaggio che
mantiene la struttura prevista dallo standard SOAP 1.1 (un solo header ed un
solo body), ma al cui interno vengono specificate informazioni aggiuntive, utili al
trattamento ed all’elaborazione da parte delle varie PdD. Tale busta viene
generata dalle stesse porte di dominio a seguito della trasformazione del
messaggio di richiesta proveniente da un SIL. Eccone un esempio :
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<eGov_IT:Intestazione …>
<eGov_IT:IntestazioneMessaggio>
<eGov_IT:Mittente>
<eGov_IT:IdentificativoParte …>
</eGov_IT:Mittente>
<eGov_IT:Destinatario>
<eGov_IT:IdentificativoParte …>
</eGov_IT:Destinatario>
<eGov_IT:ProfiloCollaborazione>…</eGov_IT:ProfiloCollaborazione>
<eGov_IT:Servizio …>…</eGov_IT:Servizio>
<eGov_IT:Azione>…</eGov_IT:Azione>
- 26 -
<eGov_IT:Messaggio>
<eGov_IT:Identificatore>…</eGov_IT:Identificatore>
<eGov_IT:OraRegistrazione …>…</eGov_IT:OraRegistrazione>
</eGov_IT:Messaggio>
<eGov_IT:ProfiloTrasmissione …/>
</eGov_IT:IntestazioneMessaggio>
<eGov_IT:ListaTrasmissioni>
<eGov_IT:Trasmissione>
<eGov_IT:Origine>
<eGov_IT:IdentificativoParte …> </eGov_IT:IdentificativoParte>
</eGov_IT:Origine>
<eGov_IT:Destinazione>
<eGov_IT:IdentificativoParte …>…</eGov_IT:IdentificativoParte>
</eGov_IT:Destinazione>
<eGov_IT:OraRegistrazione …>…</eGov_IT:OraRegistrazione>
</eGov_IT:Trasmissione>
</eGov_IT:ListaTrasmissioni>
</eGov_IT:Intestazione>
</soap:Header>
<soap:Body>
…
</soap:Body>
</soap:Envelope>
Come si può notare, tale messaggio è specifico per il dominio SPCoop, pertanto,
risulterebbe non comprensibile per i SIL. E’ per questo motivo che, prima di
essere inoltrato, è necessario che venga trasformato in un messaggio conforme
allo standard SOAP, attraverso l’operazione di sbustamento. Tale operazione,
assieme a quella di imbustamento, viene effettuata automaticamente dalla Porta
di Dominio, nelle operazioni di inoltro dei messaggi di richiesta e di risposta,
generati dai SIL, verso l’infrastruttura di cooperazione applicativa. Nello specifico,
il messaggio originale, viene scomposto nella parte Header e nella parte Body. Le
informazioni, contenute in ciascuna sezione, vengono inserite nelle relative
sezioni Header e Body di un nuovo messaggio SOAP, conforme, però, al formato
della busta e-Gov. Il motivo, per cui è necessario effettuare questa
trasformazione, è che tale messaggio contiene informazioni aggiuntive utili al
processamento dello stesso, da parte delle varie Porte di Dominio, durante il suo
tragitto. Di seguito è riportata un’immagine dell’intera infrastruttura di
cooperazione applicativa.
- 27 -
Vista globale dell’infrastruttura
Requisiti di sicurezza del progetto
Dal momento che i dati scambiati nell’ambito della cooperazione applicativa
sono molto sensibili, è necessario garantire elevati livelli di sicurezza riguardo la
gestione degli stessi.. Pertanto, in un’architettura distribuita di questo genere, è
obbligatorio tenere in considerazione
consid
i seguenti requisiti :
•
Identificazione : stabilire univocamente chi sta richiedendo il servizio a
cui si cerca di accedere
•
Autenticazione : stabilire senza dubbio che chi sta richiedendo il
servizio sia veramente colui che afferma di essere
•
Autorizzazione : stabilire se il fruitore è autorizzato a richiedere lo
specifico servizio
- 28 -
•
Integrità : garantire che non ci siano state manomissioni nelle
informazioni trasmesse
•
Confidenzialità : garantire che solo erogatore e fruitore del servizio
abbiano visibilità sulle informazioni trasmesse
•
Tracciamento : mettere in atto meccanismi che permettano di
tracciare qualsiasi evento legato
all’erogazione/fruizione del servizio, in maniera da
poter analizzare tali tracce per scoprire eventuali
problemi
•
Non ripudio : permette di provare l'identità di coloro che hanno preso
parte ad una determinata transazione
Secondo le specifiche SPCoop, questi requisiti sono garantiti da tutti i
componenti dell’infrastruttura, infatti, ad esempio, nella PdD, vengono garantiti :
•
Identificazione
•
Autenticazione
•
Autorizzazione
•
Confidenzialità
•
Non ripudio
Inoltre, durante lo scambio di messaggi sia tra le Porte di Dominio che tra SIL e
Porte Delegate, vengono utilizzate tecnologie opportune, quali :
•
HTTPS per il trasporto sicuro delle informazioni sul protocollo HTTP
•
WS-Security per la crittografia e la firma dei messaggi SOAP (tra SIL e
Porte Delegate) e delle buste e-Gov (tra Porte di Dominio stesse e tra
Porte di Dominio e NICA)
- 29 -
Capitolo 3 : Progetto ICAR
Le specifiche di SPCoop si concretizzano attraverso il progetto ICAR, acronimo di
Interoperabilità e Cooperazione Applicativa tra le Regioni. Tale progetto nasce
come iniziativa, promossa dalle regioni, con il fine di rendere possibile, come dice
il nome stesso, l’interoperabilità e la cooperazione applicativa tra gli organi
aderenti. Inizialmente vi prendono parte soltanto sedici regioni italiane ed una
provincia autonoma, ma nel seguito hanno aderito anche tutte quelle rimanenti.
Il coordinamento delle attività è stato assegnato al CISIS, Centro Interregionale
per i Sistemi Informatici, Geografici e Statistici, che tuttora cura le attività
di bootstrap dell’intera infrastruttura sul territorio italiano e pianifica ulteriori
sviluppi.
Organizzazione del progetto
Per una corretta realizzazione, il progetto è stato suddiviso in task infrastrutturali
e task applicativi. I task infrastrutturali previsti sono tre e sono :
•
INF-1 : Infrastruttura di base per la Cooperazione Applicativa Interregionale
•
INF-2 : Gestione di Strumenti Interregionali di Service Level Agreement
•
INF-3 : Sistema Federato Interregionale di Autenticazione
Tali task sono trasversali a tutto il progetto, in quanto definiscono l’infrastruttura
sulla quale si baserà la cooperazione applicativa.
I task applicativi, invece, sono sette, e caratterizzano specifici domini applicativi
sottoforma di servizi SPCoop. Nello specifico sono :
•
AP-1 : Cooperazioni e Compensazioni Sanitarie Interregionali
•
AP-2 : Cooperazione tra sistemi di Anagrafe
•
AP-3 : Area Organizzativa Omogenea
- 30 -
•
AP-4 : Lavoro e Servizi per l’Impiego
•
AP-5 : Tassa automobilistica
automobili
regionale
•
AP-6 : Osservatorio Interregionale sulla rete
r
distributiva dei carburanti
•
AP-7 : Sistema Informativo Interregionale
Interregionale di Raccordo con Cinsedo
Di seguito è riportato uno schema dell’organizzazione del progetto :
Organizzazione del progetto ICAR
Per ciascuno di questi task è stata individuata una regione, cosiddetta “capofila”,
“c
che ha il compito di sviluppare e rendere disponibile, nell’architettura SPCoop, il
task assegnato. Quello della
de Regione Basilicata è il task AP-1.
OpenSPCoop
La soluzione di riferimento per ICAR è rappresentata dal progetto OpenSPCoop
(http://www.openspcoop.org/
ww.openspcoop.org/),
),
un’implementazione
open
source
delle
specifiche del CNIPA. Comprende
omprende tutti gli elementi architetturali,
architetturali, quali : Porta di
dominio, Registro SICA, ecc. E’ una soluzione che si basa sulla piattaforma J2EE
ed utilizza come server applicativo JBOSS,, sfruttandone alcune funzionalità
integrate, quali le code JMS (Java Message Service) e gli MDB (Message
Message Driven
Bean) ecc. Le altre tecnologie utilizzate sono JiBX ed AXIS per la realizzazione dei
- 31 -
web service. Il componente più importante e più complesso di tutta la soluzione
è la Porta di Dominio, in quanto racchiude al suo interno tutti i meccanismi alla
base del funzionamento di SPCoop. Di seguito è riportato uno schema della PdD
SPCoop, estratto dalla documentazione ufficiale del progetto, che mostra proprio
quanto sia complesso questo componente.
Architettura della Porta di Dominio OpenSPCoop
Il cuore è rappresentato dal modulo di controllo, che svolge funzioni molto
importanti, come, ad esempio :
•
la gestione della sicurezza, in termini di autorizzazione e tracciamento dei
messaggi in transito attraverso la PdD
- 32 -
•
l’imbustamento
imbustamento delle richieste, che consiste nel trasformare il messaggio
SOAP proveniente dai SIL nel formato della busta e-Gov
•
lo sbustamento delle risposte, che consiste nell’attività contraria, cioè,
trasformare la busta e-Gov
e Gov nel messaggio SOAP interpretabile dai SIL
Ovviamente si interfaccia con il registro dei servizi per acquisire le informazioni
info
necessarie al processamento
mento delle richieste / risposte.
Al fine di evitare la comunicazione punto – punto tra le varie PdD, in ICAR sono
stati definiti dei componenti aggiuntivi,
aggiuntivi non previsti
revisti nelle specifiche SPCoop. Tali
Tal
componenti sono denominati NICA (Nodo
Nodo di Interconnessione per la
Cooperazione Applicativa).
Applicativa Si tratta di PdD “evolute”, il cui scopo è quello di
interconnettere diversi domini cooperanti tra loro. Con l’aggiunta di questo
componente, l’architettura di SPCoop si trasforma nella seguente :
Esempio di architettura SPCoop con NICA
- 33 -
Come si può osservare dall’immagine, l’adozione di tali componenti ha definito
una struttura gerarchica, in cui ciascuna pubblica amministrazione ha una propria
PdD. Tutte le PdD appartenenti ad un dominio afferiscono ad un unico NICA, il
quale si preoccupa di instradare i messaggi agli altri NICA definiti per gli altri
domini.
FreESBee
Si tratta di un progetto open source, alternativo ad OpenSPCoop, che nasce nel
2007, a seguito di una convenzione stipulata tra la Regione Basilicata e
l’Università degli studi della Basilicata (http://freesbee.unibas.it/). L’obiettivo del
progetto è quello di re implementare le specifiche definite dal CNIPA, attraverso
soluzioni architetturali più snelle ed efficienti di quelle utilizzate per lo sviluppo di
OpenSPCoop, in modo da rendere tutta l’architettura di cooperazione più snella
e leggera. Dal punto di vista tecnologico, infatti, FreESBee utilizza come server
applicativo Apache Tomcat, come tecnologie per il trasporto dei messaggi : ESB
(Enterprise Service Bus), mentre per l’elaborazione e l’interfacciamento ai SIL
attraverso i web service : CXF ed i componenti EIP (Enterprise Integration
Pattern). Proprio grazie a questi ultimi, che rappresentano uno strumento
innovativo sia nell’ambito della progettazione che in quello dello sviluppo, è
stato possibile riprogettare gli elementi dell’architettura in maniera abbastanza
rapida ed efficace. Il motivo di ciò deriva dal fatto che gli EIP definiscono una
serie di pattern che rappresentano dei componenti elementari, una sorta di
“mattoncini LEGO”, che possono essere collegati l’un l’altro. Ovviamente tali
pattern definiscono soltanto una struttura scheletro, al cui interno dev’essere
implementato il codice che permette di svolgere le funzionalità richieste.
Ciascuno degli elementi, da un punto di vista logico, è rappresentato da un
simbolo grafico; ciò significa che una volta collegati tra di loro, si può ottenere
- 34 -
anche una rappresentazione grafica dell’architettura realizzata, utilizzabile a
scopo di documentazione
ntazione.
E’ secondo questi principi che è stata rivista e realizzata l’implementazione
’implementazione della
PdD e degli altri componenti dell’architettura SPCoop.
SPCoop. Ecco di seguito lo schema
della PdD di freESBee riconcettualizzata :
Vista globale della Porta di Dominio di FreESBee – Invio di una richiesta / risposta
Nell’immagine
immagine viene illustrato il percorso fatto da un messaggio di richiesta /
risposta inviato da un SIL alla propria Porta di Dominio. Vengono descritti
macroscopicamente i pattern che la compongono,
compongono, senza entrare nel merito dei
moduli di imbustamento e sbustamento, che a loro volta sono stati
completamente riconcettualizzati.
- 35 -
Di
seguito,
invece,
è
riportato
lo
schema
che
descrive,
sempre
macroscopicamente, il percorso fatto dal messaggio precedente,
precedente, quando arriva
alla Porta di Dominio, per l’inoltro della risposta al SIL richiedente, oppure della
richiesta al SIL erogatore.
Vista globale della Porta di Dominio di FreESBee – Inoltro della risposta / richiesta
Come nella soluzione SPCoop, anche in FreESBee,, il cuore di tutta la Porta di
Dominio è rappresentato dai moduli di imbustamento e sbustamento. Non a
caso nelle immagini precedenti, tali moduli sono stati raffigurati come semplici
blocchi all’interno della PdD. In realtà essi hanno richiesto
richiesto il maggior lavoro di
riconcettualizzazione in termini di pattern EIP.
Di seguito sono riportati gli schemi di dettaglio sia del modulo di imbustamento
che di quello di sbustamento.
- 36 -
Vista di dettaglio dei moduli di imbustamento e sbustamento della PdD di FreESBee
- 37 -
Vista globale della Porta di Dominio di FreESBee – Invio di una richiesta / risposta
A differenza dell’immagine utilizzata per descrivere la PdD di OpenSPCoop, il
ruolo svolto da ciascun componente è reso, chiaramente, dal simbolo, dal nome
e dalla descrizione definita per ciascun pattern. Questa è la dimostrazione del
fatto che l’utilizzo di tali soluzioni può essere anche utile per fini di
documentazione, facilmente interpretabile e comprensibile, senza la necessità di
ricorrere alla stesura di documenti il più delle volte non chiari.
Alla fine dei lavori, seguendo sempre questi stessi principi, sono stati realizzati i
tre moduli software conformi alle specifiche dei rispettivi task infrastrutturali
(INF-1, INF-2 ed INF-3), il test dell’intera architettura e lo sviluppo di un sistema
per la simulazione dei SIL.
- 38 -
Capitolo 4 : Task INF-3 e relative implementazioni
Il task infrastrutturale INF-3, nel progetto ICAR, prevede la realizzazione del
“Sistema Federato Interregionale di Autenticazione”, con conseguente
implementazione del paradigma di Single Sign On (SSO), che prevede, una volta
effettuata l’autenticazione sul dominio, l’accesso a più risorse, senza dover ogni
volta autenticarsi per ciascuna di esse. La regione capofila incaricata di ciò è il
Piemonte, che ha definito una serie di specifiche, e rilasciato la Reference
Implementation, di un sistema basato sulla gestione ed utilizzazione delle
identità digitali all’interno del dominio di cooperazione.
Per ciò che riguarda la documentazione prodotta, sono stati definiti :
•
Un modello logico di riferimento dell’infrastruttura interregionale di
autenticazione ed autorizzazione
•
Un modello architetturale di riferimento del sistema federato
interregionale di autenticazione
•
Una serie di specifiche che descrivono le interfacce interne ed esterne
Una cosa molto importante da precisare è che nell’ambito dello scambio di
informazioni tra PdD, attraverso buste e-Gov, si assume di disporre di un canale
protetto, sicuro ed affidabile, in quanto INF-3 prescinde da questo, e si posiziona
al livello superiore, garantendo i meccanismi per la cooperazione inter–dominio;
mentre, al livello ancora superiore, i servizi cooperano in maniera del tutto
trasparente.
- 39 -
Di seguito è riportato uno schema che mostra la pila infrastrutturale di ICAR
appena descritta :
Pila infrastrutturale di ICAR
I componenti dell’architettura
Un ruolo fondamentale all’interno del task è rappresentato dalle Autorità di
certificazione, componenti dell’architettura a cui, per definizione, può essere
data fiducia da parte di altre entità coinvolte nel processo di cooperazione, circa
la veridicità delle informazioni prodotte. Quelle più importanti in ICAR sono
prevalentemente tre :
•
Profile Authority : sono i componenti incaricati di gestire i profili degli
utenti. Questo perché ciascun utente può possedere
diversi profili, come, ad esempio, il profilo di impiegato
del comune, attraverso il quale può accedere alle
procedure interne per la risoluzione di pratiche,
oppure, il profilo di cittadino, per accedere ai servizi
per i cittadini messi a disposizione sempre dal comune
•
Certification Authority : sono i componenti che certificano l’identità di un
- 40 -
utente, previa autenticazione attraverso diverse
tipologie di credenziali, come : nome utente e
password, oppure codice fiscale e PIN ecc.
•
Attribute Authority : sono i componenti che certificano gli attributi
contenuti nel profilo di un utente. Tali attributi
vengono utilizzati durante il processo di verifica
dell’autorizzazione all’accesso ad una risorsa. Un
esempio di attributi sono : la mansione svolta,
l’organizzazione presso cui si lavora, il titolo di
studio ecc.
Il formato delle informazioni rilasciate da tali autorità è conforme allo standard
SAML 2.0, pertanto, per convenzione, esse vengono definite asserzioni.
Ovviamente, proprio perché rilasciate da un’entità certificata e non da un
elemento qualunque, esse sono considerate attendibili. Affinché un’entità di
certificazione sia attendibile, ed evitare fenomeni secondo cui, una qualunque
autorità possa certificare qualsiasi attributo, è obbligatorio, da parte dell’ente
certificatore, apporre la propria firma digitale sugli attributi da esso rilasciati.
Questo però non basta, in quanto è stata prevista l’esistenza di un organismo
super partes, esterno al dominio, definito Garante, che è considerato a sua volta
affidabile da parte delle varie autorità, e che appone anche la sua firma sulle
certificazioni rilasciate, al fine di avere un più elevato livello di sicurezza.
- 41 -
Organizzazione delle varie autorità e relazioni con il Garante
Altri due componenti importanti all’interno dell’architettura di INF-3
3 sono lo User
Agent ed il Service Provider.
Provider Il primo rappresenta gli utenti che interagiscono con
il sistema, tipicamente un browser web, mentre il secondo rappresenta un
generico fornitore di servizio, nonché l’elemento a cui spetta il compito di
verificare se le informazioni fornite per l’accesso / erogazione del servizio sono
coerenti e conformi ai requisiti di sicurezza stabiliti. Per la verifica
dell’autenticazione ed autorizzazione, tale componente si avvale dell’ausilio di
altri due componenti, l’Access
l’
Manager (o Local Proxy) ed il Gestore delle
Politiche di Autorizzazione.
Autorizzazione. Il primo ha il compito di accedere alle varie autorità di
certificazione, per ottenere la certificazione degli attributi giunti assieme alla
richiesta; il secondo, invece, ha il compito di verificare che tali attribuiti siano
s
conformi ai requisiti richiesti per l’erogazione del servizio. Ovviamente all’interno
- 42 -
dell’infrastruttura è presente un registro, accessibile da tutte le comunità
federate, che contiene l’URL delle varie PA, CA e AA.
Lo scenario di riferimento
Lo scenario di riferimento definito dalle specifiche è il seguente : tutto ha origine
attraverso lo User Agent (in seguito UA), che richiede una risorsa al Service
Provider (in seguito SP) il quale, come prima cosa controlla se lo UA è
autenticato. Qualora non lo fosse, invia una richiesta di autenticazione al Local
Proxy (in seguito LP), il quale a sua volta la rigira allo UA. A questo punto lo UA
introduce le proprie credenziali e specifica qual è la Profile Authority (in seguito
PA) desiderata. Tale risposta viene così inoltrata al LP, il quale interroga il registro
per conoscere la URL della PA. Ottenuto l’URL, il LP interroga la PA per ottenere il
nome della Certification Authority (di seguito CA) scelta dall’utente. Come prima,
il LP interroga il registro per risolvere la URL della CA, ed una volta ottenuta
l’informazione, inoltra a quest’ultima una richiesta di autenticazione, con la
quale la CA inizia con lo UA la cosiddetta “challenge di autenticazione”. Al
termine di questa fase il LP avrà acquisito un’ asserzione generata dalla CA che
invia allo UA il quale a sua volta la gira al SP. A questo punto l’utente è
autenticato e il SP è in possesso della relativa asserzione. Lo scenario procede
con la verifica dell’autorizzazione. Il SP, come prima cosa, controlla se UA è
autorizzato per l’accesso alla risorsa richiesta, e supponiamo che non lo sia.
Come per l’autenticazione, il SP invia una richiesta al LP, il quale determina quale
sia la PA che contiene il profilo utente. Quest’azione può essere compiuta in due
modi : mantenendo una cache delle informazioni recuperate durante la fase di
autenticazione,
oppure
richiedendo
allo
UA,
durante
l’operazione
di
autenticazione, di specificare qual è la PA da cui desidera farsi rilasciare gli
attributi. Il LP chiede quindi alla PA il profilo dell’utente ed interroga il registro
per conoscere l’ URL della / delle Attribute Authority (di seguito AA) specificate
- 43 -
nel profilo selezionato. A questo punto il LP richiede alle AA gli attributi per lo
UA, e queste gli restituiscono le asserzioni con i relativi attributi. Il LP estrae le
asserzioni e le invia all SP.
SP. Quest’ultimo, ricevute le asserzioni, le valida rispetto
alle politiche
iche di accesso definite per il servizio, e se risultano essere coerenti,
fornisce la risorsa richiesta.
L’immagine seguente mostra l’interazione tra i vari componenti finora descritti :
Interazioni nello scenario di riferimento di INF-3
INF
Nel gergo di INF-3,
3, l’insieme di asserzioni raccolte dal LP, prende il nome di
“portafoglio
portafoglio di asserzioni”.
asserzioni
Lo scenario nella cooperazione applicativa
Lo scenario di riferimento precedentemente descritto rimane inalterato anche
nell’ambito dell’interazione in cooperazione applicativa, infatti, prima di
effettuare una richiesta, si assume che il modello di INF-3
INF 3 abbia acquisito il
- 44 -
portafoglio delle asserzioni
asserzioni relative all’utente richiedente, in termini di identità
ed attributi, ed inserito tale elemento nella richiesta rivolta alla PdD. Una volta
che tale richiesta è giunta a destinazione, essa risulta essere completa di tutte le
informazioni necessarie per
per la verifica e l’autorizzazione all’accesso delle risorse.
Il fatto di avere il portafoglio delle asserzioni completo all’interno della stessa
richiesta è un vantaggio notevole, in quanto non è necessario, in fase di verifica,
prima dell’erogazione del servizio,
servizio, consultare ulteriori autorità per sopperire ad
eventuali dati mancanti. In questo modo si raggira il problema secondo cui, le
stesse autorità, per poter fornire le informazioni richieste a causa di dati
mancanti,, hanno bisogno a loro volta di verificare
verificare l’autenticazione e
l’autorizzazione del richiedente, ma quest’ultimo potrebbe non avere i privilegi
sufficienti per accedere a tali informazioni,
informazioni che riguardano,, quindi, un soggetto
appartenente ad un dominio diverso, ottenendo così lo spiacevole risultato
ris
di
non poter erogare il servizio.
Di seguito viene riportata una rappresentazione di tale scenario :
Scenario di integrazione di INF-3
INF all’interno di SPCoop
- 45 -
Come al solito tutto lo scenario lo innesca lo UA, che contatta un Service Provider
del dominio richiedente (di seguito SPDR), che in questo caso rappresenta il
front-end con cui lavora l’operatore. Quest’ultimo accede all’infrastruttura di
autenticazione e autorizzazione del proprio dominio per verificare che l’utente
abbia diritto all’accesso. Per fare questo interroga il componente GPADR, che
accede al profilo del servizio e passa il controllo al LPDR, che a sua volta contatta i
vari certificatori, costruisce il portafoglio delle asserzioni e lo restituisce al GPADR.
Il GPADR, sulla base delle informazioni contenute nel portafoglio, può effettuare il
policy enforcement ed abilitare l’utente all’accesso al SPDR, a cui trasmette
l’intero portafoglio delle asserzioni. Il messaggio giunge così alla PdDDR, e da
questa alla PdDDE (dominio erogatore). Per il transito tra la PdDDR e la PdDDE il
messaggio viene dapprima criptato e firmato, rispettando lo standard
WS-Security, e successivamente affidato al livello infrastrutturale INF-1 per il
trasporto su canale sicuro HTTPS. Una volta giunto alla PdDDE, il messaggio viene
prima decriptato, verificata la firma, e se è valido viene inoltrato al SPDE.
Quest’ultimo richiede al sistema federato di autenticazione e autorizzazione INF3 un controllo sull’identità e sul ruolo del richiedente, passando il portafoglio
delle asserzioni al GPADE, il quale effettua il policy enforcement utilizzando le
asserzioni contenute nel portafoglio giunto assieme alla richiesta. Dal momento
che gli attributi sono controfirmati dal Responsabile del Dominio di Cooperazione,
il GPADE attribuisce il corretto valore e fiducia ad essi. A questo punto, se i dati
ricevuti lo consentono, il GPADE comunica a SPDE che il richiedente è abilitato ad
usufruire del servizio.
Per come è strutturata l’architettura, ora il richiedente di SPDE è il SPDR e non più
lo UA. Ciò significa che nel portafoglio delle asserzioni ricevuto, il policy
enforcement sarà effettuato sulle asserzioni relative a SPDR.
- 46 -
Eseguito il servizio, ha ora inizio l’interazione del flusso dei messaggi di risposta,
ovviamente nella direzione opposta a quella attualmente descritta, ma secondo
le stesse modalità, facendo infine pervenire tale risposta allo UA che ha avviato
l’interazione.
Tecnologie di riferimento
Riguardo alle tecnologie utilizzate per la realizzazione del task, nelle specifiche si
fa riferimento a :
•
standard SAML 2.0 per l’incapsulamento del portafoglio di asserzioni nel
messaggio SOAP
•
standard XACML per la verifica e la validazione dei requisiti di
autorizzazione rispetto alle politiche di accesso ai servizi
•
standard WS-Security per la crittografia dei dati e la firma dei messaggi
inviati
Reference Implementation
L’implementazione di riferimento del task INF-3 (di seguito RI) è stata rilasciata
dalla regione Piemonte a maggio del 2008. Essa è conforme alle specifiche SAML
2.0, pertanto prevede l’interazione con tutte le entità classiche di una
federazione basata su tale standard, che, come già detto precedentemente,
sono:
•
Profile Authority (PA)
•
Identity Provider (IdP)
•
Attribute Authority (AA)
•
Service Provider (SP)
Da notare che tale RI non fornisce queste autorità, in quanto assume che ciascun
dominio sia già in possesso delle stesse. Inoltre, coerentemente con quanto
- 47 -
definito nelle specifiche ICAR, sono state implementate due nuove entità, che
sono : il Local Proxy (LP) e l’ Authority Registry (AR).
L’unico componente visto finora, che nella terminologia di SAML assume una
denominazione differente, è l’ Identity Provider. Con tale nome, infatti, si intende
fare riferimento alla Certification Authority che rilascia le attestazioni sull’identità
degli utenti.
E’ stato ampliamente trattato e descritto in precedenza il compito svolto dal LP,
mentre risulta completamente nuovo il ruolo dell’ AR. Essa è l’entità, di cui si è
brevemente parlato prima, accessibile da tutte le federazioni, che mantiene il
registro con gli URL delle varie PA, IdP ed AA.
Grazie all’introduzione del componente LP, ed al fatto che tale implementazione
è conforme allo standard SAML 2.0, è possibile avere l’interazione tra la RI ed
altre soluzioni, siano esse open source o commerciali, che forniscono le autorità
necessarie alla realizzazione di un sistema federato. Questa è una cosa voluta, sia
per non vincolare la scelta delle autorità ad una particolare soluzione,
permettendo quindi ai singoli domini di utilizzare le authority che risultano
essere più idonee alle specifiche esigenze; sia perché, allo stato attuale, alcuni
domini possono essere già provvisti di tali elementi, il che significa quindi che è
già possibile operare in un ambiente federato, senza dover modificare o adattare
alcunché, rendendo così indolore l’adozione del sistema di autenticazione ed
autorizzazione federato per l’accesso alla cooperazione applicativa.
Purtroppo, il punto cruciale di tutta l’architettura è rappresentato proprio dalle
authority, infatti è su di esse che si basa tutto il funzionamento del task INF-3.
Come già detto, nella Reference Implementation si assume che ciascun dominio
sia già provvisto di tali entità, tuttavia, per fornire una implementazione
funzionante, sono state rilasciate anche delle authority “giocattolo”, senza alcun
- 48 -
valore legale, che simulano il funzionamento delle corrispettive reali. Sono
inoltre
stati
allestiti
degli
esempi,
che
mostrano
il
funzionamento
dell’architettura fin qui descritta. Di seguito sono riportati degli screenshot
dell’esempio predisposto nella RI :
Servizi resi dal Service Provider di esempio della Reference Implementation
- 49 -
Esempio di inserimento delle credenziali e scelta del profilo
- 50 -
La Reference Implementation è stata rilasciata sotto licenza open source. Dal
punto di vista tecnologico, è stata realizzata utilizzando la piattaforma Java JDK
1.5
ed
il
framework,
anch’esso
open
source,
OpenSAML
2.0
(http://www.opensaml.org). Come server applicativo è stato utilizzato Tomcat
5.5.20, mentre, per le interfacce di esempio, la tecnologia JSF (Java Server Faces).
Integrazione nell’architettura SPCoop
Il punto debole della Reference Implementation di INF-3 è rappresentato dal
fatto che è impossibile effettuare dei test con gli esempi forniti a corredo del
rilascio, in quanto questi sono statici, cioè, possono essere eseguiti soltanto così
come vengono forniti, non è possibile apportare nessuna modifica, se non quelle
che riguardano gli attributi degli utenti registrati sulle finte authority. Questo
pone un vincolo non banale, sia alla comprensione del funzionamento
dell’interazione tra i vari task infrastrutturali, e tra questi ed i task applicativi, sia
alla sperimentazione dell’intera infrastruttura di cooperazione applicativa, in
quanto, se non previsti, non possono essere aggiunti dinamicamente altri
componenti, come SP, IdP ecc. Ciò significa, quindi, che per avere
l’implementazione di INF-3 realmente funzionante, è necessario modificare i SIL
in modo tale che implementino la logica del SP, e siano così in grado di acquisire
il portafoglio di asserzioni, prima dell’invio di una richiesta di esecuzione di un
servizio, oppure di validarlo prima di generare la risposta relativa. Ciò significa
che una reale sperimentazione di tutta l’architettura ICAR potrà essere fatta
soltanto quando tali modifiche saranno effettuate, il che richiederà qualche
anno, in quanto i SIL in questione, soprattutto nel caso della pubblica
amministrazione, sono i sistemi informativi su cui si basano tutte le procedure
burocratiche ed amministrative che governano l’ente, il cui processo di modifica
non è una cosa banale e soprattutto rapida.
- 51 -
FreESBee-SP
Nell’ambito del progetto FreESBee, il componente che si occupa di implementare
le specifiche dettate da ICAR, per la realizzazione del sistema federato di
autenticazione, è FreESBee-SP. Come per la Reference Implementation,
ovviamente, l’utilizzo di tale modulo è subordinato alla realizzazione di
un’infrastruttura di authority, con le quali esso interagisce, per l’acquisizione
delle informazioni che permettono di descrivere l’utente. La differenza, come si
vedrà più avanti, è data dal fatto che viene fornita un’implementazione reale di
tali componenti, ovviamente senza nessun valore legale, in modo da poter
effettuare una sperimentazione “sul campo” dell’intera infrastruttura federata.
Dal punto di vista logico, tale soluzione è un wrapper, che agisce come
intermediario tra i SIL e la porta di dominio, ed è in grado di comunicare con i
primi, in maniera interattiva oppure in maniera automatica. Nel primo caso,
richiedendo esplicitamente le credenziali all’utente, mentre, nel secondo caso,
specificando opportuni parametri nella query string. Grazie a questo
meccanismo, FreESBee-SP si presta molto bene ad essere utilizzato sia nella fase
di fruizione, che in quella di erogazione di un servizio, infatti, dal lato fruitore, si
occupa della raccolta delle informazioni circa l’identità del richiedente e del
relativo portafoglio di asserzioni; dal lato erogatore, invece, si occupa della
validazione di tali informazioni, rispetto alle policy definite per l’accesso e/o
erogazione di ciascun servizio. Tali policy vengono dichiarate nella parte specifica
dell’accordo di servizio, che a sua volta risiede sul NICA. E’ perciò con tale
componente, più precisamente con il registro dei servizi, che FreESBee-SP
collabora per l’acquisizione delle policy e la validazione del portafoglio di
asserzioni.
- 52 -
Quanto appena detto è riassunto nello schema seguente :
Inte
Integrazione
di FreESBee-SP nell’architettura SPCoop
La posizione,
sizione, ricoperta da tale modulo, offre il duplice vantaggio di :
•
lasciare inalterati i sistemi informativi già abilitati all’interazione
attraverso web service, rendendo quindi immediato lo start-up
start
dell’infrastruttura federata
•
modificare i sistemi già presenti, non abilitati all’interazione attraverso
web service, prescindendo dalle problematiche proprie del componente
service provider, e quindi dalla
dalla raccolta e validazione degli attributi
In entrambi i casi il tutto si trasforma in un risparmio,
risparmio in termini
mini sia di tempo che
di costi di sviluppo / adattamento.
adattamento
- 53 -
Come
ome strumenti di supporto a FreESBee-SP, sia per il test che per la realizzazione
del sistema federato, si è ricorso ad altri due progetti open source : SIL-VIO e
Shibboleth.
Progetto SIL-VIO
SIL-VIO è l’acronimo di Sistema Informativo Locale Virtuale per l’InterOperabilità.
l’Inter
Nasce nell’ambito del progetto FreESBee come strumento di test open source
per l’architettura SPCoop, con l’obiettivo di simulare il tipico funzionamento di
un SIL. Per talee motivo, quindi, l’architettura di SIL-VIO
SIL VIO è stata sviluppata per
essere modulare, e permetterne l’utilizzo in vari scenari applicativi.
applicativi Attraverso
questo strumento è infatti possibile simulare i più disparati sistemi, da quelli
legacy, fino a quelli più avanzati. Il punto di forza su cui si basa è un articolato
motore di trasformazioni che, a partire dai dati, è in grado di generare un
messaggio SOAP di richiesta conforme alle specifiche;
specifiche e viceversa, cioè, data una
richiesta, effettuare delle operazioni (come una interrogazione o un inserimento
nel DB) e produrre la relativa risposta.
I dati per la generazione della richiesta possono essere
sere forniti in modo differente:
differente
•
prelevati automaticamente da un DB attraverso una query
•
richiesti interattivamente all’utente
all’u
•
dichiarati come costanti
Eccone uno schema :
Schema della generazione di un messaggio SOAP di richiesta
- 54 -
Schema della generazione di un messaggio SOAP di risposta
Seguendo la linea di sviluppo con cui è stato implementato il progetto FreESBee,
anche in questo caso è stato utilizzato l’approccio di EIP, per la realizzazione delle
operazioni che portano alla creazione di un messaggio di richiesta,
all’elaborazione, ed alla produzione
produz
del messaggio di risposta.
Ecco di seguito la rappresentazione dell’architettura con cui è stato concepito
SIL-VIO :
Pattern EIP nell’architettura di SIL-VIO
- 55 -
Progetto Shibboleth
Shibboleth è un progetto open source sviluppato dal consorzio Internet2
(http://shibboleth.internet2.edu/). L’obiettivo per cui è nato è quello di
permettere la condivisione e l’accesso, attraverso meccanismi di Single Sign On,
ai contenuti didattici riservati ed a pagamento, messi a disposizione dalle
università. Con il tempo si è evoluto, e grazie all’adozione di standard quali SAML
per l’identificazione e l’accesso, si è rivelato utile anche in altri contesti. Ad oggi,
infatti, risulta essere una soluzione di riferimento, una sorta di standard “de
facto”, soprattutto nel campo della pubblica amministrazione. Tale soluzione è
del tutto conforme con le specifiche di ICAR, in quanto prevede l’interazione con
vari tipi di componenti, quali : l’Identity Provider, il Service Provider e lo User
Agent. E’ inoltre previsto un altro servizio, cosiddetto, WAYF (Where Are You
From), che si occupa della ricerca degli attributi tra le varie authority, in base al
profilo che l’utente ha scelto di utilizzare. Ovviamente questi componenti sono
tutti reali ed indipendenti l’uno dall’altro; l’interazione tra essi è descritta dalla
seguente immagine :
Interazione tra i componenti di Shibboleth
- 56 -
Per ciò che riguarda l’Identity Provider, può essere configurato per accettare
modalità di autenticazione di tipo Basic; basata su database relazionali; su
directory LDAP o interfaccia web. L’Attribute Authority, invece, può essere
configurata solamente per acquisire informazioni da una directory LDAP, da cui
prelevare gli attributi definiti per l’utente.
FreESBee-SP si interfaccia con Shibboleth per gestire tutto il meccanismo di
autenticazione ed acquisizione del portafoglio di asserzioni. Per la precisione,
interagisce principalmente con il componente SP, che, in riferimento alle
specifiche ICAR, ingloba al suo interno il funzionamento sia del Local Proxy che
del Service Provider stesso. Il punto di forza di tale soluzione è che il SP è in grado
di interfacciarsi a qualsiasi Identity Provider ed Attribute Authority, purché queste
siano conformi allo standard SAML. Grazie a questo approccio, ed al fatto che le
componenti sono tutte indipendenti, è possibile supporre vari scenari :
•
usare soltanto il componente SP qualora i domini siano già in possesso di
proprie authority
•
implementare una propria authority, opportunamente certificata, basata
su IdP e AA di Shibboleth
•
adottare IdP e AA di Shibboleth per soli scopi di test
Quest’ultima ipotesi è stata utilizzata allo scopo di testare il funzionamento di
tutta l’architettura ICAR.
Scenario in cooperazione applicativa
Fino ad ora è stato solo descritto il funzionamento di FreESBee-SP, l’interazione
che ha con i moduli degli altri progetti e dove esso si posiziona all’interno
dell’architettura ICAR / SPCoop. Di seguito viene analizzato un classico scenario
- 57 -
di utilizzo in cooperazione applicativa. Per una migliore comprensione, tale
scenario, è suddiviso in due fasi :
•
la generazione
zione di una richiesta da parte del dominio fruitore
•
la verifica delle autorizzazioni e relativa erogazione del servizio nel
dominio erogatore
Prima di passare alla descrizione viene riportato di seguito lo schema di
riferimento con le relative interazioni nel dominio fruitore :
Schema delle interazioni nel dominio fruitore
Come già detto in precedenza, l’avvio del caso d’uso di richiesta di erogazione di
un servizio, può essere effettuato interattivamente, da parte di un utente che
agisce su un sistema informativo, oppure, automaticamente, da parte del
sistema informativo stesso, per
per completare una certa elaborazione. Con
FreESBee-SP
SP è possibile eseguire entrambe le modalità, tuttavia, per
- 58 -
differenziare l’una dall’altra si è scelto di utilizzare come terminologia : “utente”
quando il caso d’uso viene avviato da un utente ed eseguito interattivamente,
altrimenti, “agente”, quando il caso d’uso viene avviato da un sistema
informativo ed eseguito in modalità automatica. In entrambi i casi, il passaggio
dall’applicazione del SIL a FreESBee-SP, e viceversa, avviene attraverso il
meccanismo dei redirect. E’ ovvio che in base alla modalità scelta, è necessario
fornire a FreESBee-SP informazioni differenti, in quanto anche le operazioni che
deve eseguire sono diverse. Se si utilizza la modalità utente, per accedere
all’interfaccia per l’inserimento delle credenziali, è necessario fornire opportuni
parametri attraverso la query string, che sono :
•
Modalità di autenticazione (UTENTE / AGENTE)
•
L’URI di destinazione, cioè l’URI a cui FreESBee-SP deve redirigere l’utente
a seguito della raccolta del portafoglio di asserzioni
•
L’ID della sessione avviata sul SIL a cui riagganciarsi dopo aver raccolto il
portafoglio
•
L’URI della risorsa protetta a cui si intende accedere
Un esempio di richiesta inviata dal SIL a FreESBee-SP è il seguente :
https://hostFreesbeesp:8443/freesbeesp/schermoLogin.faces?autenticazione=U
TENTE&uriDiDestinazione=/silvio/eseguiIstanzaOperation.faces&silSessionId=05
B99142ACD21DD9CC76124DA5FB5AAE&risorsa=https://sp.example.unibas.org/
PD_PUBBLICAZIONE_VARIAZIONE_ANAGRAFICA/
A questo punto l’utente può inserire le proprie credenziali effettuando così
l’accesso al meccanismo di SSO.
- 59 -
Esempio di procedura di login per l’acquisizione del portafoglio di asserzioni
FreESBee-SP estrae dai parametri ricevuti attraverso la query string l’URI della
risorsa protetta a cui si vuole accedere, ed assieme alle credenziali, inoltra la
richiesta al componente SP di Shibboleth, come se fosse lui a richiederlo in prima
persona. Il SP di Shibboleth, attraverso il LP interno, e se configurato, con l’ausilio
del servizio WAYF, si incarica di raccogliere il portafoglio di asserzioni e farlo
validare al SP. Quest’ultimo, in base alle politiche definite per l’accesso al
servizio, può decidere se autorizzare l’erogazione o meno. La decisione presa dal
SP viene rimandata all’utente, che, in caso di mancanza di requisiti, vedrà un
messaggio che lo informa di ciò, altrimenti, sarà automaticamente rediretto sul
sistema informativo del SIL per continuare ad eseguire il caso d’uso. In caso di
esito positivo, cioè se l’utente è correttamente autenticato ed autorizzato ad
accedere ad un servizio, FreESBee-SP mantiene, per suo conto, il portafoglio di
asserzioni acquisito durante il primo accesso, in modo che, per accessi successivi
- 60 -
non sarà necessario fornire nuovamente le credenziali. Ovviamente, tali
informazioni, vengono mantenute per un periodo di tempo limitato alla durata
della sessione avviata dal SIL su FreESBee-SP.
Esempio di portafoglio di asserzioni acquisito correttamente
Nella redirezione verso l’applicazione del SIL, anche FreESBee-SP invia dei
parametri attraverso la query string, che sono : freesbeeSPSessionId e jsessionid.
Il primo verrà descritto più avanti, mentre il secondo serve all’applicazione per
recuperare la sessione precedentemente avviata con l’utente.
Un esempio di redirect da FreESBee-SP all’applicazione SIL è il seguente :
https://hostSilvio:8443/silvio/eseguiIstanzaOperation.faces;jsessionid=05B99142
ACD21DD9CC76124DA5FB5AAE?freesbeeSPSessionId=5R2821R6WGHQ76O9YC
H6JJ1FA4FB4ETI
- 61 -
Da notare che non viene inviato al SIL il portafoglio di asserzioni acquisito, ma
rimane solamente in FreESBee-SP. Nel momento in cui l’utente ha terminato le
proprie operazioni, e deve inoltrare la richiesta, per ottenere l’erogazione di un
servizio da un altro dominio, non la inoltra direttamente alla porta delegata della
propria porta di dominio, in quanto tale messaggio è sprovvisto del portafoglio,
bensì la inoltra nuovamente a FreESBee-SP, il quale si occupa di aggiungere al
messaggio SOAP il portafoglio di asserzioni precedentemente acquisito ed
inviarla, per suo conto, alla PD. Un esempio dell’URI a cui il SIL inoltra la richiesta
da inviare alla porta delegata è il seguente :
https://hostFreesbeesp:8443/freesbeesp/forwardToPD.post;jsessionid=5R2821R
6WGHQ76O9YCH6JJ1FA4FB4ETI
In tal caso, l’unico parametro è jsessionid, che serve a FreESBee-SP per risalire
alla sessione precedentemente avviata dal SIL e prelevare da essa il portafoglio
delle asserzioni.
Nella modalità agente, il comportamento è simile a quello appena descritto. Ciò
che cambia sono i parametri passati attraverso la query string e la modalità di
interazione tra SIL e FreESBee-SP, in quanto, avviene tutto in un’unica richiesta.
In questo caso, infatti, è necessario fornire :
•
Modalità di autenticazione (UTENTE / AGENTE)
•
L’URI della risorsa protetta a cui si intende accedere
•
Credenziali dell’agente che effettua la richiesta, sottoforma di username e
password
Come già detto poco fa, tutte le operazioni precedentemente descritte, vengono
svolte a seguito di un’unica richiesta, da parte dell’applicazione SIL, contenente
- 62 -
già il messaggio che la stessa deve inviare alla porta di dominio. FreESBee-SP,
FreESBee
sapendo che è un agente
gente a farla, esegue per suo conto la richiesta di
autenticazione al SP di shibboleth, che a sua volta attiva tutta la procedura per la
raccolta delle asserzioni e la validazione delle stesse. Se risultano valide, il
portafoglio viene memorizzato nella sessione,
sessione, per usi futuri, immesso nel
messaggio di richiesta ed inviato alla porta delegata; altrimenti, la richiesta viene
rigettata, ed al SIL viene inviato un messaggio di errore. L’esempio dell’URI a cui
il SIL, in modalità agente, invia la richiesta è :
https://hostFreesbeesp:8443/freesbeesp/schermoLogin.faces?autenticazione=A
https://hostFreesbeesp:8443/freesbeesp/schermoLogin.faces?autenticazione=A
GENTE&risorsa=PD_NOTIFICA
_NOTIFICA&username=agentege&password=agentege
agentege
Dal lato erogatore le cose cambiano, in quanto FreESBee-SP
FreESBee
si trova a svolgere il
compito di vero e proprio Service Provider, e decidere sull’erogazione o meno di
un servizio. Anche in questo caso, prima della descrizione, viene riportato lo
schema che descrive l’interazione all’interno del dominio erogatore :
Schema delle interazioni nel dominio erogatore
- 63 -
Ricevuto il messaggio SOAP di richiesta, come prima cosa, FreESBee-SP ne estrae
il portafoglio di asserzioni. Tale portafoglio è in formato SAML 2.0, perciò,
l’azione successiva, è quella di trasformarle in asserzioni conformi allo standard
XACML. Una volta trasformate, le sottopone al Policy Decision Point interno, che
le valida rispetto alle policy definite nell’accordo di servizio e memorizzate nel
registro dei servizi sul NICA. La decisione presa dal PDP viene poi inoltrata al
Policy Enforcement Point, anch’esso interno, che, in caso di permesso accordato,
si occupa di inoltrare la richiesta verso il SIL per l’erogazione del servizio,
altrimenti, genera un messaggio di errore, che effettua a ritroso lo stesso
percorso fatto dalla richiesta, fino ad arrivare al SIL richiedente.
Come si può notare dalla descrizione appena fatta, la validazione e la verifica
delle credenziali e degli attributi, avviene sia nel dominio fruitore, che in quello
erogatore. Questo, se da un lato aggiunge un overload all’interno
dell’architettura, soprattutto dal lato erogatore, a causa del numero di verifiche
in più che è necessario effettuare per ciascun messaggio in transito, dall’altro
fornisce una maggiore sicurezza al sistema, garantendolo anche da eventuali
errori e/o omissioni nella definizione della policy nell’uno o nell’altro dominio.
Configurazione delle istanze
I parametri passati attraverso la query string servono solo per gestire
l’interazione con le applicazioni dei SIL e l’acquisizione del portafoglio di
asserzioni.
Per
poter
funzionare,
è
necessario
che
FreESBee-SP
sia
opportunamente configurato, per esporre ai SIL i web service da contattare per
inviare richieste di cooperazione applicativa in un ambiente federato. Il processo
di configurazione è molto semplice e consiste di due operazioni :
•
Configurazione dell’URI del registro dei servizi
- 64 -
•
Configurazione di nuove istanze
La configurazione del registro dei servizi è unica per tutto il dominio d’interesse.
Consiste nella sola definizione dell’URI a cui risponde tale componente :
Esempio di configurazione dell’URI del registro dei servizi
Anche la configurazione delle istanze è altrettanto semplice, infatti consiste nella
definizione di :
•
Nome dell’accordo di servizio
•
URI della risorsa a cui accedere, generalmente la Porta Delegata
•
URI di ascolto, cioè dell’URI su cui FreESBee-SP deve avviare un nuovo
endpoint e rimanere in ascolto di richieste.
- 65 -
Esempio di configurazione di un’istanza
Dal punto di vista tecnologico, FreESBee-SP è stato realizzato utilizzando la
piattaforma JAVA, con l’ausilio dei framework open source OpenSAML 2.0 e Sun
XACML, mentre, come server applicativo, utilizza Tomcat. Per quanto riguarda
l’interfaccia, invece, è stata realizzata con la tecnologia JSF ed il framework
Richfaces.
- 66 -
Capitolo 5 : Sperimentazione dell’architettura SPCoop
La conclusione delle attività ha visto la realizzazione di una sperimentazione,
completa, dell’intera architettura SPCoop, attraverso l’uso dei componenti del
progetto FreESBee (porta di dominio, gestore eventi e sistema federato), con
l’ausilio del sistema SIL-VIO. Non è stato possibile condurre un’analoga
sperimentazione con i componenti dei rilasci ufficiali di ICAR, in quanto, al
momento, gli unici moduli in grado di interoperare sono la porta di dominio ed il
sistema di verifica dei livelli di servizio (SLA – Service Level Agreement), cioè i task
infrastrutturali INF-1 ed INF-2. La Reference Implementation di INF-3, sia per i
motivi citati nel capitolo precedente, sia perché è l’ultimo componente ad essere
stato rilasciato, risulta essere, al momento, un modulo indipendente, non
integrabile all’interno dell’architettura SPCoop, a meno che non si disponga,
all’interno del dominio, dei componenti necessari al suo funzionamento (Identity
Provider, Attribute Authority e Service Provider).
Gli scopi di questo test sono vari, primo fra tutti, quello di analizzare le
interazioni che avvengono tra i task infrastrutturali; quello di chiarire alcuni punti
critici, non completamente spiegati nelle specifiche ICAR / SPCoop; quello di
verificare il carico di lavoro gestibile dai vari componenti, al fine di ottenere
un’indicazione reale delle caratteristiche dei dispositivi hardware di cui è
necessario dotarsi.
L’architettura di test ha richiesto il dispiegamento di 11 macchine, di cui tre
server fisici ed otto virtuali, per la simulazione di due domini distinti : quello della
Regione Basilicata e quello della Regione Sicilia. Il sistema operativo utilizzato
sulle macchine fisiche è Ubuntu Desktop, mentre, su quelle virtuali, è Ubuntu
Server.
- 67 -
Di seguito lo schema rappresentativo :
Architettura di test dei componenti del progetto ICAR
Gli scenari che sono stati simulati sono una rappresentazione generale dei
possibili casi d’uso che saranno eseguiti in cooperazione applicativa. Dal
momento che la Regione Basilicata è la capofila del task applicativo AP-1,
Cooperazioni e Compensazioni Sanitarie Interregionali, è stata data maggiore
enfasi alle tematiche sulla sanità, inscenando la cooperazione tra il dominio della
regione Basilicata e quello della regione Sicilia. I casi d’uso simulati sono tre,
nello specifico :
•
Identificazione assistito
•
Segnalazione ricovero
•
Variazione anagrafica
- 68 -
Il caso d’uso “Identificazione assistito”
Lo scenario mostra un semplice esempio di richiesta ed erogazione di un servizio
in cooperazione applicativa, mostrando l’interazione tra i task infrastrutturali
INF-1 ed INF-3. Viene simulato il caso in cui un cittadino, di nome Mario Rossi, si
presenta al pronto soccorso dell’Ospedale San Carlo di Potenza per un ricovero.
Per avviare tale procedura è necessario registrare i dati di Mario nel sistema
informativo dell’ospedale. Mario è un cittadino afferente all’ASL di Catania,
pertanto l’operatore del Pronto Soccorso dell’Ospedale di Potenza, Michele
Feltri, per conoscere i dati anagrafici di Mario, effettua una richiesta alla sua ASL
di appartenenza, cioè l’Ospedale di Catania.
Lo schema che descrive questo caso d’uso è il seguente :
Schema del caso d’uso Identificazione Assistito
Le operazioni svolte sono le seguenti :
1. L’operatore Michele Feltri, del’Ospedale di Potenza, accede alla
procedura di ricovero del paziente Mario Rossi, attraverso la
funzionalità messa a disposizione dal Sistema Informativo Locale. Dal
- 69 -
momento che è un’azione che si svolge in cooperazione applicativa (a
prescindere se avviene all’interno del dominio, oppure tra domini
differenti), la prima volta che l’operatore accede, deve fornire le
proprie credenziali al modulo preposto all’autenticazione federata,
FreESBee-SP. Le operazioni di verifica dell’identità e validazione del
portafoglio di asserzioni, sono state analizzate nel dettaglio nel
capitolo precedente.
2. Se l’autenticazione va a buon fine, l’operatore può procedere al
ricovero del paziente. Nel video è possibile vedere chiaramente il
redirect che porta dall’applicazione SIL con cui l’operatore interagisce
per richiedere il ricovero, a FreESBee-SP per l’inserimento delle
credenziali, e da quest’ultimo, nuovamente al SIL. A questo punto
l’operatore può continuare con l’esecuzione del caso d’uso, inserendo
il codice fiscale del paziente per ottenere i suoi dati anagrafici.
Inizialmente la ricerca viene effettuata localmente, ma dal momento
che Mario Rossi è afferente all’ospedale di Catania, non risulta essere
presente nel database del SIL dell’ospedale di Potenza. Questo non è
un problema, in quanto è possibile comunque procedere alla
registrazione del ricovero, specificando : il codice fiscale, l’ASL di
appartenenza e i dati relativi al ricovero. Questa operazione scatena
l’invio di una richiesta in cooperazione applicativa dei dati anagrafici
di Mario Rossi. Il messaggio, contenente tale richiesta, viene inoltrato
a freESBeeSP, che lo arricchisce del portafoglio SAML dell’operatore
Michele Feltri e lo inoltra alla porta di dominio.
- 70 -
Registrazione del ricovero
3. Il messaggio, dal formato SOAP viene trasformato nel formato e-gov,
viaggia attraverso l’architettura e arriva alla porta di dominio della
Sicilia. Qui viene “sbustato”, cioè viene trasformato da busta e-gov in
messaggio SOAP ed inoltrato di nuovo al componente freesbeeSP,
questa volta del dominio della Sicilia, che lo valida rispetto alle policy
definite per l’accesso a quel servizio, e, se conforme, lo invia al SIL
dell’Ospedale di Catania.
4. Prima di procedere alla produzione della risposta, siccome tutti i
componenti, all’interno dell’architettura, sono sottoposti a verifica e
controllo del rispetto dei requisiti di qualità imposti dalle specifiche,
come prima cosa, il SIL dell’Ospedale di Catania, dopo aver ricevuto la
richiesta, si autentica presso il sistema di autenticazione federata
come “AGENTE”, ed effettua la tracciatura del servizio sul modulo
degli SLA. Successivamente, procede all’elaborazione della richiesta,
produce la relativa risposta ed invia il messaggio, con i dati anagrafici,
nuovamente alla porta di dominio. Questo riattraversa l’architettura a
ritroso fino a giungere al SIL richiedente, che registra i dati di Mario
- 71 -
Rossi nel proprio archivio. Da questo momento in poi, tali dati,
saranno presenti anche nel database dell’Ospedale di Potenza.
Dati del paziente ottenuti con una richiesta in cooperazione applicativa
- 72 -
Il caso d’uso “Segnalazione ricovero”
E’ una naturale prosecuzione di quello precedente, in cui, l’ospedale di Potenza,
segnala l’avvenuto ricovero a quello di Catania. Mostra l’interazione tra i task
infrastrutturali INF-2 ed INF-3 per la verifica degli SLA.
Tale processo è analogo al precedente, infatti, c’è l’impiegato della regione
Sicilia, il cui nome è Giulio Greco, che effettua un controllo sul soddisfacimento
dei livelli di qualità di tale servizio. Per poter accedere all’interfaccia di verifica
degli SLA, si autentica attraverso il sistema di autenticazione federata come
“UTENTE” (lo stesso vale anche per l’operatore Michele Feltri menzionato
prima). Prima dell’invio della notifica da parte dell’ospedale di Potenza, il servizio
risulta essere attivo, ma lo SLA relativo al tempo medio di risposta risulta essere
non soddisfatto.
Interfaccia di verifica degli SLA
Dopo aver registrato il ricovero, l’operatore dell’Ospedale San Carlo lo segnala a
tutti i SIL che ne hanno fatto richiesta. A questo punto, l’Ospedale di Catania,
- 73 -
riceve la segnalazione di ricovero, ed infatti nella sua base di dati locale sono
presenti tutte le informazioni relative alla degenza di Mario Rossi presso il
nosocomio potentino.
Verifica dei dati del ricovero presso l’ospedale di appartenenza
Dal momento che si tratta di una simulazione, la policy utilizzata per validare il
portafoglio di Giulio Greco è simile alla precedente, con la differenza che
cambiano i dati specificati all’interno.
- 74 -
Ill caso d’uso “Variazione anagrafica”
Lo
o scopo di questo caso d’uso è quello di mostrare il funzionamento del gestore
degli eventi e l’interazione con il modulo di autenticazione federato.
federato.
Lo schema che descrive il caso d’uso
d’u è il seguente :
Schema del caso d’uso Variazione Anagrafica
Anche questo caso d’uso si collega ai due precedenti, in quanto consiste nella
segnalazione della variazione di residenza di Mario Rossi da Catania a
Caltagirone. Nello specifico ciò che succede è questo :
1. L’operatore del Comune di Caltagirone, Antonio Furio, dopo essersi
autenticato presso il sistema
sistema di autenticazione federato, modifica il
comune di residenza di Mario Rossi da Catania a Caltagirone.
- 75 -
Modifica del comune di residenza
2. La variazione anagrafica, effettuata presso il Comune di Caltagirone
(registrato come pubblicatore), genera un messaggio e-Gov che viene
pubblicato sul GE del dominio della Sicilia .
3. Il GE Siciliano lo consegna poi ai suoi sottoscrittori : l’Ospedale di Catania
ed il GE della Basilicata.
4. Il GE della Basilicata inoltra poi il messaggio all’Ospedale di Potenza
5. Effettuando una ricerca
sul codice fiscale di Mario Rossi presso
l’Ospedale di Catania e quello di Potenza, si verifica che sono state
apportate le modifiche relative al comune di residenza.
- 76 -
Verifica della variazione sui SIL dell’Ospedale di Catania e di Potenza
- 77 -
Sia i SIL nella fase di registrazione, come pubblicatore o sottoscrittore, nei
confronti dei GE, sia i GE stessi nella fase di inoltro dei messaggi di notifica ai SIL,
o agli altri GE, effettuano accesso al dominio federato, perché gli endpoint a cui
inviano i messaggi sono tutti protetti da FreESBee-SP. Quello di interazione con i
gestori eventi è l’unico caso in cui l’autenticazione avviene soltanto nella
modalità AGENTE, in quanto non può essere interattiva.
Dal momento che la messa in piedi di tutta l’architettura, anche per semplici
esempi come questi, non è una cosa banale, durante la sperimentazione è stato
registrato un video, con relativo commento audio, che mostra praticamente
come funzionano i casi d’uso fino ad ora descritti. E’ possibile visionarlo sul sito
http://freesbee.unibas.it .
- 78 -
Capitolo 6 : Soluzioni a confronto
A seguito dei test condotti, appare più chiaro il quadro generale di tutta
l’architettura e del suo funzionamento, rimangono, tuttavia, alcuni quesiti aperti,
soprattutto per ciò che riguarda la sicurezza. E’ stato fatto, quindi, un confronto
fra le due soluzioni, con lo scopo di verificare il rispetto dei requisiti di sicurezza
definiti nelle specifiche ICAR / SPCoop.
Sicurezza in OpenSPCoop e in FreESBee
Per ciò che riguarda la sicurezza della porta di dominio, sia in OpenSPCoop che in
FreESBee, sono state rispettate tutte le specifiche definite dal CNIPA, sia in
termini di Autenticazione, Autorizzazione, Confidenzialità e Non ripudio, che in
termini di tecnologie utilizzate per la messa in sicurezza dei messaggi, attraverso
l’adozione del protocollo HTTPS per il trasporto sicuro dei dati, e dello standard
WS-Security per la firma e la crittografia della busta e-Gov, scambiata tra PdD e
NICA. In tal senso, per ciò che riguarda OpenSPCoop, non è chiaro come è
possibile specificare sia i certificati per la creazione di un canale sicuro SSL, sia
quelli utilizzati per l’operazione di firma e crittografia dei messaggi. Questo
costringe, per la modifica degli stessi, ad effettuare un intervento manuale
all’interno delle cartelle in cui viene installato il rilascio, il che, però, rappresenta
un punto di vulnerabilità dell’intero sistema (qualora ciò non venisse fatto), in
quanto, il certificato fornito con la distribuzione, è innanzitutto un certificato non
rilasciato da un ente certificatore accreditato, e pertanto non valido. La seconda
cosa, ancor più grave, è che si potrebbe verificare il caso in cui, all’interno
dell’architettura, più porte di dominio e NICA, avendo lo stesso certificato, si
scambierebbero messaggi criptati allo stesso modo, il che potrebbe permettere
facilmente la rottura, sia del canale sicuro, che della crittografia del messaggio, e
quindi l’accesso in chiaro alle informazioni scambiate. In FreESBee ciò non è
- 79 -
possibile, in quanto la definizione del certificato è un passo obbligatorio del
processo di installazione.
Un altro aspetto non chiaro è come fa la porta di dominio OpenSPCoop a
verificare l’identità e l’autorizzazione del mittente del messaggio, sia esso un
utente che inoltra la richiesta attraverso il sistema informativo con cui sta
interagendo, oppure, una richiesta formulata automaticamente da un SIL a
seguito di un’operazione. Nell’architettura FreESBee tale compito viene svolto
dal service provider, infatti all’esterno non vengono mai esposti gli URI reali delle
porte delegate ed applicative, ma sempre un URI fittizio a cui risponde il service
provider, il quale, dopo aver validato l’autenticazione ed autorizzazione del
mittente, inoltra il messaggio alla porta reale.
Ancora, in OpenSPCoop, non si capisce come avviene la protezione del registro
dei servizi presente sul NICA. Al momento, tale servizio, risulta esserne privo, il
che significa che chiunque, all’interno dell’infrastruttura, può contattarlo ed
ottenere informazioni in merito agli accordi di servizio stipulati tra le parti. Nel
caso di FreESBee, invece, anche il registro dei servizi è sotto la protezione del
service provider, che vigila sull’accesso.
Si ritiene pertanto che tali questioni saranno più chiare nel futuro, quando
emergeranno a seguito di sperimentazioni reali dell’intera architettura.
Reference Implementation vs FreESBee-SP
Anche per ciò che riguarda l’integrazione della Reference Implementation
all’interno dell’architettura ICAR ci sono un po’ di cose non molto chiare. In
questo caso, però, sono state poste esplicitamente delle domande ai responsabili
della regione Piemonte, in modo da comprendere meglio il funzionamento, ma le
risposte sono sempre state molto vaghe e poco esaurienti.
- 80 -
La prima differenza sostanziale, tra la RI e FreESBee-SP, è che nella prima, la
logica del SP dev’essere cablata all’interno del SIL, costringendo le varie
pubbliche amministrazioni, anche quelle già dotate di sistemi in grado di
scambiare messaggi SOAP, a modificare radicalmente i propri sistemi informativi,
affinché venga aggiunta anche questa funzionalità. Al contrario, invece,
FreSBee-SP non richiede alcuna modifica, soltanto quella relativa all’URI
dell’endpoint a cui inviare il messaggio SOAP con opportuni parametri, poi è
compito suo gestire tutta la logica di controllo e verifica dell’autenticazione e
dell’autorizzazione, ottenendo così un notevole risparmio, sia in termini di tempi
di realizzazione che di risorse economiche.
Sempre nelle specifiche, si parla della possibilità che ci può essere uno scambio
di messaggi tra le applicazioni dei SIL, ma per poter avvenire, comunque è
necessario che il richiedente sia autorizzato a fare la richiesta. Questo, quindi,
implica un’interazione automatica tra i SIL ed il sistema federato per
l’acquisizione del portafoglio di asserzioni, ma in riferimento al rilascio della
Reference Implementation, non è chiaro come ciò possa avvenire, in quanto le
uniche modalità previste sono quelle interattive, attraverso l’inserimento di
nome utente e password o smart card. Si è visto nel capitolo precedente come,
invece, tale possibilità è stata prevista in FreESBee-SP differenziando le modalità
di autenticazione tra UTENTE ed AGENTE, attraverso opportuni parametri di
configurazione passati nella query string.
C’è un’ambiguità tra le specifiche ICAR e la Reference Implementation, in quanto,
sembrerebbe che la validazione del portafoglio di asserzioni deve avvenire sia dal
lato fruitore che dal lato erogatore, ed una volta che il messaggio è giunto
all’erogatore, esso viene validato rispetto alle credenziali della porta di dominio
che inoltra il messaggio, perché è come se fosse lei a farne esplicita richiesta.
- 81 -
L’ambiguità nasce dal fatto che, con la Reference Implementation rilasciata, non
è proprio possibile fare ciò, ma anche se lo fosse, rimane da chiarire come viene
raccolto il portafoglio di asserzioni dalla porta di dominio ed inserito nel
messaggio, così da ottenere l’effetto che è la porta di dominio in prima persona
ad eseguire la richiesta. Un’ipotesi potrebbe essere quella di basarsi, anziché sul
portafoglio di asserzioni, solamente sulle credenziali della porta, ma anche in
questo caso, tali credenziali andrebbero specificate da qualche parte nel
messaggio, ma dove? C’è però un altro problema a riguardo, e cioè, a
prescindere dall’utilizzo del portafoglio o delle credenziali, essendo essa sempre
autorizzata ad inviare messaggi al SIL, se per qualche motivo, dal lato fruitore, si
riesce a bypassare i controlli e ad inviare la richiesta, essa non trova nessun altro
ostacolo nel suo cammino, e viene così inoltrata direttamente al SIL, il quale,
vedendosi provenire la richiesta da una porta di dominio autorizzata, effettua
l’elaborazione e produce anche la risposta, aprendo così una vulnerabilità nel
sistema. Per questo motivo, nell’architettura FreESBee, si è scelto di effettuare
un doppio controllo, sia dal lato fruitore che da quello erogatore, con la
differenza che, sull’erogatore, viene validato sempre e comunque il portafoglio di
asserzioni del fruitore. Questo costringe a definire in due punti la policy che
regola l’accesso ad una determinata risorsa, ma in cambio si ha il vantaggio di
non permettere l’erogazione di un servizio a malintenzionati in grado di
bypassare il sistema di controllo nel dominio fruitore, ad esempio contattando
direttamente l’URI reale della porta delegata.
Infine, gli esempi riportati nella Reference Implementation, fanno dedurre che è
possibile proteggere solo l’accesso alle risorse, mentre sarebbe opportuno
proteggere adeguatamente anche gli endpoint del gestore eventi, cosa che con
l’architettura FreESBee è possibile, grazie al fatto di tenere nascosti, all’esterno,
gli URI reali degli endpoint, esponendo soltanto quello protetto dal service
- 82 -
provider e quindi da FreESBee-SP, imponendo, pertanto, un accesso in modalità
AGENTE.
Schema delle differenze
Di seguito vengono riassunte in maniera compatta le differenze sopra descritte :
OpenSPCoop vs FreESBee
Autenticazione, Autorizzazione, Confidenzialità e
Non ripudio
Utilizzo del protocollo HTTPS per il trasporto sicuro
dei messaggi
Utilizzo di WS-Security per la firma e la crittografia
dei messaggi
Verificare dell’identità e dell’autorizzazione del
mittente del messaggio
Protezione del registro dei servizi del NICA
Reference
Implementation
FreESBee-SP
SI
SI
SI
SI
SI
SI
?
SI
NO
SI
Reference Implementation vs FreESBee-SP
Modifica del SIL al fine di implementare la logica del
service provider
Acquisizione del portafoglio di asserzioni in
automatico da parte delle applicazioni
Validazione del portafoglio di asserzioni sia lato
fruitore che lato erogatore
Protezione degli endpoint del gestore eventi
- 83 -
Reference
Implementation
FreESBee-SP
SI
NO
?
SI
NO
SI
NO
SI
Appendice
Di seguito è riportato un esempio di policy utilizzata per validare il portafoglio di
asserzioni sia degli operatori che degli agenti :
<Policy PolicyId="…">
<Description>…</Description>
<Target>
<Subjects>
<AnySubject/>
</Subjects>
<Resources>
<Resource>
<ResourceMatch MatchId="…">
<AttributeValue DataType="…">…</AttributeValue>
<ResourceAttributeDesignator DataType="…" AttributeId="…"/>
</ResourceMatch>
</Resource>
</Resources>
<Actions>
<AnyAction/>
</Actions>
</Target>
<Rule RuleId="… " Effect="Permit">
<Target>
<Subjects>
<AnySubject/>
</Subjects>
<Resources>
<AnyResource/>
</Resources>
<Actions>
<Action>
<ActionMatch MatchId="…">
<AttributeValue DataType="…">commit</AttributeValue>
<ActionAttributeDesignator DataType="…" AttributeId="…"/>
</ActionMatch>
</Action>
</Actions>
</Target>
<Condition FunctionId="…">
<Apply FunctionId="…">
<SubjectAttributeDesignator DataType="…"
AttributeId="idOrganizationUnit"
Issuer="http://icarlab.unibas.it"/>
</Apply>
<AttributeValue DataType="…">Basilicata</AttributeValue>
</Condition>
<Condition FunctionId="…">
<Apply FunctionId="…">
<SubjectAttributeDesignator DataType="…"
AttributeId="idTitle"
Issuer="…"/>
</Apply>
- 84 -
<AttributeValue DataType="…">Operatore</AttributeValue>
</Condition>
</Rule>
<Rule RuleId="FinalRule" Effect="Deny"/>
</Policy>
Da notare che, trattandosi di una simulazione, negli scenari trattati, le policy
sono pressoché le stesse, sia per gli UTENTI che per gli AGENTI, ovviamente ciò
che cambia sono gli attributi.
- 85 -
Bibliografia
1. D. Box, D. Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. F.
Nielsen, S. Thatte, D. Winer, “Simple Object Access Protocol (SOAP) 1.1”,
W3C, 8 Maggio 2000
2. E. Christensen, F. Curbera, G. Meredith, S. Weerawarena, “Web Services
Description Language (WSDL) 1.1”, W3C, 15 Marzo 2001
3. XML-Signature Syntax and Processing. W3C Recommendation, 12
Febbraio 2002
4. K. Lawrence, C. Kaler, D. Flinn, OASIS Web Services Security (WSS) TC,
Consorzio OASIS
5. OASIS. Web Services Security: SOAP Message Security 1.1 (WS-Security).
OASIS Standard Specification, http://docs.oasis-open.org/wss/v1.1/, 1
Febbraio 2006
6. Web Services Security UsernameToken Profile 1.1. OASIS Standard
Specification, http://docs.oasis-open.org/wss/v1.1/, 1 Febbraio 2006
7. Web Services Security X.509 Certificate Token Profile 1.1. OASIS Standard
Specification, http://docs.oasis-open.org/wss/v1.1/, 1 Febbraio 2006
8. Apache. SSL/TLS Strong Encryption: An Introduction.
http://httpd.apache.org/docs/2.0/ssl/ssl_intro.html, 2006
9. OASIS Security Services (SAML) TC, Assertions and Protocols for the OASIS
Security Assertion Markup Language (SAML) V2.0, OASIS Standard, 15
marzo 2005
10. OASIS Security Services (SAML) TC, Authentication Context for the OASIS
Security Assertion Markup Language (SAML) V2.0, OASIS Standard, 15
marzo 2005
11. OASIS Security Services (SAML) TC, Metadata for the OASIS Security
Assertion Markup Language (SAML) V2.0, OASIS Standard, 15 marzo 2005
- 86 -
12. OASIS Security Services (SAML) TC, Profiles for the OASIS Security
Assertion Markup Language (SAML) V2.0, OASIS Standard, 15 marzo 2005
13. OASIS Security Services (SAML) TC, Identity Provider Discovery Service
Protocol and Profile, OASIS Standard, 2 ottobre 2007
14. Moses, T. ed. eXtensible Access Control Markup Language (XACML)
Version 2.0. OASIS Standard, 1 Feb 2005
15. SPC, “Sistema pubblico di cooperazione: Porta di Dominio, Versione
1.0”, CNIPA, 14 Ottobre 2005
16. SPC, “Sistema pubblico di cooperazione: Busta di e-Gov, Versione
17. SPC, “Sistema pubblico di cooperazione: Accordo di Servizio,
Versione 1.0”, CNIPA, 14 Ottobre 2005
18. SPC, “Sistema pubblico di cooperazione: Servizi di Sicurezza, Versione
19. “Enterprise Integration Patterns: Designing, Building, and Deploying
Messaging Solutions" Addison-Wesley, 2004, di Gregor Hohpe, Bobby
Woolf
20. G. Mecca, A. Pappalardo, S. Raunich, Gruppo di Sviluppo FreESBee (2008).
Il Progetto freESBee: Soluzioni Infrastrutturali Open Source per il Sistema
Pubblico di Cooperazione Applicativa, SEBD
21. ICAR-INF3, Sistema Federato Interregionale di Autenticazione:
Organizzazione, versione 1.0, Ottobre 2005.
22. Progetto ICAR, Sistema Federato Interregionale di Autenticazione:
Modello Architetturale di Riferimento, 3 aprile 2007
23. Progetto ICAR, Sistema Federato Interregionale di Autenticazione:
Specifica Delle Interfacce Applicative Esterne, 3 aprile 2007
24. Shibboleth Source Access web site.
https://spaces.internet2.edu/display/SHIB/SourceAccess
- 87 -

Michele Santomauro - Progetto freESBee

Transcript

Documenti analoghi

Winsor Harmon - Cannizzo Management

Ponsacco (PI) il Oggetto: richiesta di registrazione del dominio: Il

Computing Fundamentals - Associazione Centro Studi IDI

GESTIONE DELLA SICUREZZA FUNZIONALE SECONDO IEC

DOMANDA DI REGISTRAZIONE NOME A DOMINIO

Salone Internazionale della Logistica e della Movimentazione

Trasformata di Fourier 2D (

Distributori di sapone liquido

Martin Luther King Nelson Mandela

Intervista a Emanuela Tittocchia