Autenticazione di Google Apps con un Identity Server di Ateneo utilizzando il protocollo SAML

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Autenticazione di Google Apps con un Identity Server di Ateneo utilizzando il protocollo SAML"

Transcript

1 Università degli Studi di Parma Facoltà di Scienze Matematiche Fisiche e Naturali Corso di Laurea in Informatica Tesi di Laurea in Reti di Calcolatori Autenticazione di Google Apps con un Identity Server di Ateneo utilizzando il protocollo SAML Candidato: Riccardo Amaduzzi Relatore: Chiar.mo Prof. Roberto Aleri Correlatore: Dott. Ing. Marco Panella Anno Accademico 2007/2008

2 .

3 Ai miei genitori, sempre presenti. Alla Ary, il mio Amore. Ai miei Amici..

4 Indice 1 Introduzione Problema arontato Aspetti sviluppati Strumenti utilizzati Autenticazione e autorizzazione distribuita Panoramica sui protocolli di autenticazione Autenticazione Problematiche e Tecniche risolutive Autorizzazione Autorizzazione e motore di ricerca Single Sign-On Il Progetto Liberty Alliance AAI Shibboleth Informazioni generali su Shibboleth introduzione a Shibboleth Alcuni usi di Shibboleth Shibboleth 2.0 vs Shibboleth Internet Perchè Shibboleth Shibboleth e l'università di Parma Il progetto IDEM e l'università di Parma Identity Provider

5 Indice Service Provider Procedura di login tramite Shibboleth SAML Identità Federate Chi entra nel circolo La base di SAML Introduzione a SAML Perchè SAML Vantaggi rispetto alla versione precedente Caratteristiche del protocollo Asserzioni e protocolli Bindings Proles Metadati Autenticazione Considerazioni sulla privacy e la sicurezza Il progetto Google Apps & Unipr.it Cos'è Google Apps Perchè la Federazione Realizzazione del progetto Creazione account tramite attributi e cenni a LDAP Autenticazione con il protocollo SAML 2.0 e funzionamento Realizzazione del progetto di Single Sign On con Google Apps Un pò di codice Macchina virtuale Congurazione Tomcat Filtri IdP e attributi certicato Codice per eettuare collegamento e SSO con Google 99

6 Indice 5 7 Conclusioni Risultati ottenuti Cosa manca Utilizzo futuro del nuovo servizio di posta elettronica. 102 Bibliograa 104

7 Elenco delle gure 1.1 Attacco ai dati protetti Autenticazione tramite protocollo Kerberos Schema di funzionamento autenticazione tramite Kerberos Schema di funzionamento PKI Dierenza tra autenticazione web locale e autenticazione web centralizzata Homepage CAS2 Università degli Studi di Parma Esempio di funzionamento generico del CAS Senza AAI Con AAI federata Esempio di federazione AAI Esempio di Sessione IdP Esempio di sessione SP Schema procedura di login tramite Shibboleth Protocolli SAML Scambio messaggi di protocollo Accesso a Google Apps Utilizzando SAML

8 Capitolo 1 Introduzione 1.1 Problema arontato L'obiettivo della tesi consiste nello studio delle problematiche di autenticazione e autorizzazione in una federazione di domini distribuiti in rete. Il problema arontato riguarda l'autenticazione di Google Apps con un Identity Server di Ateneo utilizzando il nuovo protocollo SAML 2.0; lo scopo è quindi permettere all'utente di autenticarsi a Google utilizzando /password di Ateneo, mediante un redirect su un Identity server locale. Ovviamente l'utente deve appartenere all'università di Parma, può essere indistintamente uno studente, un professore, un membro del Centro di Calcolo, o qualsiasi utente che sia registrato su LDAP al Centro di Calcolo. Per svolgere le prerogative è stato attivato un contratto Education Edition con Google e al termine del progetto è stata personalizzato il nuovo sistema di posta tramite le API (Application Programming Interface). La parte teorica del progetto riguarda lo studio del protocollo SAML 2.0, delle sue caratteristiche, delle migliorie rispetto alle versioni precedenti e dei possibili usi futuri per quanto riguarda le applicazioni web. Per meglio comprendere le fasi successive dell'elaborato è importante introdurre il signicato del termine Identità in Rete e della sua evoluzione. L'Identità di un soggetto costituisce la base per le transazioni che preve-

9 1.1.1 Problema arontato 8 dono lo scambio di informazioni; non solo prova che egli è chi dichiara di essere, ma indica che cosa può fare e a quale risorsa può accedere. Quando si parla di federazione delle identità ci si riferisce all'istituzione di accordi di business e di strumenti crittograci per la gestione della ducia, per la condivisione di identicativi e di attributi utente tra domini di sicurezza separati per permettere l'interazione e l'interoperabilità tra i domini stessi e nei confronti dell'utente. L'utilizzo e lo sviluppo dell'identità digitale federata si è reso necessario in quanto le persone si spostano attraverso i conni di diversi ambiti di responsabilità in modo sempre più frequente e al tempo stesso è alquanto improbabile che si possa giungere ad una identità digitale unicata, in qualunque ambito che non possa essere identicato con un solo dominio di responsabilità. Il paradigma federato costringe quindi a ripensare i ruoli delle organizzazioni nella catena di servizio in quanto se prima fornitori di servizio e di identità erano la stessa organizzazione, ora appartengono a organizzazioni diverse: I fornitori di servizio (Service Provider, SP) presidiano l'oerta di funzionalità applicative; I fornitori di identità (Identity Provider, IdP) si specializzano nella gestione delle identità digitali. Uno dei proli di cooperazione più semplici è quello in cui un SP si avvale dei servizi di Identity Management oerti da più IdP e dove la federazione è l'ambito, duciario e contrattuale, che lega l'sp al centro della stella agli IdP; un altro semplice prolo di collaborazione è quello in cui un IdP ore i propri servizi a diversi SP e dove la federazione lega l'idp a tutti i SP che desiderano trarre vantaggio dalla capacità di Identity Management dell'idp. A un livello di maturità maggiore si situa il prolo Multi-provider che vede una molteplicità tanto di IdP quanto di SP, legati in una federazione ampia, ovvero in un ambito duciario in cui ci si accorda su un insieme di regole comuni e un comune modello di trust e di responsabilità (si parlerà in seguito di circle-of-trust). Un progetto di federazione necessita di stabilire regole tecniche tra le parti: occorre innanzi tutto una sintassi comune che specichi la forma degli oggetti scambiati, una grammatica comune che indichi quale signicato attribuire

10 1.1.1 Problema arontato 9 agli oggetti ed inne una semantica comune che indichi quali proli di interazione e casi d'uso vengono previsti. Per soddisfare questi requisiti bisogna porsi alcune domande come: quali sono le relazioni di ducia tra le parti? come si garantisce la ducia end-to-end? come si garantisce la privacy dell'utente? Ancor prima di questo dobbiamo chiederci: come può l'ente erogatore del servizio accertare l'identità dell'utente? Utilizzando il metodo tradizionale, ovvero utilizzando una procedura di autenticazione che permette all'utente di dimostrare il possesso di un dato segreto noto solo all'utente stesso e all'ente (Identity Management locale); oppure utilizzando un metodo federato: l'ente ripone ducia nell'assunzione di responsabilità da parte di un Identity Provider che riconosce l'utente (Identity Management delegato). Di questo argomento si tratterà ampiamente nel capitolo secondo. Inoltre verranno analizzati i motivi per i quali l'identità federata garantisce tutti i classici requisiti di sicurezza logica quali autenticazione, autorizzazione, integrità, condenzialità e ducia tra le organizzazioni che ne fanno uso. L'identità federata permette quindi il raggiungimento dell'equilibrio tra la sicurezza delle transazioni e la semplicità di utilizzo degli strumenti online da parte degli utenti nali; è l'identità che un singolo utente può utilizzare per accedere a un determinato gruppo di siti Web collegati fra loro. Senza una identità federata, gli utenti sono costretti a gestire credenziali diverse per ogni sito che utilizzano. Con il passare del tempo questa raccolta di ID e password diventa dicile da gestire e controllare, oltre a essere più esposta a eventuali furti di identità. La gestione dell'identità federata si basa sulla relazione sicura tra l'azienda e l'individuo in quanto consente all'utente di utilizzare un'unica relazione di accesso alle informazioni con un'altra azienda collegata, senza dover denire nuove credenziali. In ultima istanza una identità federata ore ad aziende, istituzioni, dipendenti e clienti una soluzione più comoda e sicura per accedere alle risorse distribuite, senza perdere il controllo dei dati sensibili, e rappresenta una componente chiave per promuovere l'utilizzo dell'e-commerce e dei

11 1.1.1 Problema arontato 10 Figura 1.1: Attacco ai dati protetti servizi personalizzati, nonché dei servizi Web in generale. Le motivazioni più importanti che hanno portato allo sviluppo del progetto sono state: 1. riuscire ad avere una visione omogenea e coerente dell'intero sistema dal punto di vista delle relazioni tra individui e le risorse alle quali consentire l'accesso; 2. migliorare la qualità del servizio (posta elettronica universitaria), semplicandone gli accessi e la navigazione; 3. trovare una soluzione che riducesse costi, gradi di complessità e punti di intervento per l'amministrazione, evitando di dover intervenire di volta in volta sulle singole applicazioni e sui vari componenti del sistema. L'utilizzo dell'identità federata ha permesso all'utente nale di utilizzare le credenziali fornite dal proprio ente di appartenenza (Università degli studi di Parma); all'università di mantenere il controllo sul processo di autenticazione e sull'accesso ai servizi remoti da parte dei propri utenti; al fornitore di servizi (nel caso specico del progetto si tratta di Google) di evitare gli oneri di gestione delle credenziali personali e di disporre, per l'autorizzazione e la congurazione e/o personalizzazione del servizio di attributi relativi all'utente concordati con la federazione e trasmesse a cura dell'università.

12 1.1.1 Problema arontato 11 Quando si parlerà di attributi verra analizzato SAML 2.0 come protocollo standard per lo scambio delle informazioni di autorizzazione tra i domini dell'università di Parma e di Google Apps, il quale è stato scelto come caso d'uso di dominio federato con l'università, per le sue caratteristiche che ben si adattavano allo sviluppo del progetto.

13 1.1.2 Aspetti sviluppati Aspetti sviluppati Prima di entrare nel dettaglio del progetto realizzato è stato eettuato uno studio approfondito degli standard, delle applicazioni e delle tecnologie disponibili e utilizzabili per poterlo realizzare. Lo studio è stato rivolto inizialmente alle caratteristiche generali dell'autenticazione e Autorizzazione analizzandone i vantaggi e le dierenze fra l'implementazione in ambiente locale e distribuito (capitolo secondo), descrivendo i signicati di password, Kerberos, PKI, Single-Sign-On e CAS, portando come esempio locale le ACL su le e directory e come esempio distribuito la centralizzazione di ruoli e attributi su un directory server. E' stato in seguito esaminato Shibboleth 2.0 e i suoi utilizzi nell'ambito del progetto (capitolo terzo) e studiato nel dettaglio il protocollo SAML 2.0 (capitolo quarto). Dopo una breve panoramica sul progetto Google Apps - sviluppato da Google - verrà descritto nel dettaglio il progetto realizzato (capitolo quinto), ne verranno indicati gli utilizzi, le aspettative, i vantaggi, i risultati ottenuti ma anche le mancanze e i possibili miglioramenti che potrebbero essere apportati in futuro. 1.3 Strumenti utilizzati Per sviluppare il progetto sono stati scelti strumenti rigorosamente Open Source fra cui i seguenti: CentOS : Community ENTerprise Operating System, versione 5.1; IdP e SP Shibboleth2 : sviluppati da internet2; Java 6 : fornita da Sun, versione ; Apache2 : fornito da the Apache Software Foundation; Tomcat versione ; Google Apps : servizi forniti da Google gratuitamente alle organizzazioni universitarie.

14 Capitolo 2 Autenticazione e autorizzazione distribuita Autenticazione e Autorizzazione sono i concetti principali della gestione dell'accesso e dell'identità. L'autenticazione riguarda il problema di assicurare l'identità del processo con cui si sta comunicando; l'autorizzazione si occupa, invece, di stabilire che cosa può fare un processo. Solitamente la fase di autorizzazione consiste solamente in una ricerca dentro tabelle locali o in un DataBase; per questo motivo l'attenzione del progetto è stata rivolta soprattutto alla fase di autenticazione, portando ad esempio alcuni tipi di implementazioni in ambito locale e distribuito. Inoltre è stato approfondito lo studio per quanto riguarda l'approccio Single Sign-On che permette di eliminare, fra le altre cose, la necessità di eseguire l'accesso più volte quando si visualizzano dati protetti, fornendo un ambiente più sicuro per la comunità, nel nostro caso in quella universitaria Panoramica sui protocolli di autenticazione L'autenticazione è la tecnica usata dai processi per vericare che la loro controparte nella comunicazione sia veramente chi dice di essere, e non un impostore. Il modello generale utilizzato da tutti i protocolli è il seguente: l'utente A

