WebRTC per la realizzazione di uno strumento di videoconferenza aziendale
•Download as PPTX, PDF•
0 likes•97 views
Presentazione della mia tesi di laurea presso l'UNISA (Università degli Studi di Salerno) incentrata sullo studio della tecnologia WebRTC per la realizzazione di uno strumento aziendale di videoconferenza e file sharing. Altre tecnologie utilizzate: EasyRTC e Identity Provider.
Recommended
Recommended
More Related Content
Similar to WebRTC per la realizzazione di uno strumento di videoconferenza aziendale
Similar to WebRTC per la realizzazione di uno strumento di videoconferenza aziendale (20)
WebRTC per la realizzazione di uno strumento di videoconferenza aziendale
- 1. UNIVERSITÀ DEGLI STUDI DI SALERNO Dipartimento di Informatica TESI DI LAUREA IN INFORMATICA Studio della tecnologia WebRTC per la realizzazione di uno strumento di videoconferenza e file sharing Relatrice: Ch.ma Prof.ssa Filomena De Santis Candidato: Francesco Montanino Matr.: 0512101725
- 2. 4 Sviluppi futuri Identity Provider 3 2 Prototipo Tecnologie 1
- 3. WebRTC WebRTC (Web Real-Time Communication) è un recente standard open source appoggiato da W3C (World Wide Web Consortium) e IETF (Internet Engineering Task Force) che consente, ai browser che supportano HTML5, di comunicare in real-time utilizzando un’architettura peer to peer.
- 4. WebRTC: Signaling Architettura peer to peer ma… …c’è bisogno di un server Browser (Peer) WebRTC Application Browser (Peer) WebRTC Application Peer to peer communication (audio, video, data) Signaling Server
- 5. WebRTC: Sicurezza Browser (Peer) WebRTC Application Browser (Peer) WebRTC Application Peer to peer communication (audio, video, data) DTLS + SRTP Signaling Server Protocolli di sicurezza utilizzati per la condivisione dei dati: • DTLS (Datagram Transport Layer Security); • SRTP (Secure Real-Time Transport Protocol).
- 7. EasyRTC EasyRTC è una soluzione open- source, basata su WebRTC, che mette a disposizione dello sviluppatore una libreria client ed una server consentendo la creazione di una semplice applicazione di video- conferenza, chat e condivisione di file utilizzando poche righe di codice.
- 8. 4 Sviluppi futuri Identity Provider 3 2 Prototipo Tecnologie 1
- 9. Descrizione del prototipo Il prototipo sviluppato ha lo scopo di consentire la comunicazione in un contesto aziendale, fornendo uno strumento realizzato per funzionare all’interno della propria rete aziendale.
- 10. Modello architetturale Browser (Peer) WebRTC Application Code EasyRTC Server in Node.js EasyRTC Client Library Socket.io Browser (Peer) WebRTC Application Code EasyRTC Client Library Socket.io
- 11. Interfacce del sistema Pagina di Login Schermata di videoconferenza
- 12. 4 Sviluppi futuri Identity Provider 3 2 Prototipo Tecnologie 1
- 13. Identity Provider Identità verificate grazie all’utilizzo di Identity Provider.
- 14. Irrobustimenti di sicurezza Fase di autenticazione In questa fase i compiti principali dell’Identity Provider sono quelli di permettere all’utente l’autenticazione per consentire l’accesso alla room e di restituire all’applicazione un Access Token e le informazioni personali richieste (nome, cognome, email).
- 15. Richiesta di connessione In questa fase l’Identity Provider viene interpellato dal server per richiedere la verifica dell’Access Token dell’utente che ha richiesto una connessione. Irrobustimenti di sicurezza
- 16. 4 Sviluppi futuri Identity Provider 3 2 Prototipo Tecnologie 1
- 17. Integrazione di TURN e STUN Server STUN: fornisce un indirizzo pubblico, rendendo il peer visibile al di fuori della propria rete. Server TURN: possiede, a differenza di un server STUN, la funzionalità di trasmissione di uno stream. Alternative media traffic
Editor's Notes
- Salve sono Montanino Francesco, il mio lavoro di tesi, tenuto durante il periodo di tirocinio esterno presso l’azienda Kineton di Napoli, è incentrato sullo studio della tecnologia WebRTC e lo sviluppo di un prototipo aziendale di videoconferenza e file sharing.
- WebRTC è un recente standard open source che permette ai browser che supportano HTML5, di comunicare in real time utilizzando un’architettura peer to peer. Esso infatti consente lo scambio di uno stream audio-video e la condivisione di file direttamente attraverso i browser, i quali possono trovarsi su dispositivi completamente diversi.
- Questo sembra in contraddizione con quanto detto in precedenza ma per funzionare a pieno WebRTC ha bisogno di un server di signaling. Server di signaling che ha lo scopo di coordinare la comunicazione tra i peer coinvolti, come la gestione dell’avvio e la chiusura della comunicazione e l’invio di messaggi di controllo.
- WebRTC per garantire la sicurezza della comunicazione utilizza due protocolli: DTLS e SRTP. DTLS (Datagram Transport Layer Security) utilizzato per impedire l'intercettazione, la manomissione o la falsificazione dei messaggi [7]. SRTP (Secure Real-Time Transport Protocol) invece aggiunge alcune funzionalità di sicurezza, come l’autenticazione dei messaggi, la riservatezza e la protezione contro la riproduzione.
- WebRTC offre agli sviluppatori una semplice API Javascript basata su tre concetti fondamentali: MediaStream (o getUserMedia) RTCPeerConnection RTCDataChannel MediaStream permette al browser di richiedere agli utenti il consenso per l’acquisizione dello stream audio e video grazie al metodo getUserMedia(). RTCPeerConnection rappresenta il collegamento esistente tra i due peer e può essere utilizzata per inviare al corrispettivo peer connesso lo stream ricevuto da getUserMedia(). RTCDataChannel rappresenta un canale di comunicazione tra due peer per consentire lo scambio di dati generici.
- Tra le diverse soluzioni prese in considerazione per l’implementazione del prototipo, ma la più appropriata alle esigenze dell’azienda è risultata essere EasyRTC. La libreria per il client browser è scritta in Javascript e permette al client di comunicare col server per gestire il signaling dell’applicazione e crea uno strato software in grado di separare le applicazioni dagli eventuali cambiamenti in corso nelle API di WebRTC. La libreria server esposta invece è basata su Node.js.
- …esso permette la condivisione di uno stream audio/video, di messaggi e di file.
- Il prototipo realizzato, presenta la seguente architettura.
- In una comunicazione tra due utenti è indispensabile che ognuno dei due abbia la certezza di essere realmente in contatto con la persona che lui crede e che quindi non ci siano stati furti di identità. Questo significa che l’identità dei due peer deve essere verificata anche quando non è in corso la condivisione di uno stream video. Per risolvere questo problema, ci vengono in aiuto gli Identity Provider (IdP), ovvero dei servizi esterni (come Facebook, Google+, Twitter, eccetera) che permettono l’autenticazione al sito web, utilizzando però identità già create e verificate in precedenza all’interno dei social network.
- Identity Provider che vengono sfruttati in due fasi dell’utilizzo dell’applicazione web: durante la fase di autenticazione e ogni qualvolta viene richiesta una connessione. Nella fase di autenticazione il client utilizza l’Identity Provider per richiedere l’accesso ottenendo in questo modo un Access Token il quale verrà inviato, unitamente ai dati dell’utente al server. Il server andrà ad associare L’EasyRTCID, utile per individuare univocamente il peer sul server, all’Access Token e lo andrà a memorizzare in un file.
- Mentre durante una richiesta di connessione, l’applicativo del client richiederà al server la validazione dell’identità del peer che ha richiesto la connessione tramite l’Identity Provider. Nel caso in cui i parametri ritornati dall’Identity Provider coincidano con quelli memorizzati sul server, allora comparirà la richiesta di connessione sull’applicazione del client che l’ha ricevuta.
- Il protocollo ICE infatti per avviare una connessione tenta dapprima tutte le possibili connessioni dirette tra i due peer attraverso UDP, o TCP in caso di problemi, scegliendo la strada più efficiente. Nel caso in cui non fosse possibile si serve di una tipologia di server denominata STUN (Session Traversal Utilities for NAT) che ha il solo scopo di rendere il peer visibile al di fuori della rete grazie al fatto che offre un indirizzo e ad una relativa porta, entrambi pubblici. Nel caso in cui dovesse fallire anche questa soluzione, il traffico verrà indirizzato su di un server TURN (Traversal Using Relays around NAT). Un server TURN è un’estensione del server STUN, difatti esso possiede in aggiunta solo le funzionalità di trasmissione. In questo caso quindi lo stream verrebbe trasmesso attraverso i corrispondenti server TURN e non più direttamente tramite i due peer.