OAUTH: IMPLEMENTAZIONE IN JOLIE

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "OAUTH: IMPLEMENTAZIONE IN JOLIE"

Transcript

1 UNIVERSITÀ DEGLI STUDI DI UDINE Dipartimento di Matematica e Informatica Corso di Laurea Magistrale in Informatica Laboratorio avanzato OAUTH: IMPLEMENTAZIONE IN JOLIE Relatore: Prof. MARINO MICULAN Studente: LUCA FULCHIR ANNO ACCADEMICO

2

3 Contents 1 Introduzione Il progetto Jolie OAuth Funzionamento OAuth OAuth Implementazione La libreria Conclusioni Jolie OAuth iii

4

5 Chapter 1 Introduzione 1.1 Il progetto Il progetto riguarda l implementazione del protocollo OAuth1 e OAuth2 nel linguaggio di programmazione Jolie 1.2. Lo scopo del progetto è verificare l usabilità del linguaggio di programmazione in relazione allo stile di programmazione service-oriented offerto da Jolie. Nel contempo verrà analizzato il protocollo OAuth nelle sue versioni OAuth1(1.3.1) e OAuth2(1.3.2). 1.2 Jolie Jolie 1 è un linguaggio nato nel 2006 all università di Bologna. Si tratta di un linguaggio di programmazione service-oriented. Questo significa che la programmazione rifletterà direttamente la suddivisione del codice in servizi a seconda del loro scopo, similmente ad una suddivisione in classi. Rispetto ad una programmazione a classi, ogni comunicazione non avverrà tramite invocazione di metodi, ma tramite rete con il protocollo che il programmatore preferisce, e senza richiedere che il programmatore si interessi ad alcun dettaglio della comunicazione sottostante. Il programmatore vede solo una struttura simile alle classi, pur programmando effettivi servizi di rete, senza preoccuparsi troppo di sincronizzazioni, concorrenze o implementazioni dei protocolli sottostanti. 1.3 OAuth OAuth è un set di protocolli open per l autenticazione e autorizzazione degli utenti. Esistono due versioni del protocollo, OAuth1 e OAuth2, entrambe basate su HTTP. In entrambe le versioni il funzionamento principale del protocollo è dato dallo scambio di token e redirect tra 3 partecipanti: 1 1

6 2 Introduzione Client : l applicazione client che vuole autenticare un utente su un dato servizio Server di Risorse : Il server su cui sono hostate le risorse a cui l applicazione avrà accesso alla fine dell autenticazione. Server d autenticazione : Il server a cui manderemo le varie autenticazioni, e che ci autorizzerà sul server delle risorse OAuth1 Questa prima viene creata nel È stato il frutto del lavoro di una community a cui hanno partecipato, tra altri, twitter e google. La prima draft del protocollo è uscita nel 2007 e l ultima standardizzazione risale al 2010 con la version 1.0a 2, Una novità introdotta da questo protocollo sta nel gestire sia l autenticazione che l autorizzazione degli utenti. con la prima verifichiamo che l utente sia chi dice di essere, e con la seconda verifchiamo che l utente e l applicazione abbiano i permessi giusti all interno delle possibili azioni dell utente. Altra novità introdotta da questo protocollo è l autenticazione dell applicazione oltre all autenticazione dell utente. Una conseguenza di questo e del fatto che lo standard non prevede autenticazioni anonime, è che ogni applicazione va scritta specificatamente per il servizio a cui vuole accedere. Questo collegamento stretto tra applicazione e servizio è comunque richiesto a causa della mancanza di standardizzazione degli URI da chiamare nelle varie fasi d autenticazione. Nonostante questo protocollo tenti di rendersi sicuro firmando tutti i parametri delle richieste in modo da evitare eventuali attacchi, usarlo senza SSL/TLS è insicuro, in quanto non autentica in nessun modo il server d autenticazione e quindi senza SSL/TLS è vulerabile ad attacchi di spoofing OAuth2 Nel 2010 Google, Microsoft, Twitter, Facebook e altri decidono che OAuth1 non rispecchia a pieno le loro necessità, e decidono di lavorare ad una seconda versione di OAuth1. Il risultato sarà standardizzato finalmente 3 anni dopo, alla fine del 2012, ed è incompatibile con la prima version del protocollo. Questo nuovo standard ha creto molte controversie a causa del lungo periodo di standardizzazione (3 anni), specifiche lunghe e poco chiare, e mancate migliorie: le varie implementazioni OAuth2 restano incompatibili (come OAuth1) in quanto ogni applicazione dev essere scritta per un determinato servizio. A peggiorare la compatibilità tra implementazioni, ogni parte del framework OAuth2 è totalmente estendibile e rimpiazzabile, complicando ulteriormente eventuali implementazioni. Visto che questa versione comprende molte parti opzionali o totalmente reimplementabli con altri meccanismi, non è stata accettata dall IETF sotto la definizione di protocollo ma solo sotto la più lasca definizione di framework. A causa di questi e altri problemi durante la standardizzazione, il responsabile della stasura di OAuth 2.0, Eran Hammer 4, si è ritirato qualche mese prima della standardizzazione del framework arrivando perfino a far togliere il proprio nome dai responsabili per la stesura della specifica. 2 RFC Spoofing attack: 4 Eran Hammer:OAuth 2.0 and the Road to Hell:

7 1.3. OAuth 3 Le principali differenze rispetto alla prima versione sono la richiesta esplicita dell uso di SSL/TLS, l introduzione di token di refresh per aggiornare i token d autenticazione, la mancanza di firme crittografiche per garantire l integrità e sicurezza dei dati, che ora viene delegata a SSL/TLS, e la generale possibilità di rimpiazzare o modificare ogni parte dell autenticazione con meccanismi ad-hoc.

8

9 Chapter 2 Funzionamento 2.1 OAuth1 Il workflow del protocollo OAuth1 è unico e relativamente semplice, si divide in 3 fasi: Request Token : Richiesta di un token temporaneo, non ancora autorizzato; verifica dell autenticazione dell applicazione Browser Authorization : L utente viene rediretto sul sito del fornitore del servizio per loggarsi e autorizzare l applicazione all accesso. Access Token : L applicazione riceve i codici di risposta dal passo precedente e chiede al server d autenticazione un token da usare per l accesso alle risorse Il passaggio dalla seconda alla terza fase è effettuato tramite redirect HTTP. Se l applicazione non vuole o non può gestire richieste HTTP, essa dovrà effettuare una serie di richieste in polling sul server d autenticazione per essere sicuri che l utente abbia avuto tempo d autenticarsi. Per implementare OAuth1 sono necessarie 3 pagine web, la request, per la ricezione del token temporaneo alla fase 1, la authorize, per la fase 2, e la access per la terza fase. 5