15 Panoramica sui protocolli di autenticazione 14 inizia la comunicazione inviando un messaggio all'utente B o a una terza persona considerata data - solitamente il KDC (Key Distribuition Center) - e in seguito è previsto lo scambio di altri messaggi, in varie direzioni, che possono essere intercettati, modicati o rinviati da parte di un utente ingannevole che intende contrastare i due interlocutori. In molti protocolli gli utenti A e B stabiliscono anche una chiave segreta (chiave di sessione) da usare per continuare la loro conversazione, anche se nella realtà per motivi prestazionali tutto il traco è cifrato con la crittograa a chiave simmetrica, mentre la crittograa a chiave pubblica è largamente usata nei protocolli di autenticazione per stabilire una chiave di sessione. Le ragioni dell'utilizzo di una dierente chiave casuale per ogni nuova connessione sono molteplici: minimizzare la quantità di traco inviato usando le chiavi permanenti degli utenti (segrete o pubbliche), ridurre la quantità di testo cifrato che può cadere nelle mani di un intruso, e minimizzare i rischi connessi alla situazione in cui un processo vada in crash e il relativo core dump cada nelle mani sbagliate. Progettare un protocollo di autenticazione è molto più complicato di quanto sembri; per essere sicuri di svolgere un procedimento corretto è importnte seguire sempre quattro regole base: fare in modo che chi inizia l'autenticazione provi la sua identità prima che lo faccia chi risponde; fare si che i due soggetti, cioè chi inizia l'autenticazione e chi risponde, usino due chiavi dierenti per provare la loro identità; far si che i due soggetti utilizzino, per le richieste, numeri presi da insiemi diversi; rendere il protocollo resistente ad attacchi che coinvolgono una seconda sessione parallela, dove le informazioni ottenute da una sessione possono essere usate per l'altra. Vediamo ora alcune fra le implementazioni più utilizzate per eettuare la fase di Autenticazione. L'autenticazione tramite Password è il metodo più semplice fra quelli analizzati e consiste come è noto nell'inserimento di uno username e di una password che viene vericata quando si tenta di accedere ad un'area privata;

16 Panoramica sui protocolli di autenticazione 15 la sua semplicità comporta grossi problemi dal lato pratico in quanto viene ampiamente meno il fattore sicurezza Un protocollo di autenticazione usato in molti sistemi reali è invece Kerberos, progettato per fornire un accesso sicuro alle risorse di rete agli utenti di workstation; il protocollo è pensato per fornire sicurezza di autenticazione su reti aperte e insicure dove la comunicazione tra gli host che ne fanno parte può essere intercettata. Bisogna tuttavia essere consapevoli, che Kerberos non dà nessuna garanzia se le macchine in gioco sono vulnerabili: i server di autenticazione, i server applicativi (imap, pop, smtp, telnet, ftp, ssh) e i client devono essere mantenuti costantemente aggiornati anché si possa garantire l'autenticità dei richiedenti e dei fornitori di servizi. Figura 2.1: Autenticazione tramite protocollo Kerberos Ecco di seguito quali sono gli obiettivi che tale protocollo vuole raggiungere: 1. la password dell'utente non deve mai viaggiare sulla rete; 2. la password dell'utente non deve mai essere memorizzata in nessuna forma sulla macchina client: essa dopo essere utilizzata deve essere subito scartata;

17 Panoramica sui protocolli di autenticazione le password dell'utente non dovrebbero essere memorizzate in chiaro neanche nel database dei server di autenticazione; 4. all'utente è richiesto di inserire la password una sola volta per sessione di lavoro. Potrà pertanto accedere, durante detta sessione, a tutti i servizi per il quale è autorizzato, in modo trasparente, senza dover reinserire la password. Questa procedura è nota come Single Sign-On, e verrà descritta nel prossimo paragrafo; 5. la gestione delle informazioni di autenticazione è centralizzata e risiede sul server di autenticazione. I server applicativi non devono contenere informazioni di autenticazione dei loro utenti; 6. non solo gli utenti devono dimostrare di essere chi dicono di essere, ma, quando richiesto, anche i server applicativi devono provare la loro autenticità ai client; questa caratteristica prende il nome di Mutua autenticazione; 7. se richiesto, dopo che l'autenticazione e l'autorizzazione sono avvenute, client e server devono poter stabilire una connessione criptata. A tal scopo, Kerberos fornisce supporto alla generazione e allo scambio di una chiave crittograca da utilizzare per cifrare i dati. Kerberos suppone che tutti gli orologi siano sincronizzati e utilizza tre server in aggiunta alla workstation client: Authentication Server (AS) : verica gli utenti durante il login; Ticket Granting Server (TGS) : emette tiket che provano l'identità di chi li possiede; Server ricevente : compie il lavoro che il client ha richiesto. L'AS condivide una password segreta con ogni utente, mentre il TGS ha il compito di emettere dei tiket da usare per convincere i server veri e propri del fatto che il loro possessore è realmente chi dichiara di essere. Kerberos fa fronte al rischio intercettazioni utilizzando la cifratura simmetrica e un sistema dato di terze parti - KDC - per autenticare gli utenti di una rete e consentire loro di accedere ai servizi desiderati. Avvenuta l'autenticazione, Kerberos immagazzina un ticket specico per quella sessione

18 Panoramica sui protocolli di autenticazione 17 sul computer dell'utente e tutti i servizi kerberizzati, per eettuare l'autenticazione, invece di chiedere la password all'utente cercheranno direttamente quel ticket. Quando un utente si collega alla propria workstation connessa a una rete Kerberos, il suo principal viene inviato al KDC sotto forma di richiesta TGT. Questa richiesta può essere inviata dal programma di login (in modo trasparente) o dal programma kinit una volta che l'utente si è collegato. Il KDC controlla il principal nel suo database. Se viene trovato, crea un TGT, lo cifra usando la chiave dell'utente e lo invia come risposta all'utente. Il programma di login o kinit decifra il TGT utilizzando la chiave (che ricava dalla password dell'utente). La data di scadenza viene impostata in modo che un TGT compromesso possa essere utilizzato solo per un periodo limitato (che generalmente è di otto ore); questo è un metodo più sicuro rispetto a quello tradizionale basato sulla password, poiché una password compromessa può continuare a essere utilizzata nché non viene cambiata. In seguito, non occorre che l'utente reinserisca la password se non quando scade il TGT o quando si ricollega; quando un utente deve accedere a un servizio di rete, il client utilizza il TGT per richiedere un ticket per il servizio al Ticket Granting Service (TGS), in esecuzione sul KDC. Figura 2.2: Schema di funzionamento autenticazione tramite Kerberos

19 Panoramica sui protocolli di autenticazione 18 Lo scopo del protocollo è rendere l'utente client in grado di accedere ai server su tutta la rete in modo sicuro senza che la sua password debba mai essere trasmessa sulla rete; infatti la password rimane sulla workstation, e solo per pochi millisecondi. E' importante comunque sottolineare che ogni server si prende carico delle proprie autorizzazioni: quando il client presenta al server il suo ticket, questo serve solo a dimostrare al server l'identità del client, stabilire che cosa il client sia autorizzato a fare è compito del server. Kerberos non è comunque la soluzione ottimale in quanto è un protocollo di autenticazione per host dati su reti non di ducia: a nulla servono le strategie di Kerberos se qualcuno che ottiene accesso privilegiato ad un server, può copiarsi il le contenente la chiave segreta. L'impostore, infatti, metterà tale chiave su di un'altra macchina e gli basterà ottenere un semplice spoof di DNS o di indirizzo IP perché tale server appaia nei confronti dei client il server autentico. Tuttavia esistono metodi di gran lunga migliori, in quanto più ecienti e sicuri, quindi maggiormente utilizzati per la creazione di infrastrutture di comunicazione. Uno di questi è il PKI - Public Key Infrastructure -, ovvero una infrastruttura a chiave pubblica composta da una serie di accordi che consentono a terze parti date di vericare e/o farsi garanti dell'identità di un utente, oltre che di associare una chiave pubblica a un utente, normalmente per mezzo di software distribuito in modo coordinato su diversi sistemi. Le chiavi pubbliche tipicamente assumono la forma di certicati digitali. La struttura della PKI non solo riguarda la CA (Certication Authority), ma anche: la Registration Authority, attraverso la quale gli utenti si rivolgono per richiedere la certicazione delle chiavi, identicandosi e fornendo almeno la chiave pubblica e l'indirizzo . il Certicate Server ovvero un servizio di directory accessibile mediante un operational protocol, tipicamente LDAP (di cui si parlerà in seguito); esso è principalmente una lista di pubblicazione dei certicati e delle liste di certicati revocati e sospesi.

20 Panoramica sui protocolli di autenticazione 19 Gli accordi alla base di una PKI consentono agli utenti di essere mutualmente autenticati, e di utilizzare le informazioni contenute nei rispettivi certicati per cifrare e decifrare i messaggi in transito. In generale una PKI consiste di software client, software server (ad esempio un'autorità di certicazione), hardware e procedure operative. Un utente potrebbe rmare i propri messaggi con la sua chiave privata, e un altro utente controllare questa rma usando la chiave pubblica contenuta nel certicato del mittente, fornito dall'autorità di certicazione facente parte della PKI. Questo procedimento consente a due (o più) parti desiderose di comunicare di vericare la condenzialità, l'integrità dei messaggi e l'autenticazione degli utenti senza il bisogno di un precedente scambio di informazioni segrete. Figura 2.3: Schema di funzionamento PKI La maggior parte delle PKI al livello delle imprese fanno adamento su catene di certicati per stabilire l'identità delle parti: un certicato viene emesso da un'autorità di certicazione, a sua volta autenticata da un certi- cato emesso da un'autorità di livello più alto, e così via. In questo modo si stabilisce una gerarchia di certicati, composta da computer, organizzazioni e pacchetti software diversi. Gli standard sono fondamentali per il funzionamento di una PKI, e gli standard pubblici sono fondamentali per le PKI di uso esteso. Molti degli standard nel campo delle PKI sono opera del gruppo di lavoro PKIX della IETF. Le PKI a livello di impresa sono spesso strettamente legate ai servizi di di-

21 2.2.1 Autenticazione 20 rectory dell'azienda, in cui la chiave pubblica di ogni dipendente può essere memorizzata (incorporata in un certicato) assieme ad altri dettagli personali (numero di telefono, indirizzo , dipartimento...). Oggi la principale tecnologia per i sistemi di directory è LDAP e il formato più comune usato per i certicati è X.509, uno standard che denisce una PKI. 2.1 Autenticazione Col termine Autenticazione si denisce il processo tramite il quale un computer, un software o un utente verica la corretta identità di un utente che vuole comunicare attraverso una connessione. Nell'accesso ad alcuni servizi messi a disposizione dal Web è importante per l'utente denire in modo univoco la propria identità, essere riconosciuto e per questo ottenere l'accesso ai propri servizi; allo stesso modo è fondamentale conoscere l'identità di chi si trova dall'altra parte della linea di comunicazione ed essere certi che l'interlocutore col quale si stanno scambiando informazioni sia veramente chi dice di essere. L'autenticazione può essere eseguita in diversi modi. Lo standard più comune di autenticazione, indipendentemente dal fatto che venga eseguito in base alla directory o all'applicazione, è composto dal nome utente e dalla password. I problemi di sicurezza relativi a questo metodo potrebbero anche non essere gravi, a seconda dell'ambiente in cui ci troviamo. Tuttavia la 'sda' posta dalle ricerche in ambito aziendale (e universitario) consiste nell'associare il metodo più idoneo di autenticazione in base a ciò che si vuole ottenere. Un metodo di autenticazione più eciente può avere un ruolo di primaria importanza quando un insieme di dati riservati può essere visualizzato dagli utenti; è quindi possibile che il nome utente e la password non rappresentino più un metodo di autenticazione accettabile. Nel contempo, la valutazione degli utenti o la conoscenza eettiva degli utenti viene limitata dal costo o dal fatto di non essere un elemento della losoa aziendale, per questo sono stati sviluppati strumenti in grado di porre ne a questi problemi quali i certicati, la biometria e l'autenticazione a più fattori dell'infrastruttura a

22 2.2.1 Autenticazione 21 chiave pubblica (PKI). Le esigenze di una struttura possono essere soddisfatte grazie a tre concetti a livello di autenticazione di base. 1. Livello di autenticazione 1 - Un Utente può eseguire l'accesso alla propria stazione di lavoro con un nome utente e una password corretti. 2. Livello di autenticazione 2 - I dati di accesso sono obbligatori per eseguire l'accesso manuale o tramite Single Sign-On (SSO) a ogni link relativo a dati sensibili. 3. Livello di autenticazione 3 - Viene utilizzata l'autenticazione a due o più fattori che usa la biometria o un certicato x509 per visualizzare le informazioni sui certicati, convertire i certicati in diverse forme, rmare le richieste di certicati o modicarne le impostazioni di sicurezza. Le ACL - Access Control List - sono uno strumento utilizzato per denire dierenti livelli di sicurezza per i vari utenti all'interno di un sistema; attraverso le ACL si cerca di regolamentare l'accesso ad un certo oggetto in funzione del processo che tenta di accedere alla risorsa. Anche se si tratta di un concetto abbastanza ampio, che può essere applicato in diversi ambiti della sicurezza informatica, ci limiteremo a prendere in esame solamente la gestione dei permessi dei le. Esistono dierenti implementazioni di ACL, che rappresenta uno dei più alti livelli di astrazione nella gestione dei permessi. Tra le sue applicazioni principali, ci sono la congurazione di Firewall e dei diritti di accesso a le e directory. Una ACL è una lista ordinata di regole che viene usata per prendere una decisione, ad esempio se far transitare o meno un pacchetto lungo un canale o se permettere o meno ad un certo utente l'accesso ad un le. Ciascuna regola, detta Access Control Entry (ACE), esprime una o più proprietà dell'oggetto da valutare (ad esempio, l'indirizzo sorgente di un pacchetto IP), e se queste proprietà sono vericate indica quale decisione prendere (ad esempio, far passare il pacchetto oppure riutarlo). La valutazione inizia dalla prima regola e continua no a quando le condizioni di una regola non sono vericate. Se le condizioni sono vericate, la valutazione nisce e viene applicata la decisione presa, altrimenti, la valu-

23 Problematiche e Tecniche risolutive 22 tazione prosegue alla regola successiva. Se nessuna regola viene soddisfatta, viene applicata una decisione di default, denominata policy dell'acl Problematiche e Tecniche risolutive Il semplice uso della combinazione username/password può creare problemi ai fornitori di servizi: gli utenti tendono a dimenticare la password; un numero crescente di chiamate o di che giungono ai centri di assistenza riguarda password dimenticate. Inoltre costi dell'attivazione di nuove password stanno diventando un onere gravoso per i gestori; sempre più utenti si connettono a Internet in modi diversi, ma esigono lo stesso servizio dal fornitore. I vari tipi di accesso possono fondarsi su congurazioni tecniche diverse, dall'accesso tramite un PC al WAP, anche se la maggior parte delle volte la connessione a Internet avviene da computer diversi, in Internet caè o biblioteche pubbliche: in tal modo gli utenti sono costretti a ricordare svariate password; alcuni utenti inne non amano inserire nome utente e password in quanto lo considerano un ostacolo alla navigazione. Gli utenti tendono a minimizzare lo sforzo richiesto scegliendo password brevi che non risultano sicure e spesso sono utilizzate per accedere a diversi siti. Qualsiasi soluzione ai tre problemi citati comporta una delega parziale del processo di autenticazione da parte dell'utente. Attualmente le tecniche più utilizzate sono quattro: 1. La gestione della password è delegata al browser sul PC dell'utente, come nel caso del gestore di password Mozilla. Sebbene l'utente non deve reinserire ogni volta la password la soluzione non è ottimale in quanto non viene risolto il problema di utenti mobili che accedono ai servizi da PC diversi. Nessuna impresa esterna controlla i dati. 2. La gestione della password è delegata a un proxy server su Internet, messo eventualmente a disposizione da un fornitore di servizi Internet. In questo caso anzichè utilizzare il browser come gestore delle

24 2.2.2 Autorizzazione 23 password si ricorre alla stessa funzione integrata in un proxy server; un proxy server può servire numerosi utenti quindi è necessario registrare una password per utente e per sito visitato: Nel procedimento di autenticazione l'utente deve identicarsi sul proxy il quale dopo l'identicazione ore all'utente i servizi richiesti. Rispetto alla soluzione precedente il vantaggio del proxy consiste nella possibilità di accedervi da diversi PC e/o da altri dispositivi. 3. L'autenticazione è gestita da terzi che utilizzano un protocollo di autenticazione specico. Si tratta di protocolli con la stessa architettura basilare che consiste di tre parti: utente nale, fornitore di servizi e provider di autenticazione; prima di accedere al fornitore di servizi, l'utente nale deve far vericare l'identità al provider di autenticazione. Il fornitore di servizi ha un rapporto di ducia col provider di autenticazione e consente l'accesso all'utente. 4. L'autenticazione è eettuata da una parte contraente nell'ambito di un circuito di ducia; viene utilizzato un protocollo specico, come quello del Liberty Alliance project. Il sistema Liberty Alliance utilizza un modello federato in cui l'utente può registrarsi congiuntamente presso due fornitori di servizi. Quando l'account è stato registrato, un fornitore di servizi accetta l'integrazione con l'altro, che funge da servizio di autenticazione. 2.2 Autorizzazione L'autorizzazione fornisce una soluzione al problema di bilanciamento dei diritti degli utenti in modo che possano svolgere le proprie attività. La mappatura dei dati o dei risultati di ricerca corretti nell'ambito dei diritti dell'utente e la visualizzazione di tali dati rappresentano un problema. Le directory integrate e i certicati SSO e PKI sono esempi di servizi di autorizzazione che possono essere utilizzati per facilitare l'identicazione degli utenti e per convalidarne l'identità.

25 Autorizzazione e motore di ricerca 24 Di seguito, vengono riportati alcuni esempi di concetti a livello di autorizzazione: 1. Livello di autorizzazione 1 - Chiunque può accedere alle informazioni interne pubbliche ed è solo necessario avere l'accesso alla rete. 2. Livello di autorizzazione 2 - Le informazioni sono riservate ed è necessario disporre di dati di accesso secondari per la visualizzazione. 3. Livello di autorizzazione 3 - Applicato ai dati sensibili, a cui hanno accesso solo gruppi specici Autorizzazione e motore di ricerca Gli SPI di autorizzazione consentono ai motori di ricerca di utilizzare le credenziali degli utenti memorizzate all'esterno degli schemi di autenticazione; l'implementazione dell'spi di autorizzazione si basa sugli standard SAML 2.0 e attraverso i quali viene eseguita la codica. Quando un utente esegue una ricerca e il motore di ricerca deve determinare se i risultati possono essere visualizzati contatta l'host di destinazione, o connettore di accesso, utilizzando l'url o la destinazione in questione e l'identità dell'utente; ogni volta, l'host di destinazione, in base agli standard SAML 2.0, consentirà, negherà l'accesso o darà una risposta indeterminata. Questa funzione viene attivata dal protocollo di accesso (SOAP)tramite HTTPS. 2.3 Single Sign-On Una delle tecniche maggiormente adottate per risolvere i problemi legati all'autenticazione è il Single Sign On (SSO): un sistema specializzato che permette ad un utente di autenticarsi una sola volta e di avere accesso a tutte le risorse informatiche alle quali è abilitato. Si parla infatti di sistema basato su SSO quando le richieste di autenticazione non vengono direttamente gestite dal sistema stesso ma vengono redirette verso un altro sistema di autenticazione che ha precedentemente certicato le credenziali dell'utente connes-

26 2.2.3 Single Sign-On 25 so, senza avere quindi la necessità di richiedere nuovamente le credenziali per l'accesso. Il SSO ha fra gli obiettivi principali quelli di: semplicare la gestione delle password (riduzione numero password in uso per ogni utente); semplicare la gestione degli accessi ai vari servizi; semplicare la denizione e la gestione delle politiche di sicurezza. Si cerca quindi di rendere la sicurezza trasparente all'utente nale, in quanto questi deve rendersi conto di lavorare in un sistema sicuro, senza vivere la sicurezza come un onere aggiuntivo. Figura 2.4: Dierenza tra autenticazione web locale e autenticazione web centralizzata Altro vantaggio signicativo del SSO è la scalabilità: un soggetto che si autentica presso un certo Identity Provider può accedere a risorse protette da un Service Provider, in quale non ha bisogno di mantenere internamente

27 2.2.3 Single Sign-On 26 informazioni sul soggetto; tale fenomeno ha come conseguenza diretta un considerevole aumento dei soggetti servibili a parità di investimento. Nell'ambiente Web il SSO si applica esclusivamente all'accesso autenticato a risorse web, tipicamente eettuato tramite un browser; i soggetti che accedono ad una tale risorsa per la prima volta nell'arco di una stessa sessione, vengono rediretti presso un servizio di autenticazione Identity Provider). A seguito di un esito positivo dell'autenticazione, questi vengono rediretti nuovamente presso la risorsa inizalmente richiesta, protetta da un Service Provider, a cui verranno comunicati gli aggiornamenti sullo stato di autenticazione di tali soggetti. L'approccio al SSO è quindi di tipo federativo: non viene imposta l'adozione di un particolare IdP, ma vengono forniti gli strumenti per stringere legami di ducia con una Federazione di tali providers, senza vincoli gerarchici precostituiti. Proprio in virtù dell'esigenza di semplicare le procedure di autenticazione nasce il concetto di Federated Identity Management, e quindi di uno standard Liberty Alliance utilizzato nell'ambito di Fidelity. Infatti nel futuro gli sforzi principali delle organizzazioni si focalizzeranno per dare vita a un numero sempre maggiore di reti federate, per consentire ai Service Provider di realizzare specici accordi economici e commerciali con gli Identity Provider, i quali diventeranno non solo i gestori delle credenziali di identicazione degli utenti, ma anche i fornitori di servizi evoluti di e-business, e-government, e- health. In questo modo, grazie agli accordi preventivi stabiliti nel contesto della rete federata, è possibile realizzare un ambiente sicuro e semplicato per tutte le transazioni del navigatore in rete. L'utente internet, del tutto garantito in termini di protezione della privacy, può navigare da un sito all'altro in modalità Single Sign On, ossia con una sola e unica password di autenticazione. In altre parole se l'accesso alla rete è tanto sicuro quanto il più possibile semplicato, ne trae benecio tutto il sistema, sia in termini di adabilità dei servizi sia sotto il prolo dell'economia di gestione. Il CAS - Central Authentication Service - è un sistema di autenticazione sviluppato in origine da Yale University per fornire a una applicazione un

28 2.2.3 Single Sign-On 27 modo adabile per autenticare un utente; è un protocollo Sign-On che permette alle applicazioni web la possibilità di rinviare tutte le autenticazioni a un server centrale o a più server di ducia; il suo scopo è quello di consentire a un utente di accedere a più applicazioni in modo simultaneo ed automatico; esso consente inoltre ad applicazioni inattendibili di autenticare gli utenti senza avere accesso alle credenziali di sicurezza, come ad esempio la password. Consente quindi di concentrare in un unico punto l'autenticazione di tutte le applicazioni Web dell'organizzazione. Al momento dell'autenticazione il client viene dirottato sul server CAS con un canale cifrato HTTPS e dopo l'autenticazione con credenziali standard (password Posix e Certicati X.509) ritorna sull'applicazione avendo a disposizione un Token utilizzabile per autenticazioni successive (Single Sign On). I limiti di questo tipo di utilizzo stanno nella scalabilità limitata e nella scarsa essibilità nella denizione delle Policy di accesso (Autorizzazione). Il protocollo CAS è composto da almeno 3 parti: un client browser web, la richiesta di autenticazione di una applicazione web, e il server CAS; può anche implicare un servizio di back-end, come ad esempio un server database, che non ha una propria interfaccia HTTP, ma comunica con una applicazione web. Quando il client visita una applicazione che richiede l'autenticazione la richiesta viene reindirizzata al CAS, il quale convalida l'autenticità del cliente, di solito mediante il controllo di una username e password su una banca dati (come Kerberos o Active Directory). Se l'autenticazione ha esito positivo, CAS rimanda il client all'applicazione richiesta, accompagnandolo con un ticket di sicurezza; l'applicazione quindi valuta il ticket contattando il CAS su una connessione sicura e fornendogli il proprio servizio di identicazione e il ticket; a questo punto CAS restituisce all'applicazione informazioni circa l'avvenuta autenticazione dell'utente. CAS consente l'autenticazione multitier tramite proxy. Un database o un server di posta, può partecipare al CAS, convalidando l'autenticità degli utenti attraverso le informazioni che riceve da applicazioni web: in questo modo, un client webmail e un server webmail possono implementare il CAS.

29 2.2.3 Single Sign-On 28 Scopi principali del Central Authentication Service: facilitare il Single Sign-On su più applicazioni web; consentire l'autenticazione degli utenti senza dover accedere alle loro password; semplicare le procedure che le domande devono seguire per eseguire l'autenticazione. localizzare l'autenticazione a un unica applicazione web, che rende più facile per gli utenti salvaguardare le proprie password e che consente di modicare la sua autenticazione logica, se necessario, senza dover cambiare numerose applicazioni. Vediamo ora una panoramica architetturale del protocollo. Il server di autenticazione centrale (CAS) è concepito come una applicazione web standalone. E 'attualmente implementato come diversi servlet Java e passa attraverso il server HTTPS su secure.its.yale.edu. Si accede attraverso tre URL qui di seguito descritte: l'url di accesso, l'url di convalida, e l'url di logout che è opzionale. Per utilizzare il servizio di autenticazione centralizzato, una applicazione reindirizza i suoi utenti, o semplicemente crea un collegamento ipertestuale all'url di login. Ad esempio, l'url di login del CAS dell'università di Parma utilizzato per l'implementazione del progetto è la pagina cas2.unipr.it. Gli utenti possono inoltre accedere a questo indirizzo manualmente, se desiderano pre-autenticare le loro sessioni. Per consentire la possibilità di una ri-autenticazione successiva, il CAS permette di inviare un cookie (che scade automaticamente quando il browser viene chiuso) indietro al browser; tale cookie identica l'utente come uno che ha già eettuato l'accesso con successo. Vale la pena di notare che questo cookie è una parte opzionale del meccanismo di autenticazione del CAS; con esso, l'utente ottiene l'aspetto di single sign-on a più applicazioni web; ovvero inserisce il suo username e password solo una volta e può accedere a tutti i servizi che utilizzano il CAS. Senza il cookie, l'utente dovrebbe inserire il suo username e la password ogni volta che una applicazione lo reindirizza al

30 2.2.3 Single Sign-On 29 Figura 2.5: Homepage CAS2 Università degli Studi di Parma CAS (gli utenti possono dirigere il CAS di distruggere il cookie andando ad un logout URL). In aggiunta a trattamento primario di autenticazione, il CAS rileva inoltre il servizio da cui l'utente è stato reindirizzato (linkato); questo si può fare in quanto le applicazioni che reindirizzano a un utente l'url di accesso sono tenute a trasmettere al CAS un identicatore di servizio. Se l'autenticazione ha esito positivo, il CAS crea un lungo numero casuale, che noi chiamiamo ticket; quindi associa il ticket all'utente che ha autenticato con successo e il servizio per il quale l'utente stava cercando di autenticarsi. Ciò signica che, se l'utente è passato dal servizio S, il CAS crea il ticket T che permette di accedere a servizi di S. Questo ticket è inteso come un one-time-use-only, è utile solo per l'utente in questione, solo per il servizio S, e solo una volta; scade appena viene utilizzato. Una volta che l'autenticazione primaria è completata, il CAS reindirizza il browser dell'utente all'indietro alla applicazione dalla quale proviene. Il CAS reindirizza il browser dell'utente indietro a questo URL, aggiungendo il ticket discusso in precedenza come un parametro della richiesta.

31 Il Progetto Liberty Alliance 30 Figura 2.6: Esempio di funzionamento generico del CAS Il Progetto Liberty Alliance Costituito nel 2001, è un consorzio che comprende organismi senza scopo di lucro e svariati governi. L'obiettivo è denire standard 'aperti' per un'identità federata sulla rete attraverso speciche tecniche non proprietarie. L'autenticazione semplicata (simplied sign-on) e l'identità federata sulla rete (un sistema per collegare diversi account a un dato utente) rappresentano elementi chiave del sistema; l'autenticazione unica (single sign-on) consente al cliente di identicarsi una sola volta presso un provider di identità per navigare poi sui siti dei diversi fornitori di servizi all'interno di un dominio di ducia senza doversi identicare nuovamente. Il sistema funziona nell'ambito di domini o circuiti di ducia; si tratta di una federazione di fornitori di servizi e provider di identità le cui relazioni commerciali si basano sull'architettura di Liberty Alliance e su accordi operativi attraverso i quali i committenti possono eettuare transazioni in un ambiente sicuro e privo di ostacoli. 2.4 AAI L'obiettivo della AAI (Authentication Authorization Infrastructure) consiste, in sintesi, nella semplicazione dell'iter-organizzativo per l'accesso alle risorse web; ad esempio con un unico login uno studente può accedere a sistemi e-

32 2.2.4 AAI 31 Figura 2.7: Senza AAI Figura 2.8: Con AAI federata learning di più università. La AAI si avvale di un concetto chiamato Federated Identity Management che comprende la gestione e l'utilizzo di informazioni di identità attraverso i domini di sicurezza (security domains), come ad esempio tra le singole università. Tratta questioni quali interoperabilità, responsabilità, sicurezza, privacy e ducia. Tutte le parti coinvolte traggono vantaggio da uno standard AAI: A causa dell'id virtuale, le risorse possono risparmiare lo sforzo di registrare e gestire gli utenti sulla base di informazioni personali. Grazie a delle interfacce standardizzate, le risorse possono integrare gli utenti di altre organizzazioni senza molto sforzo.

33 2.2.4 AAI 32 Tramite un meccanismo di autenticazione standard, gli utenti sono autorizzati ad accedere a varie risorse di un certo numero di organizzazioni con una sola password, indipendentemente dalla loro ubicazione. Al giorno d'oggi gli studenti vogliono un accesso semplice e sicuro a risorse web di cui hanno bisogno per svolgere le loro mansioni, anche a quelle situate al di fuori delle università a cui sono iscritti. Al tempo stesso, gli amministratori delle risorse web desiderano fornire agli utenti un accesso sicuro e il diritto di utilizzare le loro risorse, con il più basso overhead possibile. È qui che AAI mostra i suoi punti di forza in quanto permette un accesso facile e sicuro alle applicazioni web. Senza un AAI, un utente è registrato con ogni risorsa a cui vuole l'accesso e per ognuna di queste è richiesto l'invio di una coppia di record <nome utente - password>, chiamate credenziali. I problemi di questo approccio sono evidenti in quanto gli utenti hanno a che fare con troppi nomi utente e password (solitamente è necessaria una coppia per ogni risorsa) e ogni amministratore di risorse deve registrare i propri utenti. La AAI semplica le procedure per tutte le parti coinvolte nel processo utilizzando il concetto di gestione delle identità federate: 1. Un utente si registra una sola volta con la sua organizzazione a cui è direttamente collegato (CAS Università Parma). L'organizzazione è quindi responsabile del mantenimento delle informazioni correlate all'utente e lo annuncia tramite le sue credenziali. Le organizzazioni possono essere istituzioni come università, biblioteche, università, ospedali etc. 2. L'autenticazione è sempre eettuata dall organizzazione madre dell'utente, che può anche fornire ulteriori informazioni sull'utente alla risorsa, su richieste di altre risorse e consensi personali; fatto questo, tutte le risorse AAI abilitate sono a disposizione di un utente utilizzando un unico set di credenziali. Allo stesso tempo, non vi è alcuna necessità per gli operatori della risorsa di registrare nuovi utenti, in quanto (gli operatori) sono in grado ottenere le informazioni richieste direttamente da parte degli utenti dell'organizzazione.

34 2.2.4 AAI La risorsa prende una decisione sul controllo dell'accesso basandosi sulle informazioni recuperate riguardanti l'utente. In tal modo la gestione delle identità federate si basa sul concetto che le risorse richieste a seguito di una autenticazione da parte dell'utente alla sua organizzazione ottengono da questa alcune informazioni riguardanti l'utente per le sue autorizzazioni. Una federazione è un insieme di organizzazioni che decidono di interoperare sottostando a determinate regole. Le federazioni di solito deniscono autorità e attributi, tramite la distribuzione di metadati che rappresentano tali informazioni. In generale ogni organizzazione che partecipa a una federazione gestisce un Identity Provider per i suoi utenti e uno svariato numero di Service Providers. Figura 2.9: Esempio di federazione AAI

35 Capitolo 3 Shibboleth Informazioni generali su Shibboleth introduzione a Shibboleth Shibboleth è una iniziativa inter-universitaria volta sviluppare una soluzione open source che consenta alle organizzazioni lo scambio di informazioni sui propri utenti in modo sicuro e rispettoso della privacy. E' basato su SAML (Security Assertion Markup Language) ed è stato sviluppato da Internet 2 e da un gruppo di architetti middleware (MACE) con la collaborazione di membri appartenenti alle università e alle imprese partner che hanno preso parte a questo progetto le cui nalità sono la progettazione, la specica e l'implementazione open source di sistemi per la condivisione di risorse web soggette ad autenticazione. Lo scopo del progetto consiste nel semplicare il problema dell'accesso a contenuti didattici riservati fra più campus universitari, ciascuno dei quali con una dierente infrastruttura di autenticazione, e gestire lo scambio di informazioni per determinare se una persona, utilizzando i browser web (ad esempio Mozzilla Firefox, Netscape Navigator, Internet Explorer), possieda o meno i permessi per accedere a una risorsa o a un target di risorse. Soluzione aperta signica avere contemporaneamente una architettura e un funzionamento 'aperto' e una implementazione open-source, mentre basata su standard signica che le informazioni scambiate tra organizzazioni devono

36 introduzione a Shibboleth 35 essere in grado di interoperare con informazioni provenienti da altre soluzioni software. I concetti chiave all'interno di Shibboleth includono: Amministrazioni federate di cui abbiamo parlato in precedenza; Controllo degli accessi basato su attributi: le decisioni sul controllo di accesso sono eettuate utilizzando tali asserzioni. La raccolta delle asserzioni può includere l'identità, anche se in molte situazioni questa non è richiesta (ad esempio, per l'accesso a una risorsa a disposizione degli studenti di un particolare corso, o per l'accesso a una licenza di una risorsa utilizzata da tutti i membri attivi di una determinata comunità). Active management della privacy: il sito di origine e il browser dell'utente controllano quali informazioni sono rilasciate al target; un tipico valore di default è semplicemente un membro della comunità. Le persone sono in grado di gestire individualmente i loro attributi (release) tramite una interfaccia utente basata sul web: la conseguenza fondamentale è che gli utenti non sono più in balia delle norme sulla privacy. Shibboleth è basato su standard: utilizza OpenSAML per il formato dei messaggi e delle asserzioni, e vincoli di protocollo basati su Security Assertion Markup Language (SAML) sviluppato dal Security Service OASIS (di questo protocollo si tratterà nel capitolo successivo). Un framework facilmente scalabile adatto a un insieme di utenti: Shibboleth fa uso delle politiche di insieme per specicare una serie di parti dell'insieme che hanno acconsentito all'uso di politiche comuni (un sito può comunque essere in più insiemi di politiche). Questo sposta il framework (infrastruttura) al di la di accordi bilaterali, fornendo essibilità quando situazioni dierenti richiedono insiemi dierenti di politiche. Un vocabolario attributo-valore semplice ma estendibile: Shibboleth ha denito un insieme standard di attributi; il primo insieme si

37 Alcuni usi di Shibboleth 36 basa su un oggetto di classe eduperson che include gli attributi di una persona più usati nello scambio di informazioni. Possiamo quindi aermare che Shibboleth è uno strumento middleware nato per sviluppare e implementare nuove tecnologie in grado di facilitare le collaborazioni inter-istituzionali, nonché l'accesso ai contenuti digitali. Non è prevista una gerarchia tra i providers (IdP e SP) in quanto ogni organismo è responsabile direttamente dei propri utenti e delle proprie risorse; si ha quindi una struttura orizzontale che viene denominata federazione. Il SP che decide di aderire a una federazione accetta un legame con tutti gli IdP che ne fanno parte; simmetricamente un IdP che entra in una federazione accetta di emettere asserzioni su richiesta di un qualsiasi SP della stessa Alcuni usi di Shibboleth Shibboleth fornisce 2 importanti funzionalità: 1. risolve il problema dell'uso di svariate password e modalità di signon, con il conseguente miglioramento della sicurezza; 2. garantisce la protezione contro la divulgazione inutile (e non necessaria) di informazioni(attributi) personali, con l'importantissima conseguenza di preservare la privacy degli utenti. Rimanendo in termini scolastici si consideri un tipico studente laureato e le attività che esso può svolgere: Se un utente desidera accedere alle risorse digitali di una libreria l'approccio tramite proxy servers ha lo svantaggio di essere molto impegnativo da mantenere mentre adottando il sistema di password condivise la privacy può essere compromessa se l'identità è impropriamente passata alla libreria; tramite Shibboleth si risolve il problema in quanto questo permette di accedere direttamente al contenuto del campus senza bisogno del server proxy, richiede l'autenticazione da parte del campus anche se l'identità non è passata alla libreria e può essere utilizzato dalla stessa libreria per nuovi approcci ai contenuti coperti da licenza Se invece un utente desidera avere accesso a una ricerca su un sito web o

38 Shibboleth 2.0 vs Shibboleth presso un'altra università l'approccio tradizionale propone l'utilizzo di un account di gruppo o di un nuovo account remoto individuale e quindi comporta la condivisione della password che implica problemi di sicurezza e di controllo o l'immissione di nuovi account; Shibboleth consente l'uso di account campus locali, permettendo accessi basati su un ruolo e richiedendo una gestione attiva della privacy da parte degli utenti. Come ultimo esempio riportiamo il caso in cui una classe di utenti condivisa voglia accedere a un altro sito web universitario: il metodo tradizionale consiste ancora negli account di gruppo o nuovi account individuali con gli svantaggi elencati nell'esempio precedente, mentre con l'utilizzo di Shibboleth è permesso l'uso di account del campus con la conseguenza di avere la garanzia della privacy individuale Shibboleth 2.0 vs Shibboleth 1.3 Shibboleth 2.0 è basato principalmente su SAML 2.0 e comprende un gran numero di migliorie funzionali realizzate grazie alle esperienze precedenti maturate tramite l'utilizzo e lo sviluppo di Shibboleth 1.3. La maggior parte dei dettagli dei cambiamenti realizzati sono discussi qui di seguito. Prima di tutto occorre sottolineare che Shibboleth 2.0 è pienamente compatibile con Shibboleth 1.3, sia da 2.0 a 1.3 SP IdP e viceversa. Vediamo ora come è cambiato il prolo di default di Shibboleth; Shibboleth 1.3 e le versioni precedenti erano principalmente implementazioni dell'architettura Shibboleth basata su SAML 1.1. Questo prolo includeva alcune estensioni proprietarie, come ad esempio la richiesta di un prolo per l'autenticazione; inoltre le versioni precedenti utilizzavano una query diretta a una parte separata dell'idp, chiamata Attribute Autority, per recuperare gli attributi. Il prolo di default utilizzato da Shibboleth 2.0 invece è pienamente compatibile con l'implementazione del prolo SSO Web Browser di SAML 2.0: gli attributi sono ora inclusi di default in una asserzione SAML 2.0 criptata inviata dall'idp al SP. Questo non riduce in alcun modo la privacy o le caratteristiche di sicurezza garantite da Shibboleth e dovrebbe tradursi in una più facile implementazione.

39 Shibboleth 2.0 vs Shibboleth Per quanto riguarda i metadati sia Shibboleth 1.3 sia Shibboleth 2.0 possono contare sui metadati standard di SAML 2.0; lo stesso le di metadati può essere utilizzato da providers di entrambe le versioni SAML. Tuttavia, per trarre vantaggio dalle nuove funzionalità di crittograa di Shibboleth 2.0, i providers devono avere accesso alle chiavi pubbliche dei loro partner; questo è molto più semplice da attuare se la chiave del fornitore o il certicato è posto direttamente nei metadati. Analizzando l'utilizzo degli attributi, si nota che Shibboleth 1.x ha sviluppato l'uso di un URI per identicare gli attributi SAML, e Shibboleth 2.0 continua ad adottare questo sistema come default. Tuttavia, Shibboleth 1.3 e le precedenti versioni includevano esempi fondati su eduperson che si basano su un namespace specializzato delegato dal gruppo di lavoro MACE-Dir. Nella maggior parte dei casi questo è stato superato dalla specica SAML 2.0 del prolo attributi LDAP/X.500, utilizzando il namespace URN: OID. La con- gurazione predenita dei le forniti con il software è compatibile coi nomi basati su OID per garantire la massima interoperabilità. Tutti i namespace formalmente delegati rimangono validi, ma vanno seguite buone pratiche di denominazione quando vengono deniti nuovi attributi. Inoltre, è stato adottato un insieme signicativo di norme molto semplicate per la sintassi degli attributi nelle asserzioni SAML 2.0 per aumentare l'interoperabilità con altre implementazioni di SAML. In conclusione il software Shibboleth 2.0 include una serie di miglioramenti al ne di massimizzare la sua capacità di produrre più varianti di sintassi possibili, ed inoltre è molto più estensibile. L' Identity Provider Shibboleth è stato completamente riprogettato per la versione 2.0 mentre il Service Provider è strutturalmente simile alla prima generazione di software, ma incorpora molte modiche interne atte a ridurre i conitti di software, a migliorare la portabilità e la maneggiabilità e fornire maggiori opzioni per l'integrazione di applicazioni. La maggior parte dei le di congurazione del software è stata completamente rinnovata, senza però alterare il modello di distribuzione globale. Shibboleth 2.0 è in grado di interoperare con qualsiasi implementazione di SAML (2.0, 1.1, 1.0) compatibile, entro i limiti di ogni specica dei proli supportati. Siccome SAML tralascia molti dettagli - in particolare nel settore

40 Internet 2 39 della sicurezza - per gli implementatori, i prodotti con un buon supporto per i metadati SAML 2.0 sono più semplici da integrare. Quindi possiamo aermare che la compatibilità a ritroso si estende no al software di Shibboleth 1.3, mentre non è garantita una signicativa compatibilità con la versione Internet 2 Internet2 è un consorzio no prot che sviluppa tecnologie e applicazioni avanzate per la rete, spesso per trasferimenti ad alta velocità, promuovendo la collaborazione e l'innovazione, le quali hanno un impatto fondamentale sul futuro di internet. E' gestito da diverse università Statunitensi e industrie specializzate nel settore. Oltre alle caratteristiche sopraelencate, la comunità di Internet 2 si impegna attivamente nello sviluppo della tecnologia middleware, della sicurezza e nella misura delle prestazioni che sono fondamentali per il progresso di internet Perchè Shibboleth Come già detto Shibboleth è un software open-source basato su uno standard che consente di orire in tutta sicurezza un servizio di SSO (Single-Sign-On). Scott Cantor, responsabile dello sviluppo di sistemi presso l'università statale dell'ohio ha guidato lo sviluppo tecnologico di Shibboleth, con l'obiettivo di estendere il sistema di autenticazione utilizzato dalle università e da ricercatori al di fuori da questi due ambiti. Si è lavorato non solo per rendere più uido il funzionamento del sistema, ma anche per costruire un ponte tra Shibboleth e la serie di iniziative proposte parallelamente dalle aziende. Il sistema ha enormemente semplicato la gestione delle relazioni basate su Internet, garantendo i necessari livelli di sicurezza e adabilità per ciascuna transazione; Shibboleth non funge solo da sistema di autenticazione ma anche - paradossalmente - da guardiano della privacy. Poniamo che uno studente della Università di Parma desideri accedere alle apps di Google: l'università custodisce in completa sicurezza tutti i suoi dati

41 3.3.2 Shibboleth e l'università di Parma 40 identicativi, il nome, l'età, il campus di appartenenza e così via. Quando lo studente clicca sul link con le apps di Google è Shibboleth ad assumere il controllo, inoltrando a Google solo il dato identicativo che esso è tenuta a conoscere, ossia che l'utente è registrato come studente dell'università di Parma. Se alcune università hanno cominciato a utilizzare Shibboleth n dal 2003, l'adozione del sistema si è estesa con grande rapidità solo nel Oggi serve oltre 500 siti su scala mondiale, inclusi sistemi scolastici in Australia, Belgio, Inghilterra, Finlandia, Danimarca, Germania, Svizzera e Olanda; inoltre anche le istituzioni cinesi stanno dando la loro adesione. Il dato signicativo è che il sistema si sta spostando anche verso il settore privato. In conclusione nei prossimi anni i navigatori del Web potrebbero avere la possibilità di accedere a siti diversi con una sola procedura di login man mano che le aziende implementeranno sistemi di autenticazione interoperabili. 3.2 Shibboleth e l'università di Parma Essendo Shibboleth è un framework basato su SAML, in grado di permettere di instaurare relazioni basate sulla ducia all'interno della comunità dei partecipanti, l'università di Parma lo ha adottato per sviluppare il progetto IDEM - IDEntity Management -. Questo progetto utilizzato per l'accesso federato elimina la necessità per i ricercatori, i docenti e gli studenti di dover mantenere più credenziali per poter avere accesso a diversi servizi di rete. I fornitori dei servizi (Service Providers) di rete non hanno più bisogno di gestire onerose procedure di accreditamento e di amministrazione degli utenti. Le organizzazioni di appartenenza degli utenti diventano i gestori delle identità (Identity Providers) che possono essere scambiate, fornendo le adeguate garanzie e sempre nel rispetto della privacy degli utenti. IDEM è il progetto pilota del GARR per realizzare un'infrastruttura di Autenticazione e Autorizzazione federata. Con Identity Management si intende la completa gestione delle identità digitali di una persona sica, dal processo di creazione e organizzazione, - no all'eliminazione dell'identità digitale. Ogni singola persona, dipendente di una azienda o utente esterno di un servizio, è oggetto di un processo di

42 3.3.2 Shibboleth e l'università di Parma 41 assegnazione di molte identità digitali che possono riguardare l'account di posta o l'accesso alla intranet aziendale, in maniera coerente con il suo speci- co ruolo aziendale. Nell' Identity Management ciascuna di queste identità digitali va attivata (Provisioning) e disattivata (deprovisioning) in maniera coerente alle politiche aziendali e in modo automatico per evitare errori o ritardi. Ad esempio nel caso di licenziamento di un dipendente l'intero processo di disattivazione dei suoi account deve essere eseguito nel modo più rapido ed ecace possibile. Processi ripetitivi possono essere facilmente eliminati riducendo notevolmente i costi operativi di gestione delle identità digitali grazie all'automazione di processi e servizi self service, ad esempio il processo di rigenerazione di una password smarrita. Le soluzioni di Identity Management, spesso associate ad architetture basate su Single Sign On (SSO), rendono molto più sicura ed eciente una infrastruttura di servizio eliminando le problematiche di autenticazione e autorizzazione. Inne la possibilità di eettuare auditing e monitoraggio sulle attività di ogni identità digitale, consente di mettersi al riparo da impiegati fraudolenti o furti di identità, consentendo una maggior aderenza alle politiche di sicurezza aziendale e, quando necessario, un più facile percorso di certicazione. L'azienda può infatti conoscere in ogni momento chi sta utilizzando il servizio e come. Utilità dell'identity Management Nella catena della sicurezza informatica, l'anello debole consiste nella gestione degli accessi e delle identità digitali. Teoricamente un'azienda dovrebbe fornire un processo automatizzato per garantire a ogni suo utente l'accesso alle applicazioni di sua competenza, ma anche per eliminare immediatamente questo accesso non appena diventa inutile o dannoso, come ad esempio quando un dipendente lascia la società. Le identità digitali di tutti i dipendenti dovrebbero essere sincronizzate in tutti i sistemi e un'azienda dovrebbe avere le tecnologie necessarie a garantire l'identità di fornitori, partner e altre realtà 'terze' che comunque accedono ai sistemi interni. In pratica accade spesso che ex dipendenti possano accedere ancora alla rete

43 3.3.2 Shibboleth e l'università di Parma 42 aziendale, prima che l'it manager riceva l'ordine uciale di cancellarli dalla rete; inoltre gli impiegati devono ricordare talmente tante password che alla ne si sentono autorizzati a sceglierne di troppo vulnerabili. Molti sono i benefici che un sistema di ID Management può apportare a una azienda o a una istituzione; in primo luogo riduce i costi di gestione IT e dell'help desk, aumenta la sicurezza di tutta l'infrastruttura e anche la produttività degli utenti, che non perdono tempo a loggarsi in sistemi diversi con procedure dierenti; un altro vantaggio non meno importante è che un sistema di ID Management aiuta a soddisfare le normative legate alla sicurezza aziendale. Occorre comunque prestare attenzione e stabilire secondo criteri logici chi può creare, modicare e visualizzare i dati degli utenti; quale particolare evento dà il via libera alla creazione di un nuovo prolo di privilegi per un nuovo utente o per un utente che cambia ruolo all'interno dell'impresa; quale, all'opposto, richiede una cancellazione immediata dei privilegi. Per realizzare l'idem bisogna assicurarsi che l'infrastruttura che regge il sistema informatico e aziendale sia solida e adabile; per questo motivo è necessario un maggiore dialogo tra infrastrutture già alla fonte, ovvero tra sistemi operativi, che sono la base su cui poggia ogni applicazione informatica aziendale. L'IDEM può essere distinta in due stili implementativi del tutto dierenti: L'IDEM ISOLATO è il modello più diuso in cui ogni servizio ha un proprio bacino di utenza indipendente e ad ogni utente viene assegnata una credenziale distinta per ogni servizio a cui faccia accesso; è un approccio molto semplice in quanto semplica la gestione delle identita da parte dei SP, ma presenta molti problemi di usabilità per gli utenti all'aumentare dei servizi utilizzati. L'IDEM FEDERATO - si parla anche di identity federation - può essere denito invece come l'insieme di regole, tecnologie, standards e accordi che permettono a un insieme di SP di accettare come validi gli identicatori utente gestiti da un altro insieme di providers, chiamati Identity Providers (IdP). L'insieme di SP e IdP prende il nome di federazione. Come vedremo in seguito questo approccio implementa implicitamente il

44 3.3.3 Il progetto IDEM e l'università di Parma 43 SSO, ovvero la possibilità di un utente di autenticarsi presso uno qualsiasi dei provider della federazione e, successivamente, di accedere ai servizi di tutti gli altri. Punti cardine di questo approccio sono: all'origine di una richiesta ci deve essere sempre una richiesta esplicità da parte dell'utente; la corrispondenza tra gli identicatori collegati in una federazione deve essere corretta: infatti devono tutti far riferimento a una stessa identità digitale; la circolarità tra i providers delle informazioni sull'utente deve essere regolata da opportune policies accettate da tutte le parti in gioco al momento della federazione dell'identità. 3.3 Il progetto IDEM e l'università di Parma Come già detto in precedenza gli ultimi anni hanno visto il proliferare di numerosi servizi web ognuno con un dierente sistema di autenticazione. Partendo dalla tradizionale autenticazione con username/password no ad arrivare ai più recenti sistemi basati su smartcard e certicati personali, l'accesso alle informazioni è generalmente regolato da una serie di iscrizioni che richiedono ad ogni singolo utente di fornire di volta in volta dierenti credenziali. Considerando inoltre che tali identità digitali implicano spesso il passaggio nella rete di dati personali soggetti a regole di sicurezza e riservatezza diverse, si capisce n da subito come questa modalità renda dicile e insicuro l'accesso a servizi online forniti da soggetti diversi dalla propria organizzazione di appartenenza. In tale ambito il Consortium GARR, come già hanno fatto enti omologhi - come Switch in Svizzera - intende favorire e supportare l'attivazione di una Federazione dei sistemi di autenticazione degli Atenei e Enti di Ricerca (chiamata Federazione GARR-AAI) basata su rapporti di reciproca ducia, all'interno della quale sia accettata l'identità digitale dell'utente riconosciuta dall'organizzazione di appartenenza. Un processo analogo, dal punto di vista logico, a quanto accade per i cittadini dei paesi membri della comunità europea the accettano la carta di identità del paese di riferimento.

45 3.3.4 Identity Provider 44 La prima tappa della Federazione GARR-AAI è stata quella di far partire il progetto pilota denominato IDEM, basato su tecnologia Shibboleth, all'interno del quale vericare l'eettiva realizzabilità di una infrastruttura di tale tipo in Italia. Per fare ciò il GARR promuove e supporta il progetto fornendo l'infrastruttura centrale e i servizi mettendo a disposizione: supporto tecnico per l'implementazione di un IDentity Provider (IDP) e Service Provider (SP); realizzazioni di riferimento opensource; il servizio WAYF (Where Are You From); gestione della mappa della federazione. Il CILEA è stato uno tra i primi enti ad aver attivato un Identity Provider Shibboleth conforme alle direttive della GARR-AAI e sta lavorando al ne di rendere Shibboleth compatibili alcuni dei propri servizi per gli utenti come quello sviluppato dall'università di Parma che è stata in grado di implementare l'autenticazione via Shibboleth. 3.4 Identity Provider Un IdP (Identity Provider) è un sistema informatico che tratta individualmente le credenziali degli utenti nali e verica che queste risultino valide. Un IdP potrebbe essere un ente nanziario, una impresa commerciale, un organismo governativo, o, come nel caso di questo progetto, una istituzione scolastica. Ogni IdP è in grado di autenticare l'utente e fornire informazioni aggiuntive o attributi sul suo conto; può operare uno o più servizi di credenziali, ciascuno dei quali tratta le credenziali dell'utente basandosi su degli standard per la verica dell'identità. Un utente può possedere credenziali da più Identity Provider, alcuni dei quali possono essere gestiti dalla stessa organizzazione o dalla stessa società. E-Authentication ha stabilito una Federazione di IdP che comprende istituti nanziari, imprese commerciali e agenzie governative.

46 3.3.5 Service Provider 45 Figura 3.1: Esempio di Sessione IdP L'Identity Provider esegue i seguenti controlli: 1. Se esiste già una sessione per l'utente ; 2. Se il timeout della sessione (inattività) non è superato (default: 30 min); 3. Se il timeout del metodo di autenticazione (ad esempio, PKI, UsernamePassword) non è superato (UsernamePassword default: 30 min); 4. Se l'attributo ForceAuthn non è settato; Se uno di questi punti non è vericato, l'idp applica una autenticazione per l'utente. Entrambi i timeout (sessione e metodo di autenticazione) sono basati su inattività; essi vengono aggiornati nel corso di ogni richiesta di autenticazione. Se la sessione scade, tutti i timeout del metodo di autenticazione sono cancellati. In conclusione si può aermare che un Identity Provider che entra in una federazione garantisce ai propri soggetti una migliore oerta di servizi in termini di quantità, qualità e diversicazione.

47 3.3.5 Service Provider 46 Figura 3.2: Esempio di sessione SP 3.5 Service Provider Il Service Provider è l'ente presso il quale è gestita la risorsa web a cui l'utente fa richiesta e che ha il compito di proteggerla attraverso qualche forma di policy di acceso; il Service Provider controlla: Se esiste già una sessione per l'utente ; Se il timeout della sessione (inattività) non è superato (default: 1 ora); Se il tempo di vita della sessione (manutenzione nella cache) non è superato (default: 8 ore); Se il tempo massimo dopo l'ultima autenticazione non è superato (di default non è impostato). Se uno di questi punti non corrisponde, è avviata la procedura di autenticazione. I dati associati a una sessione SP sono gli attributi, le informazioni di autenticazione (tempo, metodo, classe,...); in altre parole, tutte le informazioni che sono state fornite dall' IdP entro l'asserzione(i). Ciò signica che tutte le

48 3.3.6 Procedura di login tramite Shibboleth 47 autorizzazioni di accesso e i controlli vengono eettuati dalla sessione delimitata dai dati. Nota: Se il Discovery Service imposta un cookie contenente l'identità della selezione dell'idp dell'utente, alcuni passi vengono omessi e l'utente del browser viene reindirizzato direttamente all'identity Provider dell'utente. In conclusione possiamo aermare che un Service Provider è motivato ad aderire a una federazione in quanto può accedere ad un bacino di utenza più ampio costituito da tutti gli IdP della federazione. 3.6 Procedura di login tramite Shibboleth La procedura di login tramite Shibboleth è all'incirca come qualsiasi altro processo di login. Per accedere a una risorsa protetta, l'utente deve autenticarsi; tuttavia, nel caso di Shibboleth l'utente non autentica se stesso a una risorsa, ma autentica se stesso alla sua Organizzazione. L'utente non ha bisogno di fornire il suo nome utente e la password a terzi, ma solo alla sua Organizzazione. Una volta che l'utente è autenticato a Shibboleth, può accedere a qualsiasi altra risorsa abilitata senza fornire login e password; si noti che il procedimento è reso però necessario se l'utente chiude il proprio browser web o se non si è acceduto alla risorsa Shibboleth per un determinato periodo di tempo. Primo passo - Accesso al Service Provider (Utente browser <> Service Provider): L'utente apre un browser Web e accede al Service Provider; il suo browser invia una richiesta (GET). Poiché la pagina è protetta dal Service Provider Shibboleth viene controllato se l'utente ha già una sessione Shibboleth aperta e quindi se è già stato autenticato. Se l'utente non è autenticato, il server web risponde con un reindirizzamento HTTP all'organizzazione dell'utente. Secondo passo - Inizio sessione per la richiesta di autenticazione A seguito della risposta, l'inizializzatore della sessione crea una richiesta di

49 3.3.6 Procedura di login tramite Shibboleth 48 Figura 3.3: Schema procedura di login tramite Shibboleth autenticazione e la restituisce all'interno di un auto-submit-post-form. A questo punto l'identity Provider controlla la richiesta di autenticazione, e poiché l'utente non è autenticato, invia un reindirizzamento all'appropriato gestore di login (nome utente/password). Il browser viene reindirizzato al gestore e l'identity Provider reindirizza quindi a una specica pagina web il nome utente/password; in seguito il browser invia una richiesta GET per la pagina web e il server web risponde con la pagina richiesta. Terzo passo - Autenticazione, controllo attributi e accesso A questo punto l'utente può digitare il suo nome utente e password e presentarli all'idp; l'autenticatore dell'idp verica le credenziali. Dopo che l'utente è stato autenticato con successo, vengono eguiti l'attribute resolving e l'attribute ltering. Viene quindi generata una pagina HTML che include una asserzione SAML; siccome questa asserzione contiene non solo una dichiarazione di autenticazione, ma anche una dichiarazione-attributo con gli attributi dell'utente, questo modo di inviare gli attributi viene chiamato Attribute Push. L'asserzione viene trasmessa utilizzando una auto-submitpost-form. Il browser POSTA immediatamente la richiesta e inne invia un

Elementi di Sicurezza e Privatezza Lezione 18 Autenticazione: Single Sign On

Elementi di Sicurezza e Privatezza Lezione 18 Autenticazione: Single Sign On Elementi di Sicurezza e Privatezza Lezione 18 Autenticazione: Single Sign On Chiara Braghin chiara.braghin@unimi.it Lab 8 Visti i problemi con la macchina virtuale e la rete, l assignment è sospeso 1 Autenticazione

Dettagli

Elementi di Sicurezza e Privatezza Lezione 18 Autenticazione: Single Sign On

Elementi di Sicurezza e Privatezza Lezione 18 Autenticazione: Single Sign On Elementi di Sicurezza e Privatezza Lezione 18 Autenticazione: Single Sign On Chiara Braghin chiara.braghin@unimi.it! Autenticazione cont d (1) Dalle lezioni precedenti: w L autenticazione è un prerequisito

Dettagli

Accesso alle applicazioni protetto. Ovunque.

Accesso alle applicazioni protetto. Ovunque. Scheda tecnica Accesso alle applicazioni protetto. Ovunque. Utenti mobili protetti Nelle organizzazioni odierne, ai responsabili IT viene spesso richiesto di fornire a diversi tipi di utente l'accesso

Dettagli

Manuale di Integrazione IdM-RAS

Manuale di Integrazione IdM-RAS IdM-RAS Data: 30/11/09 File: Manuale di integrazione IdM-RAS.doc Versione: Redazione: Sardegna IT IdM-RAS Sommario 1 Introduzione... 3 2 Architettura del sistema... 4 2.1 Service Provider... 4 2.2 Local

Dettagli

Identity Access Management nel web 2.0

Identity Access Management nel web 2.0 Identity Access Management nel web 2.0 Single Sign On in applicazioni eterogenee Carlo Bonamico, NIS s.r.l. carlo.bonamico@nispro.it 1 Sommario Problematiche di autenticazione in infrastrutture IT complesse

Dettagli

Integrazione di CampusNet nell infrastruttura di autenticazione ed autorizzazione della rete GARR (IDEM) basata su Shibboleth

Integrazione di CampusNet nell infrastruttura di autenticazione ed autorizzazione della rete GARR (IDEM) basata su Shibboleth Facoltà di Scienze Matematiche Fisiche e Naturali Corso di Laurea in Informatica Tesi di Laurea in Reti di Calcolatori Integrazione di CampusNet nell infrastruttura di autenticazione ed autorizzazione

Dettagli

Single Sign On sul web

Single Sign On sul web Single Sign On sul web Abstract Un Sigle Sign On (SSO) è un sistema di autenticazione centralizzata che consente a un utente di fornire le proprie credenziali una sola volta e di accedere a molteplici

Dettagli

Metodi di verifica degli utenti in ELMS 1.1

Metodi di verifica degli utenti in ELMS 1.1 Metodi di verifica degli utenti in ELMS 1.1 2012-12-21 Kivuto Solutions Inc. [RISERVATO] SOMMARIO PANORAMICA...1 METODI DI VERIFICA...2 Verifica utente integrata (IUV, Integrated User Verification)...2

Dettagli

Elementi di Sicurezza informatica

Elementi di Sicurezza informatica Elementi di Sicurezza informatica Secure Socket Layer Università degli Studi di Perugia Indice 1 1.Introduzione 2 3 Perché SSL Funzionalità Storia di SSL Introduzione Introduzione Perché SSL; Funzionalità;

Dettagli

Novell ZENworks Configuration Management in ambiente Microsoft * Windows *

Novell ZENworks Configuration Management in ambiente Microsoft * Windows * Guida GESTIONE SISTEMI www.novell.com Novell ZENworks Configuration Management in ambiente Microsoft * Windows * Novell ZENworks Configuration Management in ambiente Microsoft Windows Indice: 2..... Benvenuti

Dettagli

Applicazioni per l autenticazione Sicurezza nelle reti di TLC - Prof. Marco Listanti - A.A. 2008/2009

Applicazioni per l autenticazione Sicurezza nelle reti di TLC - Prof. Marco Listanti - A.A. 2008/2009 Applicazioni per l autenticazione Kerberos Kerberos Servizio di autenticazione sviluppato dal MIT Fornisce un server di autenticazione centralizzato Basato su crittografia simmetrica (chiave privata) Permette

Dettagli

Sicurezza e virtualizzazione per il cloud

Sicurezza e virtualizzazione per il cloud Sicurezza e virtualizzazione per il cloud Con il cloud gli utenti arrivano ovunque, ma la protezione dei dati no. GARL sviluppa prodotti di sicurezza informatica e servizi di virtualizzazione focalizzati

Dettagli

identità digitale federata nella P.A. italiana Francesco Meschia CSI-Piemonte

identità digitale federata nella P.A. italiana Francesco Meschia CSI-Piemonte identità digitale federata nella P.A. italiana Francesco Meschia CSI-Piemonte Definire l Identità Digitale Il primo tentativo di fornire una definizione completa del concetto di identità digitale è stato

Dettagli

Glossario servizi di Sicurezza Informatica offerti

Glossario servizi di Sicurezza Informatica offerti Glossario servizi di Sicurezza Informatica offerti Copyright LaPSIX 2007 Glossario servizi offerti di sicurezza Informatica SINGLE SIGN-ON Il Single Sign-On prevede che la parte client di un sistema venga

Dettagli

Shibboleth e Google Apps

Shibboleth e Google Apps Università di Modena e Reggio nell Emilia 17 giugno 2009 Panoramica funzionamento di default di Shibboleth; autenticazione SAML con Google Apps; indicazioni su come integrare Google Apps con Shibboleth

Dettagli

Messa in esercizio, assistenza e aggiornamento di una Piattaform Open Source Liferay plug-in per ARPA

Messa in esercizio, assistenza e aggiornamento di una Piattaform Open Source Liferay plug-in per ARPA Messa in esercizio, assistenza e aggiornamento di una Piattaform Open Source Liferay plug-in per ARPA Pag. 1 di 16 Redatto da F. Fornasari, C. Simonelli, E. Croci (TAI) Rivisto da E.Mattei (TAI) Approvato

Dettagli

Rilevazione automatizzata delle timbrature di presenza

Rilevazione automatizzata delle timbrature di presenza Direzione Servizi Interni Rilevazione automatizzata delle timbrature di presenza MANUALE DI UTILIZZO DELLA PROCEDURA TIMBR@WEB Versione 2.0 del 09 Gennaio 2012 A cura di Luigi D Elia SOMMARIO ACCESSO ALL

Dettagli

Appl. di emissione PKCS#11. API (Metacomandi) Resource Manager Windows. Drivers PC/SC dei lettori

Appl. di emissione PKCS#11. API (Metacomandi) Resource Manager Windows. Drivers PC/SC dei lettori Roma, 30 gennaio 2003 La realtà della carta di identità elettronica (nel seguito CIE) e della carta nazionale dei servizi (nel seguito CNS) rende ineluttabile l individuazione di servizi da erogare in

Dettagli

Antonio Mattioli Seminario G@SL 5/12/2006. Windows Single Sign-on

Antonio Mattioli Seminario G@SL 5/12/2006. Windows Single Sign-on Antonio Mattioli Seminario G@SL 5/12/2006 Windows Single Sign-on Cos è il Single Sing-on? Il Single sign-on è una speciale forma di autenticazione che permette ad un utente di autenticarsi una volta sola

Dettagli

Elementi di Sicurezza e Privatezza Lezione 19 SAML e sicurezza della posta elettronica

Elementi di Sicurezza e Privatezza Lezione 19 SAML e sicurezza della posta elettronica Elementi di Sicurezza e Privatezza Lezione 19 SAML e sicurezza della posta elettronica Chiara Braghin chiara.braghin@unimi.it SAML Security Assertion Markup Language Dalla lezione precedente (1) Single

Dettagli

VERISIGN SERVER ONSITE.

VERISIGN SERVER ONSITE. VERISIGN SERVER ONSITE. Scheda Tecnica. Ultima revisione del presente documento 05/12/2001 Versione 2.2 Trust Italia S.p.A. 1 di 8 INDICE Introduzione: i certificati digitali e il protocollo SSL.... 3

Dettagli

La Sicurezza delle Reti. La Sicurezza delle Reti. Il software delle reti. Sistemi e tecnologie per la multimedialità e telematica.

La Sicurezza delle Reti. La Sicurezza delle Reti. Il software delle reti. Sistemi e tecnologie per la multimedialità e telematica. Sistemi e tecnologie per la multimedialità e telematica Fabio Burroni Dipartimento di Ingegneria dell Informazione Università degli Studi di Siena burronif@unisi unisi.itit La Sicurezza delle Reti La presentazione

Dettagli

Sicurezza nelle Grid. Sommario. Page 1. Il Problema della Sicurezza nelle Grid. Grid Security Infrastructure Autorizzazione

Sicurezza nelle Grid. Sommario. Page 1. Il Problema della Sicurezza nelle Grid. Grid Security Infrastructure Autorizzazione Sommario Il Problema della Sicurezza nelle Grid Sicurezza nelle Grid Grid Security Infrastructure Autorizzazione 2 Page 1 Il Problema della Sicurezza nelle Grid (1) Le risorse sono presenti domini amministrativi

Dettagli

l identità digitale federata nel progetto ICAR

l identità digitale federata nel progetto ICAR l identità digitale federata nel progetto ICAR Francesco Meschia Roma, 16 febbraio 2006 agenda generalità sul progetto ICAR e sul task INF-3 situazione e problemi dell identità digitale in Italia l approccio

Dettagli

Il Sito utilizza cookies tecnici e non di profilazione

Il Sito utilizza cookies tecnici e non di profilazione PRIVACY POLICY Informativa Privacy 1. INTRODUZIONE La presente Privacy Policy è relativa al sito www.aslnapoli2-formazione.eu. Le informazioni che l utente deciderà di condividere attraverso il Sito saranno

Dettagli

Articolo di spiegazione FileMaker Replica di un ambiente di autenticazione esterna per lo sviluppo

Articolo di spiegazione FileMaker Replica di un ambiente di autenticazione esterna per lo sviluppo Articolo di spiegazione FileMaker Replica di un ambiente di autenticazione esterna per lo sviluppo Pagina 1 Replica di un ambiente di autenticazione esterna per lo sviluppo La sfida Replicare un ambiente

Dettagli

Reti di calcolatori. Lezione del 25 giugno 2004

Reti di calcolatori. Lezione del 25 giugno 2004 Reti di calcolatori Lezione del 25 giugno 2004 Tecniche di attacco Denial of Service : impedisce ad una organizzazione di usare i servizi della propria rete; sabotaggio elettronico Gli attacchi DoS possono

Dettagli

CONCETTI DI NAVIGAZIONE IN RETE

CONCETTI DI NAVIGAZIONE IN RETE CONCETTI DI NAVIGAZIONE IN RETE Internet (La rete delle reti) è l insieme dei canali (linee in rame, fibre ottiche, canali radio, reti satellitari, ecc.) attraverso cui passano le informazioni quando vengono

Dettagli

Le Reti Informatiche

Le Reti Informatiche Le Reti Informatiche modulo 10 Prof. Salvatore Rosta www.byteman.it s.rosta@byteman.it 1 Nomenclatura: 1 La rappresentazione di uno schema richiede una serie di abbreviazioni per i vari componenti. Seguiremo

Dettagli

AREA SERVIZI ICT. Servizi di hosting offerti dall'area Servizi ICT. Integrazione con l'anagrafica Unica di Ateneo. hosting.polimi.

AREA SERVIZI ICT. Servizi di hosting offerti dall'area Servizi ICT. Integrazione con l'anagrafica Unica di Ateneo. hosting.polimi. AREA SERVIZI ICT Servizi di hosting offerti dall'area Servizi ICT Integrazione con l'anagrafica Unica di Ateneo hosting.polimi.it Indice 1. Anagrafica unica di Ateneo... 4 1.1. Introduzione all anagrafica

Dettagli

Certificati Digitali e sicurezza di SSL/TLS

Certificati Digitali e sicurezza di SSL/TLS ICT Security n. 35, Giugno 2005 p. 1 di 5 Certificati Digitali e sicurezza di SSL/TLS Nei precedenti articoli abbiamo descritto il protocollo SSL/TLS, in particolare la versione TLSv1.0, ed accennato ad

Dettagli

PSNET UC RUPAR PIEMONTE MANUALE OPERATIVO

PSNET UC RUPAR PIEMONTE MANUALE OPERATIVO Pag. 1 di 17 VERIFICHE E APPROVAZIONI VERSIONE V01 REDAZIONE CONTROLLO APPROVAZIONE AUTORIZZAZIONE EMISSIONE NOME DATA NOME DATA NOME DATA PRATESI STATO DELLE VARIAZIONI VERSIONE PARAGRAFO O DESCRIZIONE

Dettagli

Verifica utente integrata Guida all'implementazione per il cliente 2015-05-04 Riservato Versione 2.9

Verifica utente integrata Guida all'implementazione per il cliente 2015-05-04 Riservato Versione 2.9 Verifica utente integrata Guida all'implementazione per il cliente 2015-05-04 Riservato Versione 2.9 INDICE Introduzione... 2 Scopo e destinatari... 2 Informazioni sul documento... 2 Termini comunemente

Dettagli

Certificati digitali con CAcert Un'autorità di certificazione no-profit

Certificati digitali con CAcert Un'autorità di certificazione no-profit Certificati digitali con CAcert Un'autorità di certificazione no-profit Davide Cerri Associazione di Promozione Sociale LOLUG Gruppo Utenti Linux Lodi davide@lolug.net 11 novembre 2008 Crittografia asimmetrica:

Dettagli

Guida ai certificati SSL User Guide

Guida ai certificati SSL User Guide Guida ai certificati SSL User Guide PROBLEMATICHE DEL WEB... 2 PRIVACY...3 AUTORIZZAZIONE/AUTENTICAZIONE...4 INTEGRITA DEI DATI...4 NON RIPUDIO...4 QUALI SONO I PRINCIPALI STRUMENTI UTILIZZATI PER GARANTIRE

Dettagli

Indice. Prefazione. Presentazione XIII. Autori

Indice. Prefazione. Presentazione XIII. Autori INDICE V Indice Prefazione Presentazione Autori XI XIII XV Capitolo 1 Introduzione alla sicurezza delle informazioni 1 1.1 Concetti base 2 1.2 Gestione del rischio 3 1.2.1 Classificazione di beni, minacce,

Dettagli

SIRV-INTEROP Sicurezza basata sui ruoli

SIRV-INTEROP Sicurezza basata sui ruoli SIRV-INTEROP (UML-A8.2-0) 06 ottobre 2004 Approvazioni Il presente documento è stato approvato da: UML-A8.2-0 18/11/05 16.25 2 Storia delle Modifiche Versione Data Descrizione Riferimenti Numero Titolo

Dettagli

Servizi di hosting offerti dall'area Servizi ICT Integrazione con l'anagrafica Unica di Ateneo. Area Servizi ICT

Servizi di hosting offerti dall'area Servizi ICT Integrazione con l'anagrafica Unica di Ateneo. Area Servizi ICT Area Servizi ICT Servizi hosting di Ateneo - Integrazione con l'anagrafica Unica di Ateneo Versione 1.1 http://hosting.polimi.it Servizi di hosting offerti dall'area Servizi ICT Integrazione con l'anagrafica

Dettagli

Il nuovo servizio di Posta Elettronica di Ateneo ZIMBRA-CINECA. Giancarlo Peli. Area Sistemi Direzione Informatica Università degli Studi di Verona

Il nuovo servizio di Posta Elettronica di Ateneo ZIMBRA-CINECA. Giancarlo Peli. Area Sistemi Direzione Informatica Università degli Studi di Verona Il nuovo servizio di Posta Elettronica di Ateneo ZIMBRA-CINECA Giancarlo Peli Area Sistemi Direzione Informatica Università degli Studi di Verona Descrizione del Progetto 1 L'attuale sistema di gestione

Dettagli

C) supponendo che la scuola voglia collegarsi in modo sicuro con una sede remota, valutare le possibili soluzioni (non risolto)