10 6 Funzionamento Nella figura sottostante è riassunto il workflow OAuth1 con i messaggi e le risposte. L autenticazione dell applicazione è fornita tramite l identificativo specificato nell elemento oauth consumer key e un segreto condiviso. Come si può notare vengono usato dei timestamp per verificare l attendibilità delle informazioni ricevute, e quindi questo protocollo richiede che gli orologi siano sincronizzati fino a un certo errore, non definito nelle specifiche. Vengono inoltre usate delle nouce per evitare attacchi replay. Le nounce sono inviate solo dal client verso il server, e non vengono rispedite indietro dal server al client nella risposta. Secondo la specifica Il server dovrebbe mantenere un database per associare le nounce con le informazioni ricevute per evitare attacchi replay. Nonostante questo abbia senso, si pone un grosso carico sul server ed è probabile che per questo le implementazioni, soprattutto grosse, evitino di fare questo controllo. In questo caso se un attaccante riuscisse ad arrivare ai dati scambiati tra l applicazione e il server avrebbe di fatto accesso al pari dell applicazione. Tuttavia il sistema resta sicuro grazie al sottostante strato SSL, a patto che il client controlli il certificato del server a cui si connette.

11 2.2. OAuth OAuth2 Le fasi d autenticazione sono rimaste sostanzialmente le stesse del protocollo OAuth1, ma possono variare a seconda del tipo d accesso richiesto dall applicazione. La prima fase ora viene chiamata Authorization Request, e la terza fase Grant Request, dove il grant è l autorizzazione concessa all applicazione. Lato server vanno implementate 2 pagine web, una per la gestione delle richieste d autorizzazione e una per le richieste d accesso. Esistono 5 tipi di autorizzazioni possibili, a seconda del tipo di grant e delle informazioni disponibili all applicazione: Authorization Code Grant : Questo è il metodo più diffuso, l applicazione lavora interamente con i token generati lato server. A parte per il contenuto dei messaggi ricalca il workflow di OAuth1. L applicazione deve poter gestire richieste HTTP. viene fatta una richiesta alla pagina di autorizzazione, l utente si autentica sul sito del servizio, viene rediretto all applicazione che fa una richiesta alla pagina d accesso per ottenere i token necessari. Implicit Grant : Quest autorizzazione si limita ad autenticare l utente, non l applicazione, e non vengono generati token di refresh. L applicazione deve poter gestire richieste HTTP. Viene fatta una sola richiesta alla pagina d autorizzazione e nel redirect di ritorno sono già presenti i token da usare. Resource Owner Password Grant : Se l utente si fida dell applicazione, può dare a questa il suo nome utente e la password, e l applicazione userà queste per autenticarsi. dopo la prima autenticazione l applicazione deve tornare a lavorare solo con i token, usando solo la terza fase. In questa modalità viene fatta una richeista lla pagina d autorizzazione se vogliamo autorizzare l applicazione, e una richiesta obbligatoria alla pagina di accesso Client Credentials Grant : Questo è il complementare dell Implicit Grant. Viene autenticata l applicazione, ma non l utente. Viene fatta una richiesta alla pagina d autorizzazione e una alla pagina d accesso, saltando la seconda fase dell autenticazione con Authorization Code. È usata per risorse pubbliche. Extension Grant : Per ogni altro tipo di autenticazione si può usare questo metodo. Viene fatta una singola richiesta alla pagina d accesso, con un solo parametro grant type, contentente tutte le informazioni, e viene ritornata una risposta standard in caso di successo. Tutta la sicurezza del protocollo si basa sulla sicurezzaa dello strato SSL/TLS sottostante. La sicurezza dell autenticazione dell applicazione resta dubbia in quanto le credenziali vanno per forza incorporate nel codice dell applicazione. Per una qualsiasi applicazione web lato client tali segreti sono comodamente esposti nel codice, e dovrebbe quindi sempre usare il metodo d autorizzazione Implicit Grant. Tuttavia a meno di trovarsi su client sicuri in cui l utente non ha alcun controllo, in generale ogni segreto incorporato in un applicazione ha vita breve, in quanto i dati sono sempre estraibili dal binario dell applicazione. Altri attacchi sono possibili al protocollo se non vengono usate tutte le feature presenti come l url di redirezione o la variabile stato 1. Per eliminare questi attachi i vari 1 OAuth2 Attack vectors:

12 8 Funzionamento provider hanno reintrodotto con parametri non standard e differenti uno dall altro la firma crittografica presente in OAuth1, con il risultato di una maggiore sicurezza, a scapito della compatibilità tra implementazioni per diversi servizi Jolie Essendo un linguaggio di programmazione orientato alla costruzione di servizi la sua struttura riflette questa caratteristica: In un progetto possiamo identificare delgi header, con estensione.iol e file di codice con estensione.ol. In realtà l estensione è una pura convenzione, e non è forzata in alcun modo. In ogni servizio possiamo identificare diverse parti: Definizione dei tipi : semplice e diretta, ad esempio: type mytype : s t r i n g {. element : i n t. e l 2? : s t r i n g // elemento opzionale. e l 3 : mytype // array } La definizione delle strutture è centrale nella programmazione a causa del fatto che ogni servizio ha al massimo un elemento in input e sempre un solo elemento in output. Ogni servizio è forzato a lavorare solo sulle strutture per cui è pensato. Nonostante Jolie non sia un linguaggio tipato ed è possibile aggiungere elementi o toglierne ad una qualsiasi struttura, al momento della chiamata la struttura deve corrispondere esattamente con il tipo richiesto, senza elementi aggiuntivi o mancanti. I tipi di base sono: string, int, long, double, bool, raw, void, any. Interfacce : Servono a raggruppare un set di operazioni per uno o più servizi. definiscono il tipo di chiamata e i tipi su cui lavora, più un eventuale eccezione. i n t e r f a c e MyInterface { RequestResponse : Request1 ( s t r i n g ) ( mytype ) throws wrong answer, t e s t ( input ) ( mytype output ) OneWay : p r i n t l n ( s t r i n g ) //input, no output } Porte di comunicazione : per definire input e output di un servizio. Le direttive output- Port e inputport hanno sintassi identica, come nell esempio: inputport i d e n t i f i c a t i v o { Location : URI Protocol : p I n t e r f a c e s : i n t e r f a c e 1, i n t e r f a c e 2 } L unico parametro richeisto è Interfaces, mentre gli altri se non specificati vengono impostati a valori per le sole comunicazioni locali tra servizi Jolie.

13 2.2. OAuth2 9 Generalmente le porte di input e output per un servizio saranno coincidenti, a meno di chiamate OneWay, ma è possibile definire più porte di output e di input, con interfaccie diverse, ed includerle in header differenti in modo da rendere disponibili solo alcune chiamate. L effetto finale sarà comunque la creazione di più servizi. Ogni servizio sarà richiamabile come metodo Embedding : tramite queste direttive possiamo collegare del codice (jolie, java, javascript e altro) ad una porta di output. embedded { J o l i e : my code. ol in myoutputport } Questo è il metodo esplicito per il collegamento della definizione del servizio alla sua realizzazione, e determina la creazione del servizio. Codice : Composto dalla definizione di tre parti: init {} : una funzione di inizializzazione del servizio, eseguita una sola volta al primo caricamento dello stesso. main{} : la funzione principale che conterrà il codice vero e proprio e la definizione delle varie chiamate define myprocedure {} : definizioni di procedure: nessun input / output definito esplicitamente. Lavora per dynamic binding, per cui tutte le variabili usate saranno quelle accessibili nel punto in cui questa funzione è stata chiamata. Jolie non ha il concetto di variabile a scope locale. Jolie è scritto in java ed è un linguaggio totalmente a runtime. Dopo una prima verifica di sintassi dell intero progetto, Jolie procede con la sua esecuzione. I controlli effettuati sul codice sono ancora pochi, dato che il linguaggio è relativamente nuovo e non troppo usato. Di seguito vengono riportati esempi di problemi riscontrati: Non esiste alcun controllo sull inclusione circolare di header, il che può portare alla creazione di copie dello stesso servizio fino alla saturazione della memoria. Il valore di output delle chiamate non è sempre controllato: un output di un array verrà troncato al primo elemento. Questo è dovuto al fatto che per Jolie un elemento è in realtà simile ad un array di un elemento senza errori, ma è contrastante rispetto alla verifica dettagliata dei tipi in altri casi. Nessun errore in caso di uso di elemento non definito altrove: alcuni esempi come mystring = mystring + salve ; possono essere distruttivi: il secondo mystring è diverso dal primo, ed il risultato è che in mystring si troverà solo la stringa salve, senza nessun errore. Dato che il linguaggio non richiede la definizione delle variabili, ogni typo crea nuove variabili senza dare errore, cosa che può complicare il debugging delle applicazioni. Il parser funziona, ma va rivista la parte di error recovery. Dimenticare un semplice puntovirgola alla fine della stringa può portare a molti errori, ma nonostante una serie di errori seguita da una nullpointerexception e stacktrace java del parser può aiutare lo sviluppatore del linguaggio, non aiuta decisamente il programmatore che usa il linguaggio. In generale i problemi del linguaggio per ora dipendono dalla sua poca diffusione, più che da problemi di design.

14

15 Chapter 3 Implementazione Per l implementazione di OAuth1 e OAuth2 si è usata la seguente struttura di servizi: Una serie di servizi scritti in Java e embeddati in Jolie per avere una comunicazione via HTTP più flessibile e per le primitive di crittografia, difficilmente implementabili in un linguaggio ad alto livello come Jolie. Un servizio di traduzione dei dati presa una struttura contenente i dati dell applicazione deve costruire una struttura semplice da usare nelle richieste HTTP con i dati giusti al posto giusto. Infine l interfaccia di libreria, che nasconde il servizio di traduzione dei dati e espone solo le chiamate necessarie al funzionamento del protocollo, effettua le richieste HTTP, controlla le risposte e gestisce il tutto con strutture semplici per l utente. La struttura è stata mantenuta sia per OAuth1 che OAuth2. Dato che il protocollo richiede all applicazione utente di rispondere a delel chiamate HTTP, questa parte è lasciata all utente, sia per la semplicità dell implementazione in Jolie, sia per dare maggiore controllo all applicazione nel caso debba già restare in ascolto per altre richieste, e per farscegliere all applicazione dove stare in ascolto. La libreria è stata creata in modo che l utente debba solo inserire i dati di autenticazione principali, ma in modo che sia possibile inserire e ricevere qualsiasi altro parametro nelle richieste HTTP, per poter essere compatibile con tutte le varie implementazioni dei protocolli. 11

16 12 Implementazione Dato che in Jolie non è possibile usare strutture con elementi non esplicitamente dichiarati, e dato che non è possibile prevedere quali parametri useranno i vari fornitori di servizio, l unico modo di rendere disponibili i parametri HTTP generici è l uso di strutture generiche come array chiave-valore, meno efficienti dell uso di strutture Jolie, perchè richiedono una ricerca in O(n). Una struttura tipo hashmap sarebbe meno efficente dato l esiguo numero di elementi e la complessità delle funzioni di hashing. 3.1 La libreria OAuth1 Le seguenti chiamate sono accessibili per la libreria OAuth1: requesttoken : Fase 1 dell autenticazione, per prendere i token temporanei getrereffal : Fase due dell autenticazione, per dire all utente dove deve puntare il browser e autenticarsi getaccess : Fase finale, per prendere i token d accesso reali. Tutte le chiamate prendono in input (per fase 1 e 3 anche output) la seguente struttura jolie: type OAuth1Pair : void {. name : s t r i n g. value : s t r i n g } type OAuth1Info : void {. l o c a t i o n r e q u e s t : s t r i n g. l o c a t i o n a u t h o r i z e : s t r i n g. l o c a t i o n a c c e s s : s t r i n g. method : s t r i n g. c a l l b a c k? : s t r i n g. realm? : s t r i n g. consumer key : s t r i n g. s e c r e t? : s t r i n g. token? : s t r i n g. t o k e n s e c r e t? : s t r i n g. v e r i f i e r? : s t r i n g // HTTP a d d i t i o n a l user s p e c i f i e d parameters. headers : OAuth1Pair. query : OAuth1Pair } che comprende tutti i parametri necessari e opzionali per OAuth1, più parametri opzionali per le richieste HTTP nel caso siano richiesti da altri provider.

17 3.1. La libreria OAuth2 L implementazione di OAuth2 è un po più complicata a causa della flessibilità del framework OAuth2: Le seguenti chiamate sono accessibili: acgauth : Metodo Authorization Code Grant, prima fase: autorizzazione applicazione e token temporanei. ritorna il referral per l utente. acgaccess :Terza fase dell autenticazione, dopo che l utente si è autenticato. ottiene i token finali. implicitgrant :Metodo Authorization Code Grant, autentichiamo solo l utente. ritorna un referral per l utente, nel redirect troviamo i token. il redirect è parsabile con la chiamata parseanswer. passwordgrant : Metodo Password Grant, dopo una prima chiamata a acgauth possiamo usare questo metodo per autenticare l applicazione direttamente con l user e password dell utente. clientcredentialgrant :Metodo Client Credentials Grant, autentichiamo solo l applicazione. Da usare dopo una prima chiamata a acgauth, senza dare alcun referral all utente. extensiongrant : Metodo Extension Grant, è necessario fornire un elemento extension- Grant in input, l output sono i dati d autenticazione parseanswer : parsing della risposta alla chiamata implicitgrant. ritorna la struttura di base con le informazioni aggiornate. refresh : refresh del token d accesso. da usare allo scadere del token d autenticazione.

18 14 Implementazione Tutte le chiamate hanno come input/output la seguente struttura jolie: type HTTPJson : s t r i n g {. value? : any. c h i l d : HTTPJson } type OAuth2Pair : void {. name : s t r i n g. value : s t r i n g } type OAuth2Info : void {. l o c a t i o n a u t h o r i z e : s t r i n g. l o c a t i o n a c c e s s : s t r i n g. method : s t r i n g. c l i e n t i d : s t r i n g. c l i e n t s e c r e t : s t r i n g. code? : s t r i n g. r e d i r e c t u r i? : s t r i n g. scope? : s t r i n g. s t a t e? : s t r i n g. extensiongrant? : s t r i n g. a c c e s s t o k e n? : s t r i n g. token type? : s t r i n g. r e f r e s h t o k e n? : s t r i n g. e x p i r e s i n? : i n t // HTTP a d d i t i o n a l user s p e c i f i e d parameters. json? : HTTPJson. headers? : OAuth2Pair. query? : OAuth2Pair }

19 Chapter 4 Conclusioni 4.1 Jolie Jolie e la programmazione service-oriented sono interessanti, nonostante il linguaggio soffra di mancanze per lo più dovute alla scarsa diffusione. La programmazione service-oriented in jolie potrebbe essere ancora più interessante se affiancata a concetti di hot-reloading del codice in stile erlang. L uso fatto da Jolie di questo stile di programmazione riguarda soprattutto la semplificazione della comunicazione tra processi, ed effettivamente rende la programmazione semplice, una volta raccolte tutte le informazioni riguardanti il linguaggio. Ciò di cui si sente di più la mancanza in Jolie non è l uso di operatori come += o l avere una maggiore collezione di primitive per specifici problemi, ma è la documentazione: sul sito si trovano pochi esempi utili nella programmazione reale, per lo più frammentari, la differenza fre file di header.iol e file di codice.ol non è chiarita, e spesso è più utile controllare i sorgenti java di Jolie per capire il funzionamento di una interfaccia che non consultare la documentazione sul sito (vedi uso del protocollo HTTP). L aspetto peggiore del linguaggio oltre alla documentazione è lo stato del parser: il programmatore non deve vedere tutti gli errori interni del parser, ma solo una rappresentazione finale, di poche righe, non stacktrace interni al parser o all interprete, che rendono molto difficile il debugging, facendo perdere più tempo a decifrare l errore che non a correggerlo. 4.2 OAuth Essendo un protocollo molto ad alto livello (livello 5 nella pila ISO/OSI), non è definibile efficente a livello di quantità di dati trasmessi. Il vantaggio di questo protocollo riguarda la gestione dell autorizzazione dell utente oltre all autenticazione, e la sua relativa facilità d implementazione. L implementazione è resa più facile poichè non è necessario usare primitive di comunicazione a basso livello, non si lavora con messaggi parziali o errori di trasmissione, anche se questo aumenta il numero di protocolli dai quali un applicazione deve dipendere (Nel nostro caso: SSL/TLS, HTTP sia client che server). In particolare per quanto possa essere semplice usare il protocollo HTTP, richiedere ad un applicazione di incorporare un web server solo per poter gestire i redirect necessari al protocollo può decisamente appesantire l applicazione. 15

20 16 Conclusioni Fortunatamente il protocollo HTTP è ampiamente diffuso, e le implementazioni server minimali esistono per ogni client, e sono già preseni in Jolie. La odierna tendenza a rendere tutte le applicazioni disponibili via web rende questo protocollo in linea con lo stile di sviluppo generale, ma la sua esagerata flessibilità può complicarne l implementazione per la creazione di librerie generiche. Infine, la totale incompatiilità dell implementazione per un provider con l implementazione di un altro provider lo rendono uno scarso candidato per un protocollo d autenticazione generico come ad esempio openid

Protocolli di autenticazione ione per la connessione alle reti sociali. Le tecnologie del Web 2.0

Protocolli di autenticazione ione per la connessione alle reti sociali. Le tecnologie del Web 2.0 Protocolli di autenticazione ione per la connessione alle reti sociali Le tecnologie del Web 2.0 OAuth: cos è Semplice standard aperto per l autenticazione sicura delle API Protocollo aperto per permettere

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

Il Protocollo HTTP e la programmazione di estensioni Web

Il Protocollo HTTP e la programmazione di estensioni Web Il Protocollo HTTP e la programmazione di estensioni Web 1 Il protocollo HTTP È il protocollo standard inizialmente ramite il quale i server Web rispondono alle richieste dei client (prevalentemente browser);

Dettagli

Università degli studi di Perugia

Università degli studi di Perugia Università degli studi di Perugia Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di Laurea in Informatica Il protocollo OAuth STUDENTI PROFESSORE Luca Mancini Riccardo Queri Stefano Bistarelli

Dettagli

Il Paradigma REST per lo sviluppo di applicazioni Web 2.0

Il Paradigma REST per lo sviluppo di applicazioni Web 2.0 tesi di laurea Anno Accademico 2006/2007 Il Paradigma REST per lo sviluppo di applicazioni Web 2.0 relatore Ch.mo prof. Domenico Cotroneo correlatore Ing. Marcello Cinque candidato Antonio Alonzi Matr.

Dettagli

31/05/2013. Sistemi Web Distribuiti (parte 2) - Indice dei Contenuti - Naming. Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano

31/05/2013. Sistemi Web Distribuiti (parte 2) - Indice dei Contenuti - Naming. Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano /28 Sistemi Web Distribuiti (parte 2) - Indice dei Contenuti - Naming 3 Sincronizzazione 4 Consistenza e Replica 5 Replica di sistemi

Dettagli

DATABASE IN RETE E PROGRAMMAZIONE LATO SERVER

DATABASE IN RETE E PROGRAMMAZIONE LATO SERVER DATABASE IN RETE E PROGRAMMAZIONE LATO SERVER L architettura CLIENT SERVER è l architettura standard dei sistemi di rete, dove i computer detti SERVER forniscono servizi, e computer detti CLIENT, richiedono

Dettagli

Vallarino Simone. Corso di sicurezza A.A. 2003/2004 HTTPS

Vallarino Simone. Corso di sicurezza A.A. 2003/2004 HTTPS Vallarino Simone Corso di sicurezza A.A. 2003/2004 HTTPS INTRODUZIONE Per cominciare a parlare di https è necessario aprire la discussione ricordando le caratteristiche dell http: HTTP Nel sistema telematico

Dettagli

Esercitazione 8. Basi di dati e web

Esercitazione 8. Basi di dati e web Esercitazione 8 Basi di dati e web Rev. 1 Basi di dati - prof. Silvio Salza - a.a. 2014-2015 E8-1 Basi di dati e web Una modalità tipica di accesso alle basi di dati è tramite interfacce web Esiste una

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

Fermo!Point API. Guida all integrazione. Versione RedirectAPI: 1.0 Versione AsyncAPI: 0.9 Ultimo aggiornamento: 20-10-2014

Fermo!Point API. Guida all integrazione. Versione RedirectAPI: 1.0 Versione AsyncAPI: 0.9 Ultimo aggiornamento: 20-10-2014 Fermo!Point API Guida all integrazione Versione RedirectAPI: 1.0 Versione AsyncAPI: 0.9 Ultimo aggiornamento: 20-10-2014 Autore: Oscar Locatelli, Coriweb Srl Committente: Fermopoint Srl Sommario Introduzione

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

La sicurezza nelle comunicazioni Internet

La sicurezza nelle comunicazioni Internet Accesso remoto sicuro a intranet e a server aziendali di posta elettronica Un esempio Cosa ci si deve aspettare di sapere alla fine del corso La sicurezza nelle comunicazioni Internet Esiste un conflitto

Dettagli

Whoami. Luca Fulchir, Magistrale Informatica qui a Udine, Sistemista, esperto in sicurezza, reti. Presidente AsCI, organizzatore OSD.

Whoami. Luca Fulchir, Magistrale Informatica qui a Udine, Sistemista, esperto in sicurezza, reti. Presidente AsCI, organizzatore OSD. Fenrir Whoami Luca Fulchir, Magistrale Informatica qui a Udine, Sistemista, esperto in sicurezza, reti. Presidente AsCI, organizzatore OSD. Fenrir Authentication, Encryption & Transport protocol http://fenrirproject.org

Dettagli

12.5 UDP (User Datagram Protocol)

12.5 UDP (User Datagram Protocol) CAPITOLO 12. SUITE DI PROTOCOLLI TCP/IP 88 12.5 UDP (User Datagram Protocol) L UDP (User Datagram Protocol) é uno dei due protocolli del livello di trasporto. Come l IP, é un protocollo inaffidabile, che

Dettagli

Indice generale. Parte I Anatomia del Web...21. Introduzione...xiii

Indice generale. Parte I Anatomia del Web...21. Introduzione...xiii Indice generale Introduzione...xiii Capitolo 1 La sicurezza nel mondo delle applicazioni web...1 La sicurezza delle informazioni in sintesi... 1 Primi approcci con le soluzioni formali... 2 Introduzione

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

SETEFI. Marco Cantarini, Daniele Maccauro, Domenico Marzolla. 19 Aprile 2012

SETEFI. Marco Cantarini, Daniele Maccauro, Domenico Marzolla. 19 Aprile 2012 e VIRTUALCARD 19 Aprile 2012 e VIRTUALCARD Introduzione Il nostro obiettivo é quello di illustrare la struttura e le caratteristiche di fondo che stanno alla base delle transazioni online operate tramite

Dettagli

SSL: applicazioni telematiche SSL SSL SSL. E-commerce Trading on-line Internet banking... Secure Socket Layer

SSL: applicazioni telematiche SSL SSL SSL. E-commerce Trading on-line Internet banking... Secure Socket Layer : applicazioni telematiche Secure Socket Layer E-commerce Trading on-line Internet banking... Protocollo proposto dalla Netscape Communications Corporation Garantisce confidenzialità e affidabilità delle

Dettagli

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Giampiero Allamprese 0000260193 PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Reti di Calcolatori LS prof. Antonio Corradi A.A. 2007/2008 ABSTRACT L obiettivo di questo progetto è la realizzazione

Dettagli

Nicolò Carandini HTTP, Web Services e RestSharp (II parte) 1

Nicolò Carandini HTTP, Web Services e RestSharp (II parte) 1 Nicolò Carandini HTTP, Web Services e RestSharp (II parte) 1 HTTP, Web Services e RestSharp Dopo aver descritto nella prima parte di quest articolo 1 le basi su cui poggia la comunicazione nel Word Wide

Dettagli

Linguaggio C. Fondamenti. Struttura di un programma.

Linguaggio C. Fondamenti. Struttura di un programma. Linguaggio C Fondamenti. Struttura di un programma. 1 La storia del Linguaggio C La nascita del linguaggio C fu dovuta all esigenza di disporre di un Linguaggio ad alto livello adatto alla realizzazione

Dettagli

Come funziona internet

Come funziona internet Come funziona internet Architettura client server URL/URI Richiesta (Request) Risposta (Response) Pagina url e uri Uno Uniform Resource Identifier (URI, acronimo più generico rispetto ad "URL") è una stringa

Dettagli

APPENDICE. Procedure in SQL (1)

APPENDICE. Procedure in SQL (1) APPENDICE Procedure in SQL Transazioni in SQL Embedded SQL Remote Procedure Call Appendice 1 Procedure in SQL (1) Standard SQL2 permette di definire procedure, associate a singoli comandi SQL, memorizzate

Dettagli

Seminario di Sistemi Distribuiti RPC su SOAP

Seminario di Sistemi Distribuiti RPC su SOAP Seminario di Sistemi Distribuiti RPC su SOAP Massimiliano Vivian [777775] Massimiliano Vivian 1 Introduzione La comunicazione delle informazioni è l elemento fondamentale per lo sviluppo dei sistemi. SOAP

Dettagli

PROGETTI DISPONIBILI IL CORSO DI PROGETTO DI RETI E SISTEMI INFORMATICI

PROGETTI DISPONIBILI IL CORSO DI PROGETTO DI RETI E SISTEMI INFORMATICI PROGETTI DISPONIBILI IL CORSO DI PROGETTO DI RETI E SISTEMI INFORMATICI 1 Web Link Monitor... 2 2 Database Browser... 4 3 Network Monitor... 5 4 Ghost Site... 7 5 Copy Search... 9 6 Remote Audio Video

Dettagli

13 - Gestione della Memoria nella Programmazione Orientata agli Oggetti

13 - Gestione della Memoria nella Programmazione Orientata agli Oggetti 13 - Gestione della Memoria nella Programmazione Orientata agli Oggetti Programmazione e analisi di dati Modulo A: Programmazione in Java Paolo Milazzo Dipartimento di Informatica, Università di Pisa http://www.di.unipi.it/

Dettagli

Seminari Eucip, Esercizio e Supporto di Sistemi Informativi

Seminari Eucip, Esercizio e Supporto di Sistemi Informativi Seminari Eucip, Esercizio e Supporto di Sistemi Informativi Servizi di Dipartimento di Informtica e Sistemistica Università di Roma La Sapienza Sicurezza su Sicurezza della La Globale La rete è inerentemente

Dettagli

Sicurezza delle applicazioni di rete

Sicurezza delle applicazioni di rete Sicurezza delle applicazioni di rete Antonio Lioy < lioy @ polito.it > Politecnico di Torino Dip. Automatica e Informatica Sicurezza di canale autenticazione (singola o mutua), integrità e segretezza solo

Dettagli

Progetto Febbraio 2013 - Appello 1: Diffusione di tweets sul grafo di Twitter

Progetto Febbraio 2013 - Appello 1: Diffusione di tweets sul grafo di Twitter UNIVERSITÀ DEGLI STUDI DI MILANO, DIPARTIMENTO DI INFORMATICA LAUREA TRIENNALE IN COMUNICAZIONE DIGITALE CORSO DI RETI DI CALCOLATORI ANNO ACCADEMICO 2011/2012 Progetto Febbraio 2013 - Appello 1: Diffusione

Dettagli

Capitolo 7. Sviluppi futuri. 7.1 Generazione automatica di pagine WML

Capitolo 7. Sviluppi futuri. 7.1 Generazione automatica di pagine WML Capitolo 7 Sviluppi futuri 7.1 Generazione automatica di pagine WML Con l avvento della tecnologia WAP/WML abbiamo constatato la necessità di avere a disposizione uno strumento che consenta, così come

Dettagli

Protocolli di rete. Vittorio Maniezzo Università di Bologna. Vittorio Maniezzo Università di Bologna 02 Protocolli - 2/30

Protocolli di rete. Vittorio Maniezzo Università di Bologna. Vittorio Maniezzo Università di Bologna 02 Protocolli - 2/30 Protocolli di rete Vittorio Maniezzo Università di Bologna Vittorio Maniezzo Università di Bologna 02 Protocolli - 1/30 Strati di protocolli (Protocol Layers) Le reti sono complesse Molti elementi: host

Dettagli

Configurazione di sicurezza di XAMPP

Configurazione di sicurezza di XAMPP Configurazione di sicurezza di XAMPP Andrea Atzeni (shocked@polito.it) Marco Vallini (marco.vallini@polito.it) Politecnico di Torino Dip. Automatica e Informatica Siti web sicuri alcuni siti web possono

Dettagli

Indice. Introduzione. PARTE PRIMA PHP: i fondamenti 1

Indice. Introduzione. PARTE PRIMA PHP: i fondamenti 1 Indice Introduzione XV PARTE PRIMA PHP: i fondamenti 1 Capitolo 1 Perché PHP e MySQL? 3 1.1 Cos è PHP? 3 1.2 Cos è MySQL? 4 1.3 La storia di PHP 5 1.4 La storia di MySQL 6 1.5 Le ragioni per amare PHP

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 Lab 8 Visti i problemi con la macchina virtuale e la rete, l assignment è sospeso 1 Autenticazione

Dettagli

Programmazione Java Avanzata

Programmazione Java Avanzata Programmazione Java Avanzata Accesso ai Dati Ing. Giuseppe D'Aquì Testi Consigliati Eclipse In Action Core J2EE Patterns - DAO [http://java.sun.com/blueprints/corej2eepatterns/patterns/dataaccessobject.html]

Dettagli

I Principali Servizi del Protocollo Applicativo

I Principali Servizi del Protocollo Applicativo 1 I Principali Servizi del Protocollo Applicativo Servizi offerti In questa lezione verranno esaminati i seguenti servizi: FTP DNS HTTP 2 3 File Transfer Protocol Il trasferimento di file consente la trasmissione

Dettagli

Lezione 5: Socket SSL/ TLS. Corso di Programmazione in Rete Laurea Magistrale in Ing. Informatica Università degli Studi di Salerno

Lezione 5: Socket SSL/ TLS. Corso di Programmazione in Rete Laurea Magistrale in Ing. Informatica Università degli Studi di Salerno Lezione 5: Socket SSL/ TLS Corso di Programmazione in Rete Laurea Magistrale in Ing. Informatica Università degli Studi di Salerno 1 Outline Introduzione Gestione delle chiavi e dei certificati Comunicazione

Dettagli

FORSETI BLOG. Readcast. Aprile 2014 Speciale Heartbleed. http://blog.forseti.it/

FORSETI BLOG. Readcast. Aprile 2014 Speciale Heartbleed. http://blog.forseti.it/ FORSETI BLOG Readcast Aprile 2014 Speciale Heartbleed http://blog.forseti.it/ Indice di 3 Forseti Blog - Aprile 2014 3 di Dottore in Sicurezza dei Sistemi e delle Reti Informatiche, Dottore Magistrale

Dettagli

Programmazione in Java (I modulo) Lezione 3: Prime nozioni

Programmazione in Java (I modulo) Lezione 3: Prime nozioni Programmazione in Java (I modulo) Lezione 3: Prime nozioni La volta scorsa Abbiamo avuto un primo assaggio! Abbiamo visto come usare l editor per scrivere un programma Java. Abbiamo analizzato riga per

Dettagli

Esercitazione sulle libpq - libreria C per PostgreSQL

Esercitazione sulle libpq - libreria C per PostgreSQL Esercitazione sulle libpq - libreria C per PostgreSQL Roberto Tronci roberto.tronci@diee.unica.it Basi di Dati A.A. 2007/2008 Tronci ( roberto.tronci@diee.unica.it ) Esercitazione libpq Basi di Dati 2007/2008

Dettagli

Introduzione al linguaggio Java: Servlet e JSP

Introduzione al linguaggio Java: Servlet e JSP Introduzione al linguaggio Java: Servlet e JSP Corso di Gestione della Conoscenza d Impresa A. A. 2006/2007 Dipartimento di Informatica Università degli Studi di Bari 1 Servlet e JSP: il contesto Un applicazione

Dettagli

Architetture Web parte 2

Architetture Web parte 2 Architetture Web parte 2 Programmazione in Ambienti Distribuiti A.A. 2004-05 Sessione Un insieme di richieste, provenienti dallo stesso browser e dirette allo stesso server, confinate in un dato lasso

Dettagli

Tecnologie Web L-A. Java e HTTP. Dario Bottazzi Tel. 051 2093541, E-Mail: dario.bottazzi@unibo.it, SkypeID: dariobottazzi. Java e TCP/IP in a Nutshell

Tecnologie Web L-A. Java e HTTP. Dario Bottazzi Tel. 051 2093541, E-Mail: dario.bottazzi@unibo.it, SkypeID: dariobottazzi. Java e TCP/IP in a Nutshell Tecnologie Web L-A Java e HTTP Dario Bottazzi Tel. 051 2093541, E-Mail: dario.bottazzi@unibo.it, SkypeID: dariobottazzi Java e TCP/IP in a Nutshell! java.net.inetaddress: rappresenta un indirizzo IP e

Dettagli

Servizio Sistemi Informativi SPERIMENTAZIONE DI RETI PRIVATE VIRTUALI CON L'UTILIZZO DI SOFTWARE OPEN SOURCE

Servizio Sistemi Informativi SPERIMENTAZIONE DI RETI PRIVATE VIRTUALI CON L'UTILIZZO DI SOFTWARE OPEN SOURCE Servizio Sistemi Informativi SPERIMENTAZIONE DI RETI PRIVATE VIRTUALI CON L'UTILIZZO DI SOFTWARE OPEN SOURCE Redatto: Nucleo Gestione Innovazione e fornitori IT Versione: 1.0 Data emissione: 9/11/2006

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

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL STRUTTURA DEI SISTEMI OPERATIVI 3.1 Struttura dei Componenti Servizi di un sistema operativo System Call Programmi di sistema Struttura del sistema operativo Macchine virtuali Progettazione e Realizzazione

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

JavaServer Pages: Introduzione

JavaServer Pages: Introduzione JavaServer Pages: Introduzione Gianluca Moro gianluca.moro@unibo.it Dipartimento di Elettronica, Informatica e Sistemistica Università di Bologna Sistemi reali in JSP!! ofoto.com: stampa e gestisce foto

Dettagli

Cohesion Sign - Applet firma

Cohesion Sign - Applet firma Cohesion Sign - Applet firma Al fine di supportare le funzionalità di firma per tutte le carte contenenti certificati validi a tal scopo, si è reso necessario riscrivere completamente l applet originale

Dettagli

14 - Packages. Programmazione e analisi di dati Modulo A: Programmazione in Java. Paolo Milazzo

14 - Packages. Programmazione e analisi di dati Modulo A: Programmazione in Java. Paolo Milazzo 14 - Packages Programmazione e analisi di dati Modulo A: Programmazione in Java Paolo Milazzo Dipartimento di Informatica, Università di Pisa http://www.di.unipi.it/ milazzo milazzo di.unipi.it Corso di

Dettagli

Laboratorio di RETI DI CALCOLATORI

Laboratorio di RETI DI CALCOLATORI Laboratorio di RETI DI CALCOLATORI A.A. 2009-2010 I WEB SERVICES Carlo Mastroianni Laboratorio di Reti di Calcolatori - Orario lunedì, 11:30-13:30, aula 40B mercoledì, 10:00-11:30, laboratorio settimo

Dettagli

Servizi web in LabVIEW

Servizi web in LabVIEW Servizi web in LabVIEW Soluzioni possibili, come si utilizzano. 1 Soluzioni possibili WEB SERVER Dalla versione 5.1 di LabVIEW è possibile implementare un Web server che consente di operare da remoto sul

Dettagli

Oreste Signore, Responsabile Ufficio Italiano W3C Area della Ricerca CNR - via Moruzzi, 1-56124 Pisa

Oreste Signore, <oreste@w3.org> Responsabile Ufficio Italiano W3C Area della Ricerca CNR - via Moruzzi, 1-56124 Pisa http://www.w3c.it/education/2012/upra/basicinternet/#(1) 1 of 16 Oreste Signore, Responsabile Ufficio Italiano W3C Area della Ricerca CNR - via Moruzzi, 1-56124 Pisa Master in Comunicazione

Dettagli

Programmazione di sistemi distribuiti

Programmazione di sistemi distribuiti Programmazione di sistemi distribuiti I Sistemi Distribuiti, per loro natura, prevedono che computazioni differenti possano essere eseguite su VM differenti, possibilmente su host differenti, comunicanti

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

Tecnologie di Sviluppo per il Web

Tecnologie di Sviluppo per il Web Tecnologie di Sviluppo per il Web Applicazioni Web J2EE Framework per il Modello 2 it.unibas.pinco versione 3.2 Questo lavoro è concesso in uso secondo i termini di una licenza Creative Commons (vedi ultima

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

Sistemi informativi e Telemedicina Anno Accademico 2008-2009 Prof. Mauro Giacomini

Sistemi informativi e Telemedicina Anno Accademico 2008-2009 Prof. Mauro Giacomini Sistemi informativi e Telemedicina Anno Accademico 2008-2009 Prof. Mauro Giacomini Concetti di base Tre funzioni fondamentali: Autenticazione: riceve le credenziali, le verifica presso un autorità, se

Dettagli

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14. Pietro Frasca. Parte II Lezione 5

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14. Pietro Frasca. Parte II Lezione 5 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14 Pietro Frasca Parte II Lezione 5 Martedì 18-03-2014 1 Livello di applicazione Architetture

Dettagli

LABORATORIO DI TELEMATICA

LABORATORIO DI TELEMATICA LABORATORIO DI TELEMATICA COGNOME: Ronchi NOME: Valerio NUMERO MATRICOLA: 41210 CORSO DI LAUREA: Ingegneria Informatica TEMA: Analisi del protocollo FTP File Transfer Protocol File Transfer Protocol (FTP)

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

Motore di riempimento DB (generatore dati per simulazione)

Motore di riempimento DB (generatore dati per simulazione) SISTEMI DISTRIBUITI prof. S.Pizzutilo Motore di riempimento DB (generatore dati per simulazione) Studente: Alessandro Balestrucci 617937 Corso di Laurea: Informatica Magistrale Dipartimento di Informatica

Dettagli

Corso di Laurea in Informatica Reti e Sicurezza Informatica

Corso di Laurea in Informatica Reti e Sicurezza Informatica Corso di Laurea in Informatica Reti e Sicurezza Informatica Esercitazione 6 Autenticazione in Tomcat per lo sviluppo di Web Service. In questo documento si presentano i meccanismi fondamentali che consentono

Dettagli

Come funziona il WWW. Architettura client-server. Web: client-server. Il protocollo

Come funziona il WWW. Architettura client-server. Web: client-server. Il protocollo Come funziona il WWW Il funzionamento del World Wide Web non differisce molto da quello delle altre applicazioni Internet Anche in questo caso il sistema si basa su una interazione tra un computer client

Dettagli

Sicurezza delle applicazioni di rete. Sicurezza di canale. Sicurezza di messaggio (o dei dati) Antonio Lioy - Politecnico di Torino (1995-2011) 1

Sicurezza delle applicazioni di rete. Sicurezza di canale. Sicurezza di messaggio (o dei dati) Antonio Lioy - Politecnico di Torino (1995-2011) 1 Sicurezza delle applicazioni di rete Antonio Lioy < lioy @ polito.it > Politecnico di Torino Dip. Automatica e Informatica Sicurezza di canale autenticazione (singola o mutua), integrità e segretezza solo

Dettagli

Oggetto: MASTER DI ALTA FORMAZIONE PROFESSIONALE IN PROGRAMMATORE JAVA PARTECIPAZIONE GRATUITA

Oggetto: MASTER DI ALTA FORMAZIONE PROFESSIONALE IN PROGRAMMATORE JAVA PARTECIPAZIONE GRATUITA Oggetto: MASTER DI ALTA FORMAZIONE PROFESSIONALE IN PROGRAMMATORE JAVA PARTECIPAZIONE GRATUITA Salerno Formazione, società operante nel settore della didattica, della formazione professionale e certificata

Dettagli

aggiunge del testo nella parte finale del tag, in questo caso la stringa da controllare.

aggiunge del testo nella parte finale del tag, in questo caso la stringa da controllare. Capitolo 6 jquery Negli ultimi anni è stata rilasciata una mole incalcolabile di framework JavaScript, più o meno completi, realizzati per supportare nel miglior modo possibile lo sviluppatore web aiutandolo

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

19. LA PROGRAMMAZIONE LATO SERVER

19. LA PROGRAMMAZIONE LATO SERVER 19. LA PROGRAMMAZIONE LATO SERVER Introduciamo uno pseudocodice lato server che chiameremo Pserv che utilizzeremo come al solito per introdurre le problematiche da affrontare, indipendentemente dagli specifici

Dettagli

Flavio De Paoli depaoli@disco.unimib.it

Flavio De Paoli depaoli@disco.unimib.it Flavio De Paoli depaoli@disco.unimib.it 1 Il web come architettura di riferimento Architettura di una applicazione web Tecnologie lato server: Script (PHP, Pyton, Perl), Servlet/JSP, ASP Tecnologie lato

Dettagli

Capitolo 1 - parte 1. Corso Reti ed Applicazioni Mauro Campanella

Capitolo 1 - parte 1. Corso Reti ed Applicazioni Mauro Campanella Capitolo 1 - parte 1 Corso Reti ed Applicazioni Mauro Campanella Precisazione Noi ci occuperemo solo della trasmissione di informazione in formato digitale. Un segnale analogico è basato su una variazione

Dettagli

ICT (Information and Communication Technology): ELEMENTI DI TECNOLOGIA

ICT (Information and Communication Technology): ELEMENTI DI TECNOLOGIA ICT (Information and Communication Technology): ELEMENTI DI TECNOLOGIA Obiettivo Richiamare quello che non si può non sapere Fare alcune precisazioni terminologiche IL COMPUTER La struttura, i componenti

Dettagli

Il.NET Framework. By Dario Maggiari. L architettura del.net Framework è riassunta, nel complesso, nella figura seguente:

Il.NET Framework. By Dario Maggiari. L architettura del.net Framework è riassunta, nel complesso, nella figura seguente: Il.NET Framework By Dario Maggiari L architettura del.net Framework è riassunta, nel complesso, nella figura seguente: Il cuore del.net Framework è costituito dal CLR (Common Language Runtime) che, secondo

Dettagli

Chiamate a Procedure Remote

Chiamate a Procedure Remote FACOLTA DI SCIENZE MATEMATICHE, FISICHE E NATURALI Corso di Laurea Magistrale in Informatica Corso di Sistemi Distribuiti Anno Accademico 2012/2013 Relazione sullo sviluppo di Chiamate a Procedure Remote

Dettagli

PHP: Hypertext Preprocessor

PHP: Hypertext Preprocessor Corso di Laurea Specialistica in Ingegneria Informatica Corso di Linguaggi e Tecnologie Web A. A. 2011 - PHP: Hypertext Preprocessor Caratteristiche avanzate Eufemia Tinelli 1 Contenuti PHP ad oggetti

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

15 - Packages. Programmazione e analisi di dati Modulo A: Programmazione in Java. Paolo Milazzo

15 - Packages. Programmazione e analisi di dati Modulo A: Programmazione in Java. Paolo Milazzo 15 - Packages Programmazione e analisi di dati Modulo A: Programmazione in Java Paolo Milazzo Dipartimento di Informatica, Università di Pisa http://www.di.unipi.it/ milazzo milazzo di.unipi.it Corso di

Dettagli

Guida Utente della PddConsole. Guida Utente della PddConsole

Guida Utente della PddConsole. Guida Utente della PddConsole Guida Utente della PddConsole i Guida Utente della PddConsole Guida Utente della PddConsole ii Copyright 2005-2015 Link.it srl Guida Utente della PddConsole iii Indice 1 Introduzione 1 2 I protocolli di

Dettagli

Guida Utente della PddConsole. Guida Utente della PddConsole

Guida Utente della PddConsole. Guida Utente della PddConsole Guida Utente della PddConsole i Guida Utente della PddConsole Guida Utente della PddConsole ii Copyright 2005-2014 Link.it srl Guida Utente della PddConsole iii Indice 1 Introduzione 1 2 I protocolli di

Dettagli

Appendice D. D. Web Services

Appendice D. D. Web Services D. D.1 : cosa sono I cosiddetti sono diventati uno degli argomenti più attuali nel panorama dello sviluppo in ambiente Internet. Posti al centro delle più recenti strategie di aziende del calibro di IBM,

Dettagli

Architetture Web Protocolli di Comunicazione

Architetture Web Protocolli di Comunicazione Architetture Web Protocolli di Comunicazione Alessandro Martinelli alessandro.martinelli@unipv.it 10 Maggio 2011 Architetture Web Architetture Web Protocolli di Comunicazione Il Client Side Il Server Side

Dettagli

CORSO DI ALGORITMI E PROGRAMMAZIONE. JDBC Java DataBase Connectivity

CORSO DI ALGORITMI E PROGRAMMAZIONE. JDBC Java DataBase Connectivity CORSO DI ALGORITMI E PROGRAMMAZIONE JDBC Java DataBase Connectivity Anno Accademico 2002-2003 Accesso remoto al DB Istruzioni SQL Rete DataBase Utente Host client Server di DataBase Host server Accesso

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

Tecnologie e Programmazione Web

Tecnologie e Programmazione Web Presentazione 1 Tecnologie e Programmazione Web Html, JavaScript e PHP RgLUG Ragusa Linux Users Group SOftware LIbero RAgusa http://www.solira.org - Nunzio Brugaletta (ennebi) - Reti 2 Scopi di una rete

Dettagli

Vendere online. Andrea Marin. Università Ca Foscari Venezia SVILUPPO INTERCULTURALE DEI SISTEMI TURISTICI SISTEMI INFORMATIVI PER IL TURISMO

Vendere online. Andrea Marin. Università Ca Foscari Venezia SVILUPPO INTERCULTURALE DEI SISTEMI TURISTICI SISTEMI INFORMATIVI PER IL TURISMO Andrea Marin Università Ca Foscari Venezia SVILUPPO INTERCULTURALE DEI SISTEMI TURISTICI SISTEMI INFORMATIVI PER IL TURISMO a.a. 2013/2014 Section 1 Introduzione Parliamo di acquisti online quando a seguito

Dettagli

Tipi fondamentali di documenti web

Tipi fondamentali di documenti web Tipi fondamentali di documenti web Statici. File associati al web server il cui contenuto non cambia. Tutte le richieste di accesso conducano alla visualizzazione della stessa informazione. Dinamici. Non

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

La sicurezza nelle reti di calcolatori

La sicurezza nelle reti di calcolatori La sicurezza nelle reti di calcolatori Contenuti del corso La progettazione delle reti Il routing nelle reti IP Il collegamento agli Internet Service Provider e problematiche di sicurezza Analisi di traffico

Dettagli

Corso di Informatica. Prerequisiti. Modulo T3 B3 Programmazione lato server. Architettura client/server Conoscenze generali sui database

Corso di Informatica. Prerequisiti. Modulo T3 B3 Programmazione lato server. Architettura client/server Conoscenze generali sui database Corso di Informatica Modulo T3 B3 Programmazione lato server 1 Prerequisiti Architettura client/server Conoscenze generali sui database 2 1 Introduzione Lo scopo di questa Unità è descrivere gli strumenti

Dettagli

Reti basate sulla stack di protocolli TCP/IP

Reti basate sulla stack di protocolli TCP/IP Reti basate sulla stack di protocolli TCP/IP Classe V sez. E ITC Pacioli Catanzaro lido 1 Stack TCP/IP Modello TCP/IP e modello OSI Il livello internet corrisponde al livello rete del modello OSI, il suo

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

Eredità in C++ Corso di Linguaggi di Programmazione ad Oggetti 1. a cura di Giancarlo Cherchi

Eredità in C++ Corso di Linguaggi di Programmazione ad Oggetti 1. a cura di Giancarlo Cherchi Eredità in C++ Corso di Linguaggi di Programmazione ad Oggetti 1 a cura di Giancarlo Cherchi 1 Introduzione Il meccanismo dell eredità consente di sfruttare delle relazioni tipo/sottotipo, ereditando attributi

Dettagli

Sistemi Mobili e Wireless Android Introduzione alla piattaforma

Sistemi Mobili e Wireless Android Introduzione alla piattaforma Sistemi Mobili e Wireless Android Introduzione alla piattaforma Stefano Burigat Dipartimento di Matematica e Informatica Università di Udine www.dimi.uniud.it/burigat stefano.burigat@uniud.it Cos'è Android?

Dettagli

INFORMAZIONI GENERALI POSTA ELETTRONICA @CFPCOMO.COM

INFORMAZIONI GENERALI POSTA ELETTRONICA @CFPCOMO.COM Ogni utente del CFP Como è dotato di casella di posta elettronica. La forma delle caselle di posta elettronica è iniziale del nome_cognome@cfpcomo.com. Ad esempio s_moriani@cfpcomo.com. Il centro dispone

Dettagli

Architetture Applicative Il Web

Architetture Applicative Il Web Architetture Applicative Il Web Alessandro Martinelli alessandro.martinelli@unipv.it 18 Marzo 2014 Architetture Architetture Web L Architettura Client-Server HTTP Protocolli di Comunicazione Fondamenti

Dettagli

Sicurezza dei sistemi e delle reti 1. Lezione VI: IPsec. IPsec. La suite TCP/IP. Mattia Monga. a.a. 2014/15

Sicurezza dei sistemi e delle reti 1. Lezione VI: IPsec. IPsec. La suite TCP/IP. Mattia Monga. a.a. 2014/15 Sicurezza dei sistemi e delle 1 Mattia Lezione VI: Dip. di Informatica Università degli Studi di Milano, Italia mattia.monga@unimi.it a.a. 2014/15 1 cba 2011 15 M.. Creative Commons Attribuzione Condividi

Dettagli

Sistemi Operativi (modulo di Informatica II)

Sistemi Operativi (modulo di Informatica II) Sistemi Operativi (modulo di Informatica II) La comunicazione tra processi Patrizia Scandurra Università degli Studi di Bergamo a.a. 2008-09 Sommario Processi cooperanti La comunicazione tra processi Necessità

Dettagli