C) supponendo che la scuola voglia collegarsi in modo sicuro con una sede remota, valutare le possibili soluzioni (non risolto) PROGETTO DI UNA SEMPLICE RETE Testo In una scuola media si vuole realizzare un laboratorio informatico con 12 stazioni di lavoro. Per tale scopo si decide di creare un unica rete locale che colleghi fra

Dettagli

Al prompt inserire il seguente comando per installare le applicazioni server di SAMBA:

Al prompt inserire il seguente comando per installare le applicazioni server di SAMBA: Server Samba Reti Windows Sommario Introduzione Installare SAMBA Configurare SAMBA Server Client Spesso le reti di computer sono costituite da sistemi eterogenei e, sebbene gestire una rete composta interamente

Dettagli

LBINT. http://www.liveboxcloud.com

LBINT. http://www.liveboxcloud.com 2014 LBINT http://www.liveboxcloud.com LiveBox Srl non rilascia dichiarazioni o garanzie in merito al contenuto o uso di questa documentazione e declina qualsiasi garanzia espressa o implicita di commerciabilità

Dettagli

LA TEMATICA. Questa situazione si traduce facilmente:

LA TEMATICA. Questa situazione si traduce facilmente: IDENTITY AND ACCESS MANAGEMENT: LA DEFINIZIONE DI UN MODELLO PROCEDURALE ED ORGANIZZATIVO CHE, SUPPORTATO DALLE INFRASTRUTTURE, SIA IN GRADO DI CREARE, GESTIRE ED UTILIZZARE LE IDENTITÀ DIGITALI SECONDO

Dettagli

UNIVERSITÀ DEGLI STUDI DI PARMA

UNIVERSITÀ DEGLI STUDI DI PARMA UNIVERSITÀ DEGLI STUDI DI PARMA Facoltà di scienze Matematiche Fisiche e Naturali Corso di Laurea in INFORMATICA Tesi di laurea in RETI DI CALCOLATORI Autenticazione Centralizzata con il sistema CAS, integrando

Dettagli

MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale

MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale 1. Livello infrastrutturale Il Cloud, inteso come un ampio insieme di risorse e servizi fruibili da Internet che possono essere dinamicamente

Dettagli

Alcuni elementi di sicurezza sulle reti

Alcuni elementi di sicurezza sulle reti Alcuni elementi di sicurezza sulle reti La sicurezza è un aspetto centrale per le attuali reti dati. Come tutti sanno le minacce provenienti da Internet aumentano di continuo, e le possibilità di attacco

Dettagli

PROGETTO - Ingegneria del Software. Università degli Studi di Milano Polo di Crema. Corso di laurea in Scienze Matematiche, Fisiche e Naturali

PROGETTO - Ingegneria del Software. Università degli Studi di Milano Polo di Crema. Corso di laurea in Scienze Matematiche, Fisiche e Naturali Università degli Studi di Milano Polo di Crema Corso di laurea in Scienze Matematiche, Fisiche e Naturali INFORMATICA Corso di Ingegneria del Software progetto IL SISTEMA CALENDAR Presentato al dott. Paolo

Dettagli

(Allegato C ) Allegato C. Misure di sicurezza. Il presente allegato descrive le caratteristiche della

(Allegato C ) Allegato C. Misure di sicurezza. Il presente allegato descrive le caratteristiche della (Allegato C ) Allegato C Misure di sicurezza Il presente allegato descrive le caratteristiche della piattaforma e le misure adottate per garantire l'integrita' e la riservatezza dei dati scambiati e conservati,

Dettagli

La nuova Posta Elettronica IMAP del C.S.B.N.O. di Restelli Paolo. Appendice 2 : Protocolli sicuri, autenticazione sicura e certificati ( P.

La nuova Posta Elettronica IMAP del C.S.B.N.O. di Restelli Paolo. Appendice 2 : Protocolli sicuri, autenticazione sicura e certificati ( P. Rho, Luglio 07, 2006 CORSI ON-LINE La nuova Posta Elettronica IMAP del C.S.B.N.O. di Restelli Paolo Appendice 2 : Protocolli sicuri, autenticazione sicura e certificati ( P. Restelli) Attualmente la maggior

Dettagli

Protezione delle informazioni in SMart esolutions

Protezione delle informazioni in SMart esolutions Protezione delle informazioni in SMart esolutions Argomenti Cos'è SMart esolutions? Cosa si intende per protezione delle informazioni? Definizioni Funzioni di protezione di SMart esolutions Domande frequenti

Dettagli

Concetti base. Impianti Informatici. Web application

Concetti base. Impianti Informatici. Web application Concetti base Web application La diffusione del World Wide Web 2 Supporto ai ricercatori Organizzazione documentazione Condivisione informazioni Scambio di informazioni di qualsiasi natura Chat Forum Intranet

Dettagli

1.1 - Crittografia sulla infrastruttura trasmissiva tra le stazioni remote Rilheva il centro di telecontrollo

1.1 - Crittografia sulla infrastruttura trasmissiva tra le stazioni remote Rilheva il centro di telecontrollo SISTEMA DI TELECONTROLLO RILHEVA GPRS (CARATTERISTICHE DEL VETTORE GPRS E SICUREZZE ADOTTATE) Abstract: Sicurezza del Sistema di Telecontrollo Rilheva Xeo4 ha progettato e sviluppato il sistema di telecontrollo

Dettagli

Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security con token SAML

Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security con token SAML Master Universitario di II livello in Interoperabilità Per la Pubblica Amministrazione e Le Imprese Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security

Dettagli

Gestione password per le utenze del dominio di autenticazione AMM (amm.dom.uniroma1.it)

Gestione password per le utenze del dominio di autenticazione AMM (amm.dom.uniroma1.it) Centro Infosapienza Ufficio gestione sistemi Settore sistemi centrali e per l office automation Gestione password per le utenze del dominio di autenticazione AMM (amm.dom.uniroma1.it) Sommario 1. Premessa...

Dettagli

hdone 1 Overview 2 Features hdone Team 13 dicembre 2007

hdone 1 Overview 2 Features hdone Team 13 dicembre 2007 hdone hdone Team 13 dicembre 2007 1 Overview hdone è una web application che fornisce il supporto necessario a tutte le aziende che si occupano di fornire servizi di assistenza al cliente. Dopo gli anni

Dettagli

Tracciabilità degli utenti in applicazioni multipiattaforma

Tracciabilità degli utenti in applicazioni multipiattaforma Tracciabilità degli utenti in applicazioni multipiattaforma Case Study assicurativo/bancario Yann Bongiovanni y.bongiovanni@integra-group.it Roma, 4 ottobre 2006 Retroscena Un azienda multinazionale del

Dettagli

Uso sicuro del web Navigare in siti sicuri

Uso sicuro del web Navigare in siti sicuri Uso sicuro del web Navigare in siti sicuri La rete internet, inizialmente, era concepita come strumento di ricerca di informazioni. L utente esercitava un ruolo passivo. Non interagiva con le pagine web

Dettagli

UNIVERSITÀ DEGLI STUDI DI PADOVA

UNIVERSITÀ DEGLI STUDI DI PADOVA UNIVERSITÀ DEGLI STUDI DI PADOVA DIREZIONE AMMINISTRATIVA Servizio programmazione e sviluppo progetti SCHEDA PROGETTI INNOVATIVI 1. Titolo del progetto Autenticazione e Single Sign On 2. Breve descrizione

Dettagli

Shibboleth enabling a web service: Nilde s case study

Shibboleth enabling a web service: Nilde s case study II giornata su Authentication & Authorization Infrastructure (AAI): Autenticazione federata e biblioteche digitali. Roma, 6 Marzo 2007 Shibboleth enabling a web service: Nilde s case study Silvana Mangiaracina

Dettagli

Sme.UP Web Application

Sme.UP Web Application Sme.UP Web Application Web Application Web.UP Una interfaccia web per i vostri dati gestionali Il modulo applicativo Web.UP fornisce al progettista di siti Internet una serie di potenti strumenti per l'integrazione

Dettagli

COOKIE POLICY DEL SITO

COOKIE POLICY DEL SITO COOKIE POLICY DEL SITO PREMESSA Questa pagina costituisce una sezione dell'informativa privacy estesa consultabile sul sito e descrive nello specifico l'utilizzo dei cookie effettuato dal titolare. INFORMAZIONI

Dettagli

Guida a Gmail UNITO v 02 2

Guida a Gmail UNITO v 02 2 MANUALE D USO GOOGLE APPS EDU versione 1.0 10/12/2014 Guida a Gmail UNITO v 02 2 1. COME ACCEDERE AL SERVIZIO DI POSTA SU GOOGLE APPS EDU... 3 1.1. 1.2. 1.3. Operazioni preliminari all utilizzo della casella

Dettagli

LBSEC. http://www.liveboxcloud.com

LBSEC. http://www.liveboxcloud.com 2014 LBSEC http://www.liveboxcloud.com LiveBox Srl non rilascia dichiarazioni o garanzie in merito al contenuto o uso di questa documentazione e declina qualsiasi garanzia espressa o implicita di commerciabilità

Dettagli

WHITE PAPER: White paper. Guida introduttiva. ai certificati SSL. Istruzioni per scegliere le migliori opzioni di sicurezza online

WHITE PAPER: White paper. Guida introduttiva. ai certificati SSL. Istruzioni per scegliere le migliori opzioni di sicurezza online WHITE PAPER: Guida introduttiva AI certificati SSL White paper Guida introduttiva ai certificati SSL Istruzioni per scegliere le migliori opzioni di sicurezza online Guida introduttiva ai certificati SSL

Dettagli

Reti e Domini Windows 2000. Corso di Amministrazione di Reti A.A. 2002/2003

Reti e Domini Windows 2000. Corso di Amministrazione di Reti A.A. 2002/2003 Reti e Domini Windows 2000 Corso di Amministrazione di Reti A.A. 2002/2003 Materiale preparato utilizzando dove possibile materiale AIPA http://www.aipa.it/attivita[2/formazione[6/corsi[2/materiali/reti%20di%20calcolatori/welcome.htm

Dettagli

Framework di sicurezza della piattaforma OCP (Identity & Access Management)

Framework di sicurezza della piattaforma OCP (Identity & Access Management) Smart Cities and Communities and Social Innovation Bando MIUR D.D. 91/Ric. del 5 luglio 2012 Framework di sicurezza della piattaforma OCP (Identity & Access Management) AAI: Il problema che OCP ha affrontato

Dettagli

Il Livello delle Applicazioni

Il Livello delle Applicazioni Il Livello delle Applicazioni Il livello Applicazione Nello stack protocollare TCP/IP il livello Applicazione corrisponde agli ultimi tre livelli dello stack OSI. Il livello Applicazione supporta le applicazioni

Dettagli

LBSEC. http://www.liveboxcloud.com

LBSEC. http://www.liveboxcloud.com 2014 LBSEC http://www.liveboxcloud.com LiveBox Srl non rilascia dichiarazioni o garanzie in merito al contenuto o uso di questa documentazione e declina qualsiasi garanzia espressa o implicita di commerciabilità

Dettagli

Vpn Ateneo di Parma (Sito ufficiale:

Vpn Ateneo di Parma (Sito ufficiale: Vpn Ateneo di Parma (Sito ufficiale: Premessa http://www.unipr.it/arpa/setbibl/vpn/vpn.html ). L'Università di Parma si è dotata di un terminatore di VPN (Virtual Private Network) che consentirà agli utenti

Dettagli

Politica sui cookie. Introduzione Informazioni sui cookie

Politica sui cookie. Introduzione Informazioni sui cookie Introduzione Informazioni sui cookie Politica sui cookie La maggior parte dei siti web che visitate utilizza i cookie per migliorare l'esperienza dell'utente, consentendo al sito di 'ricordarsi' di voi,

Dettagli

Corso Specialista Sistemi Ambiente Web. Test finale conoscenze acquisite - 15.12.2003. Windows 2000 Server

Corso Specialista Sistemi Ambiente Web. Test finale conoscenze acquisite - 15.12.2003. Windows 2000 Server Windows 2000 Server 1 A cosa serve il task manager? A A monitorare quali utenti stanno utilizzando una applicazione B A restringere l'accesso a task determinati da parte degli utenti C Ad interrompere

Dettagli

w w w. n e w s o f t s r l. i t Soluzione Proposta

w w w. n e w s o f t s r l. i t Soluzione Proposta w w w. n e w s o f t s r l. i t Soluzione Proposta Sommario 1. PREMESSA...3 2. NSPAY...4 2.1 FUNZIONI NSPAY... 5 2.1.1 Gestione degli addebiti... 5 2.1.2 Inibizione di un uso fraudolento... 5 2.1.3 Gestione

Dettagli

Informativa e consenso per l utilizzo delle Google Apps for Education ISMC ALLEGATO 2 ALLEGATO 2 PRIVACY DI GOOGLE

Informativa e consenso per l utilizzo delle Google Apps for Education ISMC ALLEGATO 2 ALLEGATO 2 PRIVACY DI GOOGLE Pag. 1 di 8 PRIVACY DI GOOGLE (http://www.google.com/intl/it/policies/privacy/ Ultima modifica: 19 agosto 2015) I nostri servizi possono essere utilizzati in tanti modi diversi: per cercare e condividere

Dettagli

Informativa estesa. I dati personali che Lei fornirà verranno registrati e conservati su supporti elettronici protetti

Informativa estesa. I dati personali che Lei fornirà verranno registrati e conservati su supporti elettronici protetti Informativa estesa Informativa Privacy RCS Gaming S.r.l., con sede a Milano, Via A. Rizzoli 8 è il Titolare del Trattamento dei dati personali raccolti su questo sito ai sensi e per gli effetti del Codice

Dettagli

Modulo 7 - ECDL Reti informatiche

Modulo 7 - ECDL Reti informatiche 1 Modulo 7 - ECDL Reti informatiche Elaborazione in Power Point del Prof. Fortino Luigi 2 Internet Un insieme di molteplici reti di elaboratori collegate tra loro che, con l ausilio di particolari protocolli

Dettagli

Harika dà grande valore al diritto alla privacy dei propri utenti e fornisce, pertanto, questa dichiarazione

Harika dà grande valore al diritto alla privacy dei propri utenti e fornisce, pertanto, questa dichiarazione DICHIARAZIONE SULLA PRIVACY Harika dà grande valore al diritto alla privacy dei propri utenti e fornisce, pertanto, questa dichiarazione che disciplina la raccolta ed il trattamento dei dati personali

Dettagli

BlackBerry Social Networking Application Proxy per ambienti Microsoft SharePoint

BlackBerry Social Networking Application Proxy per ambienti Microsoft SharePoint BlackBerry Social Networking Application Proxy per ambienti Microsoft SharePoint Versione: 2.0 Guida di installazione e configurazione Pubblicato: 2011-12-08 SWDT1177102-1864151-1208024337-004 Indice 1

Dettagli

Meccanismi di autenticazione sicura. Paolo Amendola GARR-CERT

Meccanismi di autenticazione sicura. Paolo Amendola GARR-CERT Meccanismi di autenticazione sicura Paolo Amendola GARR-CERT Argomenti Crittografazione del traffico Identita digitali One-time passwords Kerberos Crittografazione del traffico Secure Shell SASL SRP sftp

Dettagli

Seminario di Sistemi Distribuiti: RPC su SOAP

Seminario di Sistemi Distribuiti: RPC su SOAP Corso di Sistemi Distribuiti Prof. S. Balsamo Seminario di Sistemi Distribuiti: RPC su SOAP [ 777775] 1 INTRODUZIONE 3 2 RPC 3 3 SOAP (SIMPLE OBJECT ACCESS PROTOCOL) 3 4 UTILIZZO DI SOAP COME PROTOCOLLO

Dettagli

Ogni browser (Internet Explorer, Google Chrome, Mozilla Firefox o Safari) permette di impostare le preferenze per i cookie.

Ogni browser (Internet Explorer, Google Chrome, Mozilla Firefox o Safari) permette di impostare le preferenze per i cookie. COSA SONO? Un cookie è rappresentato da un file di testo memorizzato sul vostro computer, tramite il browser di navigazione, creato durante la navigazione sui siti web. Servono nella maggioranza dei casi

Dettagli

Problematiche correlate alla sicurezza informatica nel commercio elettronico

Problematiche correlate alla sicurezza informatica nel commercio elettronico Problematiche correlate alla sicurezza informatica nel commercio elettronico http://www.infosec.it info@infosec.it Relatore: Stefano Venturoli, General Manager Infosec Italian Cyberspace Law Conference

Dettagli

Dipartimento di Informatica e Scienze dell Informazione. OpenSSH. Simon Lepore. Corso di Sicurezza. DISI, Universita di Genova

Dipartimento di Informatica e Scienze dell Informazione. OpenSSH. Simon Lepore. Corso di Sicurezza. DISI, Universita di Genova Dipartimento di Informatica e Scienze dell Informazione OpenSSH Simon Lepore Corso di Sicurezza DISI, Universita di Genova Via Dodecaneso 35, 16146 Genova, Italia http://www.disi.unige.it 1 Contenuti Introduzione...3

Dettagli

Nelle reti di calcolatori, le porte (traduzione impropria del termine. port inglese, che in realtà significa porto) sono lo strumento

Nelle reti di calcolatori, le porte (traduzione impropria del termine. port inglese, che in realtà significa porto) sono lo strumento I protocolli del livello di applicazione Porte Nelle reti di calcolatori, le porte (traduzione impropria del termine port inglese, che in realtà significa porto) sono lo strumento utilizzato per permettere

Dettagli

BlackBerry Internet Service Uso del browser dello smartphone BlackBerry Versione: 2.6. Manuale dell'utente

BlackBerry Internet Service Uso del browser dello smartphone BlackBerry Versione: 2.6. Manuale dell'utente BlackBerry Internet Service Uso del browser dello smartphone BlackBerry Versione: 2.6 Manuale dell'utente SWDT228826-600991-0122103435-004 Indice Guida introduttiva... 2 Informazioni di base sul sito Web

Dettagli

Comunicazioni sicure su Internet: https e SSL. Fisica dell Informazione

Comunicazioni sicure su Internet: https e SSL. Fisica dell Informazione Comunicazioni sicure su Internet: https e SSL Fisica dell Informazione Il servizio World Wide Web (WWW) Come funziona nel dettaglio il Web? tre insiemi di regole: Uniform Resource Locator (URL) Hyper Text

Dettagli

Uso di una procedura di autenticazione unificata per client Linux e Microsoft Windows su server Microsoft Windows.

Uso di una procedura di autenticazione unificata per client Linux e Microsoft Windows su server Microsoft Windows. UNIVERSITA DEGLI STUDI G. D ANNUNZIO CHIETI-PESCARA FACOLTA ECONOMIA LAUREA DI I LIVELLO IN ECONOMIA INFORMATICA TESI DI LAUREA Uso di una procedura di autenticazione unificata per client Linux e Microsoft

Dettagli

Obiettivo: realizzazione di reti sicure TIPI DI ATTACCO. Politica di sicurezza: a) scelte tecnologiche b) strategie organizzative

Obiettivo: realizzazione di reti sicure TIPI DI ATTACCO. Politica di sicurezza: a) scelte tecnologiche b) strategie organizzative Obiettivo: realizzazione di reti sicure Politica di sicurezza: a) scelte tecnologiche b) strategie organizzative Per quanto riguarda le scelte tecnologiche vi sono due categorie di tecniche: a) modifica

Dettagli

Informativa sulla privacy

Informativa sulla privacy Informativa sulla privacy Kelly Services, Inc. e le sue affiliate ("Kelly Services" o "Kelly") rispettano la vostra privacy e riconoscono i vostri diritti relativi ai dati personali che acquisisce da voi,

Dettagli

PKI PUBLIC KEY INFRASTRUCTURES

PKI PUBLIC KEY INFRASTRUCTURES Premesse PKI PUBLIC KEY INFRASTRUCTURES Problemi Come distribuire in modo sicuro le chiavi pubbliche? Come conservare e proteggere le chiavi private? Come garantire l utilizzo corretto dei meccanismi crittografici?

Dettagli

La sicurezza secondo skymeeting (data pubblicazione 06/12/2011)

La sicurezza secondo skymeeting (data pubblicazione 06/12/2011) La sicurezza secondo skymeeting (data pubblicazione 06/12/2011) www.skymeeting.net La sicurezza nel sistema di videoconferenza Skymeeting skymeeting è un sistema di videoconferenza web-based che utilizza

Dettagli

NETASQ V9: PKI & Controllo accessi. Presentation Marco Genovese Presales engineer marco.genovese@netasq.com

NETASQ V9: PKI & Controllo accessi. Presentation Marco Genovese Presales engineer marco.genovese@netasq.com NETASQ V9: PKI & Controllo accessi Presentation Marco Genovese Presales engineer marco.genovese@netasq.com Alcuni concetti Alcuni concetti prima di incominciare per chiarire cosa è una PKI e a cosa serve

Dettagli

Deploy di infrastrutture di rete business tramite ambienti completamente virtualizzati

Deploy di infrastrutture di rete business tramite ambienti completamente virtualizzati Deploy di infrastrutture di rete business tramite ambienti completamente virtualizzati Dott. Emanuele Palazzetti Your Name Your Title Your Organization (Line #1) Your Organization (Line #2) Indice degli

Dettagli

Xerox SMart esolutions. White Paper sulla protezione

Xerox SMart esolutions. White Paper sulla protezione Xerox SMart esolutions White Paper sulla protezione White Paper su Xerox SMart esolutions La protezione della rete e dei dati è una delle tante sfide che le aziende devono affrontare ogni giorno. Tenendo

Dettagli

Internet e posta elettronica. A cura di Massimiliano Buschi

Internet e posta elettronica. A cura di Massimiliano Buschi Internet e posta elettronica A cura di Massimiliano Buschi Concetti fondamentali Internet www Tcp/ip Browser Terminologia Esistono un sacco di termini con cui bisogna famigliarizzare http url Link Isp

Dettagli

Le Reti (gli approfondimenti a lezione)

Le Reti (gli approfondimenti a lezione) Le Reti (gli approfondimenti a lezione) Per migliorare la produttività gli utenti collegano i computer tra di loro formando delle reti al fine di condividere risorse hardware e software. 1 Una rete di

Dettagli

Visione Generale. Versione 1.0 del 25/08/2009

Visione Generale. Versione 1.0 del 25/08/2009 Visione Generale Versione 1.0 del 25/08/2009 Sommario 1 Premessa... 4 2 Le componenti applicative... 6 2.1 Porta di dominio... 7 2.2 Infrastrutture per la cooperazione... 9 2.2.1 Registro degli Accordi

Dettagli

Una soluzione per i portali amministrativi (e-government)

Una soluzione per i portali amministrativi (e-government) Una soluzione per i portali amministrativi (e-government) COME NASCE LA SOLUZIONE Proteggere gli accessi distanti al portale amministrativo con l'autenticazione multi fattore XELIOS VNA (Virtual Network

Dettagli