Università degli Studi di Padova - SIAGAS
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Università degli Studi di Padova
Dipartimento di Matematica "Tullio Levi-Civita"
Corso di Laurea in Informatica
Integrazione di servizi "Calendario Office 365"
via API per la pianificazione di eventi
Tesi di laurea triennale
Relatore
Prof. Gilberto Filè
Laureando
Alessandro Bari
Anno Accademico 2016-2017
Alessandro Bari: Integrazione di servizi "Calendario Office 365" via API per la pianificazione di eventi, Tesi di laurea triennale, c Settembre 2017.
Dedico questa tesi a mia nonna Lidia;
te ne sei andata prima di poter assistere alla mia laurea, ma ti sento ancora vicina.
Mi hai sempre spronato a dare il meglio per raggiungere questo traguardo ed eri
convinta che ci sarei riuscito. Finalmente posso dirti CE L’HO FATTA ...
Alessandro
Sommario
Il presente documento descrive il lavoro svolto durante il periodo di stage, della
durata di circa trecento ore, dal laureando Alessandro Bari presso l’azienda Wintech
S.p.A. Gli obbiettivi da raggiungere erano:
• L’analisi delle peculiarità e delle funzonalità di WOW al fine di comprendere
meglio questa piattaforma;
• Studio delle tecnologie utilizzate e dell’ambiente di lavoro;
• Studio delle API di Office365 necessarie allo sviluppo dei servizi;
• Definizione delle specifiche dei servizi, della loro Governance e delle Policy ad
essi applicate;
• Implementazione di una autorizzazione lato back-end server-to-server;
• Gestione eventi sul calendario Office 365 (aggiunta, cancellazione, modifica),
sempre lato server.
v“I computer sono inutili. Ti danno solo risposte”
— Pablo Picasso
Ringraziamenti
Innanzitutto, vorrei esprimere la mia gratitudine al Prof. Gilberto Filè, relatore della
mia tesi, per l’aiuto e il sostegno fornitomi durante la stesura del lavoro.
Ringrazio il mio tutor aziendale, Enrico Merigliano, per la disponibilità sempre avuta
con me e l’azienda Wintech per avermi fatto sentire subito parte di essa.
Ringrazio la mia famiglia per il sostegno e il grande aiuto datomi durante questi anni
di studio.
Ringrazio poi tutti i miei amici per tutti i bellissimi anni passati insieme e le mille
avventure vissute!
Infine ringrazio, per l’aiuto ricevuto, tutti i componenti del gruppo Answer e gli altri
amici conosciuti all’università, con i quali ho condiviso anni di grande impegno e
difficoltà.
Padova, Settembre 2017 Alessandro Bari
viiIndice
1 Introduzione 1
1.1 Organizzazione del documento e del testo . . . . . . . . . . . . . . . 1
1.2 L’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.1 Storia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.2 Certificazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.3 Servizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.4 World Of Wintech . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 TdB: Il CRM aziendale . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Assistenza e ticketing . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 GeCo: strumento di consuntivazione . . . . . . . . . . . . . . . . . . 7
1.6 La necessità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.7 Microsoft Office 365 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7.1 Microsoft Outlook Calendar . . . . . . . . . . . . . . . . . . . 8
2 Il progetto di stage 11
2.1 Descrizione del progetto . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Obiettivi dello stage . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 Obiettivi obbligatori . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Obiettivi desiderabili . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Vincoli tecnologici . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Pianificazione del lavoro . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Microsoft Graph, Azure AD e OAuth 2.0 15
3.1 Microsoft Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1 Cosa si può fare con Graph? . . . . . . . . . . . . . . . . . . . 16
3.2 Azure AD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Autorizzazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.1 OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4 Tecnologie utilizzate 23
4.1 Linguaggio di programmazione utilizzato . . . . . . . . . . . . . . . . 23
4.1.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Strumenti di supporto . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.1 Apache Maven . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Ambiente di sviluppo e versionamento . . . . . . . . . . . . . . . . . 27
4.3.1 IntelliJ IDEA . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.2 Subversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
ixx INDICE
5 Progettazione e codifica 29
5.1 Impostazione del progetto . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1.1 Microsoft Azure Portal . . . . . . . . . . . . . . . . . . . . . . 29
5.2 Codifica dei servizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2.1 Autenticazione server-to-server . . . . . . . . . . . . . . . . . 33
5.2.2 Servizi realizzati . . . . . . . . . . . . . . . . . . . . . . . . . 36
6 Qualifica 39
6.1 Verifica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.1.1 Analisi statica . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.1.2 Analisi dinamica . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.1.3 Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.2 Validazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.2.1 Validazione interna . . . . . . . . . . . . . . . . . . . . . . . . 42
6.2.2 Validazione esterna . . . . . . . . . . . . . . . . . . . . . . . . 42
7 Conclusioni 43
7.1 Raggiungimento degli obiettivi . . . . . . . . . . . . . . . . . . . . . 43
7.2 Conoscenze acquisite . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.3 Futuri sviluppi ed integrazioni del progetto di stage . . . . . . . . . . 44
7.4 Valutazione personale . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Glossario 47
Bibliografia 57Elenco delle figure
1.1 Wintech S.p.A. - Logo ufficale dell’azienda . . . . . . . . . . . . . . . 2
1.2 Gestione informazioni in Wintech secondo UNI ISO 27001:2014 . . . 3
1.3 TdB - CRM aziendale in Wintech . . . . . . . . . . . . . . . . . . . . 6
1.4 GeCo - Schermata per la creazione di un’attività . . . . . . . . . . . 7
3.1 Graph - Struttura delle relazioni tra servizi . . . . . . . . . . . . . . 15
3.2 Azure - Logo ufficiale . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 OAuth 2.0 - Logo ufficiale . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4 OAuth 2.0 - Authorize request . . . . . . . . . . . . . . . . . . . . . 19
3.5 OAuth 2.0 - Access Token request . . . . . . . . . . . . . . . . . . . . 20
4.1 Java - Logo ufficiale . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Apache Maven - Logo ufficiale . . . . . . . . . . . . . . . . . . . . . . 25
4.3 IntelliJ IDEA - Logo ufficiale . . . . . . . . . . . . . . . . . . . . . . 27
4.4 Subversion - Logo ufficiale . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1 Microsoft Azure Portal - Homepage del portale . . . . . . . . . . . . 30
5.2 Microsoft Azure Portal - Autorizzazioni necessarie . . . . . . . . . . 31
5.3 Microsoft Azure Portal - Impostazione chiave privata . . . . . . . . . 32
5.4 it.wintech.Calendarutils - Package utilizzato per la demo aziendale . 36
Elenco delle tabelle
5.1 CalendarController - Metodi contenuti nella classe . . . . . . . . . 38
xiCAPITOLO 1
Introduzione
Questo capitolo introduce l’aziendale nella quale si è svolto lo stage parlando della sua
storia, dei prodotti ed i servizi che offre e dei vari applicativi attualmente in uso verso i
quali il progetto si appoggia.
Organizzazione del documento e del testo
Riguardo la gerarchia del documento, essa è così organizzata:
Il primo capitolo introduce al contesto aziendale, alla sua organizzazione ed ai
suoi obiettivi;
Il secondo capitolo approfondisce gli obiettivi, i vincoli e descrive la pianificazione
del progetto di stage;
Il terzo capitolo descrive l’analisi dell’ambiente Microsoft Graph, Azure AD e di
OAuth 2.0 a monte dello sviluppo;
Il quarto capitolo approfondisce le tecnologie e gli strumenti che sono stati adottati
per lo sviluppo del progetto;
Il quinto capitolo approfondisce la fase di progettazione e di codifica dei servizi
realizzati;
Il sesto capitolo descrive le metodologie adottate per la verifica e la validazione
dei prodotti sviluppati;
Il settimo capitolo conclude la relazione finale di stage dandone una propria
impressione personale.
Riguardo la stesura del testo, relativamente al documento, sono state adottate le
seguenti convenzioni tipografiche:
• Gli acronimi, le abbreviazioni e i termini ambigui o di uso non comune menzio-
nati vengono definiti nel glossario, situato alla fine del presente documento;
• Per la prima occorrenza dei termini riportati nel glossario viene utilizzata la
seguente nomenclatura: parola G .
12 CAPITOLO 1. INTRODUZIONE
L’azienda
figura 1.1: Wintech S.p.A. - Logo ufficale dell’azienda
Storia
Wintech S.p.A. è un’azienda che nasce nel 1987 come System IntegratorgG 7.4.
La sede centrale è a Padova con filiali a Milano e Bassano del Grappa ed una recente
unità operativa a Pordenone. Grazie alla propria esperienza, competenza e creatività,
Wintech trasforma le complessità tecnologiche in soluzioni informatiche innovative,
efficienti e dal facile utilizzo.
Wintech fornisce consulenza personalizzata, soluzioni applicative e tecnologiche in
ambito IT per ottimizzare i processi aziendali e raggiungere gli obiettivi definiti
assieme ai clienti.
L’azienda collabora con i principali produttori di soluzioni IT avendo competenze
specifiche in tutte le fasi necessarie al successo di un progetto.
Grazie all’esperienza maturata negli anni, essa vanta numerose partnership a livello
mondiale tra cui Microsoft, IBM ed HP.1.2. L’AZIENDA 3
Certificazioni
Il sistema di qualità di Wintech è stato certificato secondo la norma ISO 9001:2008
per le attività di:
• Progettazione, implementazione e fornitura di sistemi informativi integrati;
• Progettazione e sviluppo di soluzioni software;
• Erogazione di servizi di assistenza tecnica, sistematica e applicativa.
Riguardo i processi aziendali, Wintech ha di recente (2017) investito nella sicurezza
ottenendo certificazione UNI ISO 27001:2014 per i servizi sistemistici e di network
forniti in outsourcing, offrendo soluzioni ancora più complete ed affidabili ai propri
clienti.
Le colonne portanti di questa certificazione sono:
• Riservatezza (confidenzialità): informazioni accessibili esclusivamente alle
persone autorizzate;
• Integrità: dati e informazioni devono essere protette da modifiche non auto-
rizzate;
• Disponibilità: sistemi e applicazioni devono essere disponibili quando neces-
sario.
figura 1.2: Gestione informazioni in Wintech secondo UNI ISO 27001:2014
Servizi
L’azienda offre ai clienti servizi quali:
• Analisi e progettazione di soluzioni su misura. Ciò è possibile attraverso un
dialogo diretto mirato ad individuare i bisogni per la realizzazione di prodotti
capaci di soddisfare le aspettative del cliente;
• Installazione ed avviamento delle soluzioni;
• Formazione per l’uso delle applicazioni proposte;4 CAPITOLO 1. INTRODUZIONE
• Consulenza;
• Assistenza di tipo sistemistico, helpdeskG 7.4 o applicativo grazie all’ausilio di
software quali teamviewerG 7.4.
World Of Wintech
WoW è l’acronimo di World of Wintech, un portale web in sviluppo presso l’azienda
Wintech, che ha l’obiettivo di gestire al completo le funzionalità che ogni dipendente
dovrà affrontare nel lavoro di tutti i giorni. WoW sarà un portale dove ogni utente
avrà a disposizioni quello che cerca, sapendosi adattare alle esigenze di chi ci accede
in base alla mansione svolta. L’ambizione di questo progetto è quella di creare un
Digital Workplace aziendale. Sono stati delineati in principio i punti chiave di WoW:
• Profilare gli utenti in modo rigoroso;
• Gestire anagrafiche univoche;
• Creazione di un motore collaborativo veloce, contestuale e puntuale;
• Utilizzo di una grafica semplice e una user experience stimolante e allo stesso
tempo intuitiva.
Il portale consentirà quindi l’aggregazione di varie applicazioni, dati, contenuti e
persone mirando a rendere più agile, snello ed efficiente il lavoro quotidiano. Caratteri-
stiche essenziali sono la modularità, la flessibilità e scalabilità. All’accesso del portale
ogni utente potrà visualizzare la propria dashboard, personalizzata secondo le proprie
esigenze, che permetterà una gestione del profilo e dei servizi differenziata in base alla
tipologia d’utenza. Grazie all’approccio sociale del portale sarà possibile rimanere
costantemente aggiornati sulla realtà aziendale con la possibilità di visualizzare le
news dell’azienda e i compiti da eseguire giornalmente con tanto di commenti. Questa
linea porterà vari vantaggi come la diminuzione della quantità di posta elettronica
scambiata tra i componenti di Wintech e la contestualizzazione della comunicazione
tipica della realtà che possiamo vivere attraverso i social network. Attualmente WoW
è in fase di sviluppo e, come è stato accennato sopra, l’approccio modulare consente
l’integrazione di più applicazioni che possono essere sviluppate singolarmente da vari
team per poi essere integrate nella fase finale. Allo stato attuale sono in sviluppo i
seguenti moduli:
• News: permette di accedere alle novità che riguardano l’azienda;
• eSolver: è l’applicativo che contiene tutte le anagrafiche e comprende tutti gli
utenti dell’azienda, i clienti e i fornitori;
• Messaging: un applicativo che consente la comunicazione istantanea tra i vari
componenti;
• Dashboard Aziendale: una dashboard personalizzata volta a mostrare dati
rilevanti sull’azienda d’interesse per l’utente autenticato;
• Project Management: modulo di supporto ai Project Manager che consente la
gestione dei progetti in corso;1.2. L’AZIENDA 5
• Task Manager: modulo che consente di organizzare tutte le attività da svolgere
e visualizzare statistiche sul lavoro operato;
• Consuntivazione: applicativo che permette agli utenti di consuntivare in ore le
attività svolte durante la giornata;
• Profilo Utenti: gestione del profilo e visualizzazione dei profili altrui;
• Applicazioni: vista per l’accesso veloce alle applicazioni gestite;
• Piattaforma Informazione e Social Communities: modulo che consente l’in-
tegrazione con strumenti utilizzati dall’azienda come IBM Connections e la
piattaforma basata su Moodle.
Una volta sviluppato ed approvato il progetto di stage verrà incluso in WOW dando
forma al modulo di pianificazione impegni.6 CAPITOLO 1. INTRODUZIONE
TdB: Il CRM aziendale
Il concetto di CRM Customer Relationship Management è legato al concetto di
fidelizzazione dei clienti.
In un’impresa come Wintech il mercato è rappresentato dal cliente e da tutto ciò
che lo circonda, diventa quindi estremamente utile memorizzare in maniera ordinata
molti dati, sul cliente, ed averli sempre a portata di mano.
Attualmente Wintech utilizza un sistema CRM clientserverG 7.4, da loro stessi creato
ed utilizzato dal 1999, per la gestione ed il tracciamento delle relazioni con tutti i
loro clienti.
Il nome di questo sistema è TdB, acronimo di “Tableau de Bord”.
Questo sistema si è evoluto nel tempo diventando un punto di riferimento importante
per i dipendenti e fondamentale per organizzare e tenere traccia di tutte le relazioni
con i clienti, siano esse rappresentate da documenti fisici, da appuntamenti fissati
o dal semplice corpo di una mail in risposta ad un ordine, offerta, commessa o
quant’altro.
Con un CRM di questo tipo si ha la piena visibilità sulle attività del team di vendita,
report tempestivi sui progressi interni e canali di collaborazione tra i gruppi di lavoro.
figura 1.3: TdB - CRM aziendale in Wintech
Assistenza e ticketing
Wintech utilizza un portale per l’assistenza verso i clienti e il ticketing interno, in
questo modo vi è un maggiore controllo delle attività aperte (pianificazione) e di
quelle chiuse (consuntivazione).
Le motivazioni per le quali un’attività viene creata può essere interna, come la1.5. GECO: STRUMENTO DI CONSUNTIVAZIONE 7
richiesta di installazione di un software su una macchina aziendale, oppure può essere
conseguenza di una assistenza tecnica esterna ad un cliente, che deve essere tracciata
ed assegnata ad un responsabile interno, seguendo la logica di TdB.
GeCo: strumento di consuntivazione
GeCo è il software che permette ai dipendenti Wintech di effettuare consuntivazioni
sulle attività svolte. È uno strumento fondamentale per rendicontare le ore di attività
e tracciare lo sviluppo di ogni progetto. Ogni dipendente, prima del termine della
settimana lavorativa, deve registrare le proprie attività, rendendo così tracciabile il
proprio operato.
Come si nota dalla figura 1.4 relativa allo strumento, la pianificazione di un’ attività
può essere associata ad un ticket generato tramite il portale assistenza Wintech e
costituisce quindi un legame con un cliente.
Tali attività, alla chiusura, portano alla generazione di un rapportino in formato
PDF che rappresenta quindi un altro documento collegato agli acquirenti e quindi
da tracciare.
figura 1.4: GeCo - Schermata per la creazione di un’attività
La necessità
Il problema riscontrato da Wintech è che per la fase di pianificazione degli interventi
vengono usati più applicativi rendendo il procedimento non intuitivo, complesso e
lento. La soluzione pensata richiede un servizio da integrare in WOW, che si occupi
della pianificazione risolvendo i problemi attualmente riscontrabili nel procedimento.
Il servizio da realizzare deve seguire le caratteristiche fondamentali di WOW, cioè il
suo grado di automatismo e la sua semplicità di utizzo, in particolare questo servizio
deve risultare:8 CAPITOLO 1. INTRODUZIONE
• Veloce;
• Intuitivo;
• Estendibile;
• Portabile.
Queste caratteristiche hanno portato all’idea di presentare gli impegni pianificati in
un calendario per rendere il procedimento il più intuitivo possibile. La proposta di
realizzare ex novo un calendario è stata scartata per i tempi e i costi troppo elevati,
si è pensato quindi di utilizzare uno dei calendari più funzionali in commercio cioè
quello offerto da Microsoft Office 365 .
Microsoft Office 365
È un servizio offerto da Microsoft che consente di utilizzare online tutti i software
del pacchetto Office 2016, fra cui sono presenti: Outlook, un software di tipo
organizzativo per email, calendario e rubrica, il word processor Word, il foglio
elettronico Excel, PowerPoint per la creazione di presentazioni, oltre a tutti gli altri
software "classici" della suite. La logica di Office è passata da quella di prodotto
a quella di servizio, concedendo oltre all’insieme di applicativi sopra elencati dello
spazio di archiviazione su OneDrive, il servizio cloud di Microsoft, garantendo anche
il supporto multipiattaforma (PC, Mac, iOS e Android). I principali strumenti online
che compongono l’offerta di Office 365 sono:
• Exchange Online;
• SharePoint Online;
• Lync Online;
• Office Online.
Office 365 consente di utilizzare le applicazioni della suite anche in versione offline
in quanto questa viene installata quando si acquista il servizio, inoltre essendo un
servizio web, le applicazioni che lo compongono sono sempre aggiornate all’ultima
versione disponibile.
Microsoft Outlook Calendar
Microsoft Outlook è un programma Microsoft, facente parte della suite Microsoft
Office, che funge da PIMG 7.4 e da client di posta. Più precisamente contiene:
• Un calendario;
• Un’agenda delle attività;
• Le note;
• Il diario;1.7. MICROSOFT OFFICE 365 9
• Contatti (rubrica);
• Posta elettronica.
Il calendario offerto da Office 365 è simile ad un’agenda. Le funzionalità principali
offerte sono:
• Creazione di appuntamenti e riunioni e la possibilità di tenerne traccia;
• La gestione di più calendari alla volta;
• La condivisione dei calendari con altri utenti;
• Mail automatiche di invito generate alla creazione di una nuova lista invitati
ad un evento.CAPITOLO 2
Il progetto di stage
In questo capitolo viene descritto il progetto di stage definendone gli obiettivi da
raggiungere, i vincoli da rispettare e la pianificazione delle attività.
Descrizione del progetto
Il progetto di stage richiede di sviluppare un servizio applicativo che, tramite l’otteni-
mento di un’autorizzazione, gestisca la pianificazione degli impegni interni (riunioni,
rappresentazione dei ticket interni, ecc) o esterni (rapporto con i clienti). Come detto
in precedenza, secondo Wintech il modo più veloce e intuitivo per rappresentare
un impegno è inserirlo in un calendario, in particolare in un calendario Office 365
essendo questo molto funzionale e già conosciuto da molti dipendenti dell’azienda.
Seguendo questa logica il prodotto sviluppato durante il mio stage dovrà gestire
degli eventi in uno o più calendari Office 365 consentendo la pianificazione interna
ed esterna.
Il servizio realizzato verrà, una volta testato ed approvato, integrato in WOW in
modo da seguire la logica aziendale di fornire un unico applicativo in grado di erogare
molti servizi utili.
Il progetto di stage concordato con l’azienda si è svolto tramite un’analisi iniziale
della piattaforma aziendale WOW e degli strumenti interni attualmente in uso in
azienda. A seguito di uno studio approfondito delle APIG 7.4 di Office 365 è stata
decisa la modalità di sviluppo tramite un confronto con il team aziendale che lavora
attualmente su WOW, entrando in contatto con il metodo Agile G 7.4.
Obiettivi dello stage
Per l’attività di stage, in accordo col tutor aziendale, sono stati fissati degli obiettivi
obbligatori e degli obiettivi desiderabili in modo da tracciare una linea guida per il
progetto rispettando le necessità dell’azienda.
Si farà riferimento ai requisiti secondo le seguenti notazioni:
• «Ob» per i requisiti obbligatori, vincolanti in quanto obiettivo primario;
• «De» per i requisiti desiderabili, non vincolanti o strettamente necessari.
1112 CAPITOLO 2. IL PROGETTO DI STAGE
Le sigle precedentemente indicate saranno seguite da una coppia sequenziale di
numeri, che identificano il requisito.
Obiettivi obbligatori
Gli obiettivi obbligatori rappresentano i requisiti che devono essere garantiti dallo
studente per iniziare il progetto di stage.
Gli obiettivi concordati sono stati i seguenti:
• Ob1 : Studio delle funzionalità e delle caratteristiche della piattaforma WOW ;
• Ob2 : Studio delle tecnologie utilizzate e dell’ambiente di lavoro;
• Ob3 : Studio delle API di Office365 necessarie allo sviluppo dei servizi;
• Ob4 : Definizione delle specifiche dei servizi, della loro Governance e delle Policy
ad essi applicate;
• Ob5 : Progettazione e implementazione delle funzionalità concordate, in parti-
colare:
– Ob5.1 : Deve essere disponibile la funzionalità di autenticazione del tipo
server-to-server;
– Ob5.2 : Deve essere possibile gestire i calendari di ogni utente Office 365
interno all’azienda;
– Ob5.3 : Deve essere possibile aggiungere, togliere e modificare le attività
sul calendario;
– Ob5.4 : Deve essere gestita la notificazione per gli inviti agli eventi.
• Ob6 : Stesura documentazione relativa ai servizi realizzati.
Obiettivi desiderabili
Gli obiettivi desiderabili rappresentano requisiti non strettamente necessari ma che
se soddisfatti riconoscono valore aggiunto al prodotto. Gli obiettivi concordati sono i
seguenti:
• De1 : Collegare ogni attività in calendario con il consuntivo della stessa, in
particolare:
– De1.1 : Creare, leggere e modificare un record di consuntivazione (dal
database);
– De1.2 : Creare un riferimento ad un consuntivo ed associarlo al relativo
impegno in calendario.2.3. VINCOLI TECNOLOGICI 13
Vincoli tecnologici
I vincoli tecnologici rappresentano delle condizioni a cui attenersi o adattarsi per lo
svolgimento delle attività. All’interno di Wintech i vincoli tecnologici e d’ambiente
di sviluppo sono stati i seguenti:
• Lo sviluppo dei servizi applicativi deve avvenire in linguaggio Java, che
rappresenta il riferimento tecnologico aziendale per applicazioni back-end;
• Lo sviluppo di tali servizi deve avvenire in ambiente Windows 10 ed esclusi-
vamente su macchine aziendali;
• Il versionamento del codice deve avvenire utilizzando Subversion, che rappre-
senta il software di riferimento per il versionamento del codice in azienda;
• La scelta delle librerie e l’IDE da utilizzare è libera.
Pianificazione del lavoro
Lo stage ha coperto attività per la durata effettiva di circa 300 ore, distribuite
secondo l’orario di lavoro aziendale nell’arco di 8 settimane.
La codifica, i test e la documentazione hanno seguito le norme previste all’interno
dell’azienda.
La documentazione è stata stilata costantemente durante tutto il periodo di stage.
La pianificazione delle attività di stage è stata così ripartita:
• Prima settimana: Analisi delle funzionalità e delle caratteristiche della piatta-
forma WOW ;
• Seconda settimana: Analisi degli strumenti interni inerenti al servizio da
realizzare;
• Terza settimana: Studio delle API di interesse per la realizzazione dei servizi;
• Quarta settimana: Analisi, stesura e verifica delle specifiche desiderate con il
tutor aziendale ed il team di sviluppo di WOW;
• Quinta, Sesta e Settima settimana: Sviluppo dei servizi pianificati;
• Ottava settimana: Documentazione del lavoro svolto con descrizione delle sue
attività e dei servizi prodotti.CAPITOLO 3
Microsoft Graph, Azure AD e OAuth 2.0
Questo capitolo descrive l’analisi dell’ambiente Microsoft Graph, Azure AD e OAuth 2.0.
Si tratta di uno studio di fattibilità del progetto in relazione a requisiti, vincoli e alle
tecnologie da adottare per ottenere un’autorizzazione server-to-server.
Microsoft Graph
Graph è una piattaforma di sviluppo offerta da Microsoft, che espone delle API,
accessibili da un singolo endpoint: https://graph.microsoft.com, utili per gestire
i servizi offerti da Office 365.
figura 3.1: Graph - Struttura delle relazioni tra servizi
Graph viene rappresentato tramite un grafo che traccia le relazioni tra i vari servizi
di Office 365 permettendo l’accesso a risorse e ad azioni attraverso l’uso di API. Tra
tutte le entità visibili nel grafo in figura (3.1), è importante sottolineare i servizi utili
per lo scopo di stage, in particolare:
• Calendar: È un servizio che permette la gestione di uno o più calendari Office
365 e di tutti gli elementi legati ad un calendario, come ad esempio gli eventi;
1516 CAPITOLO 3. MICROSOFT GRAPH, AZURE AD E OAUTH 2.0
• User: È un servizio che permette la gestione dei contatti associati ad un utente
Office 365;
• Messages: È un servizio che permette la gestione della posta associata ad un
utente Office 365.
Cosa si può fare con Graph?
Grazie all’utilizzo di Microsoft Graph è possibile creare servizi e applicazioni con un
alto grado di personalizzazione a seconda delle necessità dell’utente. Tramite Graph
si può ad esempio:
• Tenere traccia di una riunione e fornire all’utente informazioni sul profilo dei
partecipanti, nonché informazioni sugli ultimi documenti e progetti per cui
stanno lavorando;
• Esplorare il calendario dell’utente e suggerire i tempi migliori per la prossima
riunione;
• Recuperare l’ultima proiezione di vendita da un file Excel caricato in OneDrive
e aggiornare in tempo reale le previsioni, anche da dispositivo mobile;
• Aiutare a categorizzare informazioni personali e di lavoro in modo da averle
sempre a portata di mano.
Come si può notare, questi esempi di funzionalità offerte si avvicinano molto
all’obbiettivo finale del servizio applicativo richiesto dallo stage.3.2. AZURE AD 17
Azure AD
Microsoft Azure è una raccolta di servizi cloud integrati in continua evoluzione usata
da sviluppatori e professionisti IT per creare, distribuire e gestire applicazioni tramite
la rete globale di data center.
figura 3.2: Azure - Logo ufficiale
Tramite Azure vengono erogati servizi appartenenti a diverse categorie quali:
• Risorse di elaborazione;
• Archiviazione e memorizzazione dati;
• Trasmissione dati;
• Interconnessione di reti;
• Analisi;
• Intelligence;
• Apprendimento automatico;
• Sicurezza e gestione delle identità;
• Monitoraggio e gestione;
• Servizi per lo sviluppo di applicazioni.
Con Azure è possibile usare strumenti e tecnologie open source, in quanto supporta
un’ampia selezione di sistemi operativi, linguaggi di programmazione, framework,
database e dispositivi.
Il Centro sicurezza di Azure permette di prevenire, rilevare e gestire le minacce
tramite livelli maggiori di visibilità e controllo della sicurezza di tutte le risorse
impiegate.18 CAPITOLO 3. MICROSOFT GRAPH, AZURE AD E OAUTH 2.0
Autorizzazione
Uno degli obbiettivi obbligatori per il progetto era l’autorizzazione per l’esecuzione
di servizi sull’account aziendale di Office 365, essa deve avvenire in back-end e in
maniera automatica, senza la parte di front-end di interazione con l’utente. Una
prima parte del progetto si è quindi concentrata sulla modalità con le quali Office
365 tratta logicamente l’accesso ai suoi contenuti, gli account e gli utenti ad essi
associati.
OAuth 2.0
La procedura di autenticazione utilizza OAuth 2.0, che è un protocollo standard
industriale per l’autorizzazione, supportata anche da Office 365. Si basa su OAuth
2.0 Framework, che abilita un’applicazione di terze parti ad ottenere accesso limitato
ad un servizio HTTP, organizzando un’interazione di approvazione tra il proprietario
della risorsa ed il servizio HTTP o permettendo all’applicazione di terze parti di
ottenere l’accesso a proprio nome.
figura 3.3: OAuth 2.0 - Logo ufficiale3.3. AUTORIZZAZIONE 19
Authorize Request
Dopo una ricerca ho individuato una possibile soluzione che utilizza il metodo classico
di autenticazione di OAuth 2.0, spiegato dal seguente schema:
figura 3.4: OAuth 2.0 - Authorize request
Il flusso che questo metodo utilizza per l’autorizzazione di accesso ai servizi offerti
da Microsoft Graph è composto dai seguenti punti:
1. L’utente richiede (tramite un’interfaccia grafica) l’autorizzazione di accesso;
2. L’utente viene indirizzato ad un form di accesso ad Azure AD ed inserisce le
credenziali;
3. Azure AD, dopo i vari controlli, concede l’autorizzazione consegnando al
chiamante un codice chiamato id_token;
4. Utilizzando l’id_token l’applicazione chiamante può richiedere le risorse di cui
necessita al Web Server ;
5. Il Web Server controllata la validità dell’id_token crea una sessione per l’utente
all’interno della quale esso potrà utilizzare le risorse richieste.
Il problema che si riscontra utilizzando questo metodo, oltre a richiede una procedura
di autenticazione da front-end, è che non è adatto per i servizi da realizzare secondo
obiettivi progettuali, ma applicabile solamente in caso di un’integrazione di contenuti
con una applicazione (web) già esistente.20 CAPITOLO 3. MICROSOFT GRAPH, AZURE AD E OAUTH 2.0
Ciò che si adatterebbe perfettamente al caso in analisi è un processo di autenticazione
che tralasci la fase di inserimento delle credenziali utente (punti 1 e 2). È quindi
necessario sostituire le credenziali utente con un altra serie di codici identificativi.
Access Token request
Approfondento lo studio dei metodi di autenticazione di OAuth 2.0 ho trovato la
soluzione finale nel metodo spiegato di seguito:
figura 3.5: OAuth 2.0 - Access Token request
Il flusso che questo metodo utilizza per l’autorizzazione di accesso ai servizi offerti
da Microsoft Graph è composto dai seguenti punti:
1. L’applicazione Client richiede all’endpoint di OAuth 2.0 un codice chiamato
access token;
2. L’endpoint dopo le dovute verifiche restituisce all’applicazione chiamante
l’access token;
3. Tramite l’access token l’applicazione Client può ora richiedere le risorse di cui
necessita mediante chiamate alle API;
4. Il servizio chiamato risponde concedendo le risorse richieste, accompagnate da
un oggetto JsonG 7.4.
Come si può notare la logica di questo metodo assomiglia molto a quella del precedente,
infatti il punto essenziale è lo stesso, viene richiesto un codice di accesso fornedo3.3. AUTORIZZAZIONE 21 l’identità del chiamante che deve essere riconosciuta dal sistema chiamato. La differenza sostanziale tra i due metodi studiati è che nel primo si utilizza l’identità dell’utente per ottenere l’autorizzazione di accesso, mentre nel secondo viene fornita l’identità dell’applicazione stessa come fosse un utente.
CAPITOLO 4
Tecnologie utilizzate
Questo capitolo descrive le tecnologie e gli strumenti utilizzati durante il periodo di
sviluppo riportandone i pregi e i difetti.
Linguaggio di programmazione utilizzato
Il linguaggio di programmazione utilizzato per la codifica, secondo gli standard
aziendali, è Java (in versione 1.8).
Java
figura 4.1: Java - Logo ufficiale
Java è un linguaggio di programmazione ad alto livello, orientato agli oggetti e a
tipizzazione statica, specificatamente progettato per essere il più possibile indipen-
dente dalla piattaforma di esecuzione. Da standard aziendale viene utilizzato per lo
sviluppo di ogni applicativo che elabori in back-end.
Vantaggi
• Compatibilità multipiattaforma (grazie alla Virtual Machine);
• Alta astrazione dalla macchina fisica (implica semplicità di sviluppo, uniformità
e portabilità);
2324 CAPITOLO 4. TECNOLOGIE UTILIZZATE
• Velocità di sviluppo;
• Portabilità su diversi Sistemi Operativi;
• Grande disponibilità di librerie;
• Alta integrazione con il web.
Svantaggi
• Per il progetto in analisi non sono disponibili sdkG 7.4 ufficiali di Office 365
che avrebbero velocizzato il processo di sviluppo;
• Alta astrazione (impedisce l’uso di caratteristiche specifiche di una determinata
macchina o OS);
• Linguaggio verboso;
• Leggermente più lento (derivante da uso di Virtual Machine);
• Codice decomponibile.4.2. STRUMENTI DI SUPPORTO 25
Strumenti di supporto
A supporto dello sviluppo è stato necessario affiancare alcune tecnologie e strumenti
per garantire un livello di qualità del codice e della sua manutenzione in linea con
gli standard aziendali. Di seguito sono riportate le descrizioni delle tecnologie di
supporto adottate, le motivazioni ed i contesti del loro utilizzo.
Apache Maven
figura 4.2: Apache Maven - Logo ufficiale
Maven è un progetto open source, sviluppato da Apache, che permette di organizzare
in modo efficiente un progetto java utilizzando buildautomation g 7.4.
I componenti principali di Maven sono i seguenti:
• pom.xml: (POM, Project Object Model) file di configurazione che contiene
tutte le informazioni su un progetto (dipendenze, test, documentazione, ecc);
• Goal: singola funzione che può essere eseguita sul progetto. I goal possono
essere sia specifici per il progetto dove sono inclusi, sia riusabili;
• Jelly script: linguaggio XML con il quale vengono definiti i goal;
• Plug-in: goal riutilizzabili in tutti i progetti;
• Repository: directory strutturata destinata alla gestione delle librerie. Un
repository può essere locale o remoto.
Maven effettua automaticamente il download di librerie Java e plug-in dai vari
repository definiti, scaricandoli in locale o in un repository centralizzato. Questo
permette di recuperare in modo uniforme i vari file JARg 7.4 e di poter spostare il
progetto da un ambiente all’altro avendo la sicurezza di utilizzare sempre le stesse
versioni delle librerie.
Nel progetto personale, Maven, è stato impiegato per la gestione delle dipendenze,
delle librerie incluse e per la compilazione del codice sorgente.
Vantaggi
• Standardizzazione della struttura di un progetto e della sua compilazione;
• Test ed esportazione del progetto automatizzate;
• Gestione e download automatico delle librerie necessarie al progetto;26 CAPITOLO 4. TECNOLOGIE UTILIZZATE
• Sistema indipendente per la gestione di artifatti software come librerie o moduli;
• Ricerca e download delle dipendenze in un sistema centralizzato, dedicato e
anche personalizzabile (Maven 2 Central Repository);
• Alta portabilità;
• Stessa configurazione garantita in ambienti software differenti.
Svantaggi
• Al termine del processo di sviluppo, essendo il progetto corposo, il processo di
build risultava lento.4.3. AMBIENTE DI SVILUPPO E VERSIONAMENTO 27
Ambiente di sviluppo e versionamento
Questa sezione è dedicata alla descrizione dell’ambiente di sviluppo e della sua confi-
gurazione per quanto riguarda la codifica dei servizi e la gestione del versionamento
del codice e della documentazione.
Ogni scelta, esclusa quella per l’IDE di sviluppo, è in linea con le procedure e gli
standard impiegati in azienda.
IntelliJ IDEA
figura 4.3: IntelliJ IDEA - Logo ufficiale
IntelliJ IDEA è un ambiente di sviluppo integrato (IDE) molto famoso, principalmente
adottato per il linguaggio di programmazione Java.
Sviluppato da JetBrains (prima conosciuto come IntelliJ), è disponibile in due edizioni:
Community Edition (free) ed Ultimate Edition (a pagamento).
Per la durata di sviluppo del progetto si è adottata l’Ultimate Edition sotto licenza
studenti (utilizzabile un anno dalla sua attivazione) fornita dall’Università di Padova.
Vantaggi
• Svariati linguaggi di programmazione supportati (Java, SQL, XML/XSL,
HTML/XHTML/CSS, JavaScript e molti altri);
• Moltissime funzionalità legate al linguaggio di programmazione, tra cui short-
cuts, gestione delle componenti, suggerimenti sulla sintassi e molto altro;
• Integrazione di un sistema real-time per l’avviso degli errori a livello sintattico
e logico legato al linguaggio;
• Supporto a debugging e test automatici;
• Supporto ai principali software per il controllo di versione (Git, Mercurial,
Subversion ed altri).
Svantaggi
• Richiede parecchie risorse hardware e diventa sempre più pesante sostenere
progetti molto vasti, specialmente in una prima fase di indicizzazione delle
risorse e di una prima build del progetto.28 CAPITOLO 4. TECNOLOGIE UTILIZZATE
Subversion
figura 4.4: Subversion - Logo ufficiale
Subversion (noto anche come SVN, che indica invece il nome del suo client a riga
di comando) è un sistema centralizzato di controllo versione per software. È stato
progettato da CollabNet Inc. con lo scopo di essere il naturale successore di CVS,
oramai considerato superato.
In Subversion le vere transazioni atomiche sono le commitg 7.4 e una commit interrotta
non lascia il repository in uno stato di incoerenza. Subversion è stato utilizzato
seguendo lo standard aziendale per il versionamento del codice legandolo all’ambiente
di lavoro ed utilizzandolo per fare commit regolari del codice prodotto giorno per
giorno durante il periodo di sviluppo e di test dei servizi.
Vantaggi
• Le directory, i cambi di nome, e i metadati dei file sono sotto controllo di
versione;
• Branching e Tagging sono operazioni veloci, che richiedono un tempo indipen-
dente dalla dimensione dei dati;
• Il progetto è nativamente client/server, ed è basato su una libreria stratificata;
• Il protocollo client/server invia solo le differenze in entrambe le direzioni, quindi
i costi di comunicazione sono proporzionali alla dimensione delle modifiche e
non alla dimensione dei dati;
• La licenza del progetto è Open Source, simile a quella di Apache.
Svantaggi
• Esistono altri sistemi più aggiornati (ad esempio Git) che impediscono di fare
operazioni pericolose che Subversion permette;
• Subversion è centralizzato e non distruibuito, quindi non è presente una copia
fisica nella macchina utente;
• L’operazione di merge può essere lenta e pericolosa in un sistema centralizzato.CAPITOLO 5
Progettazione e codifica
Questo capitolo descrive la configurazione delle parti interessate allo sviluppo e le
peculiarità dei servizi realizzati.
Impostazione del progetto
Questa sezione descrive i passaggi per configurare l’ambiente remoto e quello locale
in modo tale che essi possano comunicare tra loro.
Tale approccio ha consentito di testare il funzionamento del codice prodotto durante
tutto l’arco temporale della codifica e di progettare i servizi adattandoli al meglio in
relazione alle funzionalità di Office 365.
Microsoft Azure Portal
Per far si che il codice prodotto agisca sui contenuti in remoto, bisognerà creare
un’applicazione, tramite il servizio fornito da Azure Portal, in modo da relazionare il
codice scritto nel progetto e l’account Office 365 aziendale. Tale applicazione viene
definita da Office 365 con il termine “Service Account”. Definiamo meglio il suo
ruolo ed il legame che possiede con le altre entità all’interno del servizio cloud.
Un Service Account è un account di servizio che rappresenta un’applicazione col-
legata direttamente all’account dell’azienda (Enterprise in questo caso) ed utilizza
un’autenticazione server-to-server con OAuth 2.0. Non ha dei contenuti propri ma
può controllare lo spazio cloud di tutti gli utenti interni all’azienda.
La differenza tra Service Account ed App user è molto sottile:
• Il primo, che abbiamo già capito essere l’applicazione dell’azienda, a seconda
del livello di autorizzazione, consente di controllare i vari utenti creando degli
App user ed agendo per conto loro;
• Un App User quindi rappresenta solamente un utente che appartiene all’appli-
cazione definita in Azure Portal.
Vediamo di seguito quali sono i passi per configurare questo Service Account:
2930 CAPITOLO 5. PROGETTAZIONE E CODIFICA
1. Creazione di nuova applicazione
La prima operazione da fare è entrare all’interno di Azure Portal accedendo ad:
https://portal.azure.com
ed autenticandosi con le credenziali aziendali.
Dopo aver eseguito l’autenticazione la schermata che si presenterà sarà la seguente:
figura 5.1: Microsoft Azure Portal - Homepage del portale
I passi per creare una nuova applicazione adatta ai requisiti del progetto sono:
1. Cliccare su “Azure Active Directory”;
2. Cliccare su “Registrazioni per l’app” e “Registrazione nuova applica-
zione”;
3. Inserire il nome della nuova applicazione;
4. Inserire la tipologia (App Web/API in questo caso);
5. Inserire un URL di accesso (casuale perchè non necessario);
6. Cliccare su “Crea”.5.1. IMPOSTAZIONE DEL PROGETTO 31
2. Configurazione delle Autorizzazioni necessarie
Una volta che l’applicazione è stata creata è necessario configurarla, impostando le
varie autorizzazioni necessarie per l’applicazione.
figura 5.2: Microsoft Azure Portal - Autorizzazioni necessarie
Cliccando quindi sopra la voce “Autorizzazioni necessarie” nel menù dell’appli-
cazione, si entrerà nella sezione di configurazione delle autorizzazioni. A questo
punto cliccando su “Aggiungi” è possibile selezionare uno o più servizi ai quali
l’applicazione si riferirà, nel mio caso è stato selezionato Microsoft Graph richiedendo
i vari permessi di lettura e scrittura sui calendari di Office 365. Per essere effettive
le autorizzazioni devono essere concesse dall’amministratore dell’account aziendale
di Azure che deve semplicemente cliccare su “Concedi autorizzazioni” una volta
acceduto al menù dell’applicazione.32 CAPITOLO 5. PROGETTAZIONE E CODIFICA
3. Configurazione chiave privata
È necessario impostare una o più chiavi private nel portale Azure in modo tale che
utilizzando le stesse nella fase di autenticazione il sistema verifichi la corrispondenza
e riconosca la validità della richiesta.
figura 5.3: Microsoft Azure Portal - Impostazione chiave privata
Cliccando quindi sopra la voce “Chiavi” nel menù dell’applicazione, si entrerà nella
sezione di configurazione delle chiavi private. In questo modulo è possibile impostare
una descrizione, una data di scadenza e il valore delle chiavi; il valore della chiave
viene immediatamente crittografato e non sarà più visibile nel portale, quindi è utile
salvare tale valore in un file esterno (anche remoto).5.2. CODIFICA DEI SERVIZI 33
Codifica dei servizi
Passiamo alla sezione che descrive i servizi che si sono realizzati, partendo dalla
richiesta di autenticazione server-to-server per andare a vedere poi nel dettaglio
alcuni dei servizi sviluppati.
Autenticazione server-to-server
Per soddisfare la modalità di autenticazione, come rischiesto da obiettivi progettuali,
è necessario seguire un processo che prevede:
1. Richiesta del token d’accesso;
2. Parsing del risultato.
Richiesta del token d’accesso
La richiesta del token d’accesso avviene mediante una chiamata POST contenente le
seguenti informazioni:
1 - Token Endpoint: https://login.windows.net//oauth2/token
Si tratta dell’endpoint verso il quale l’applicazione deve rivolgersi per ottenere il
token di accesso. Questo end-point è ottenibile dal portale di Azure accedendo alla
scheda “Endpoint”. Esso è composto da 4 parti:
• https://login.windows.net: si tratta di un URI di riferimento al server che
si occupa di concedere l’autorizzazione di accesso;
• tenant-id: è una stringa di caratteri che identifica l’utente Microsoft Azure,
amministratore dell’applicazione;
• oauth2: come detto in precedenza è il protocollo di autorizzazione utilizzato;
• token: per segnalare al server che la richiesta è posta per ottenere un token di
accesso.
2 - Grant Type: client_credentials
È il tipo di concessione richiesta; nel mio caso deve essere utilizzato il tipo “client_credentials”
perchè informa il server, a cui viene fatta la richiesta, che i parametri inviati sono le
credenziali dell’utente/applicazione richiedente. È quindi chiaro che l’autorizzazione
viene concessa solo a client fidati dopo un controllo delle informazioni inviate.
3 - Resource: https://graph.microsoft.com
Si tratta del servizio verso il quale viene richiesta l’autorizzazione. Nel mio caso
come detto in precedenza l’autorizzazione viene richiesta per il servizio Microsoft
Graph perchè è esso che gestisce il calendario di Office 365.34 CAPITOLO 5. PROGETTAZIONE E CODIFICA
4 - Dati esterni: Client secret e id dell’applicazione
Questi dati, per come è stato scritto il codice, sono contenuti in un file esterno e
dopo essere stati recuperati devono essere integrati alla richiesta, si tratta di:
• Client secret: cioè la chiave privata crittografata ottenuta dal portale Azure in
precedenza;
• Id dell’applicazione: esso è fornito sempre dal portale Azure al momento della
creazione dell’applicazione e identifica univocamente l’applicazione.
Parsing del risultato
Il risultato della richiesta di autorizzazione è un oggetto Json costruito in questo
modo:
{
"token_type":"Bearer",
"expires_in":"3599",
"ext_expires_in":"0",
"expires_on":"1502443010",
"not_before":"1502439110",
"resource":"https://graph.microsoft.com",
"access_token":""
}
Dal questo Json sono estraibili le seguenti informazioni:
1 - Token type: Bearer
“token_type” è un parametro che rappresenta il tipo del token richiesto, cioè il modo
in cui il token di accesso viene generato e presentato alla risorsa chiamata.
Il valore “Bearer” (di default per molte implementazioni) indica che il server, verso il
quale viene fatta la richiesta, risponde semplicemente consegnando il token di accesso.
Per altri tipi di token, come ad esempio il tipo Mac, il token di accesso viene generato
e tenuto segreto in un Key ManagerG 7.4 come attributo e viene inviata in risposta
una mac_key per la decriptazione.
2 - Scadenze del token: expires_in, ext_expires_in, expires_on, not_before
Si tratta di informazioni sulla scadenza del token di accesso in secondi, nella richiesta
questi valori sono mantenuti di default (circa un’ora di durata) in quanto per il
progetto di stage non era richisto di mantenere una sessione attiva per un particolare
periodo di tempo;
3 - Resource: https://graph.microsoft.com
Questo parametro riporta semplicemente la risorsa verso la quale si richiede l’auto-
rizzazione; Microsoft Graph nel mio caso.
4 - Access Token: stringa di caratteri (2418)
Il token di accesso ottenuto è un JWT token che include informazioni sull’amministra-
tore che ha concesso l’autorizzazione e l’applicazione che ha richiesto l’autorizzazione.
Di seguito è riportato un esempio di un access token JWT decodificato.5.2. CODIFICA DEI SERVIZI 35
{
"aud": "https://graph.microsoft.com",
"iss": "https://sts.windows.net/b4f0a60f-91e0-4d83-bea1-221b3dc3f06d/",
"iat": 1502443120,
"nbf": 1502443120,
"exp": 1502447020,
"aio": "Y2FgYDj1R/Wj+2bGwmtvX1Vr6z60BAA=",
"app_displayname": "wintech-office365-utils",
"appid": "e96a78c7-7aaa-4c6a-94e9-4eacad43a5a8",
"appidacr": "1",
"idp": "https://sts.windows.net/b4f0a60f-91e0-4d83-bea1-221b3dc3f06d/",
"oid": "9e521a28-e066-4d11-85d8-25eee51ada11",
"roles": [
"Calendars.ReadWrite",
],
"sub": "9e521a28-e066-4d11-85d8-25eee51ada11",
"tid": "b4f0a60f-91e0-4d83-bea1-221b3dc3f06d",
"uti": "vkq-N6SyQUugRm7NuIYjAA",
"ver": "1.0"
}
Le più importanti informazioni che derivano da questa decodifica sono:
• aud: si riferisce al servizio che ha concesso l’autorizzazione;
• appid: è il codice identificativo dell’applicazione richiedente;
• role: è la sequenza di permessi associati all’applicazione richiedente, nel mio
caso Calendars.ReadWrite per poter agire sui calendari di Office 365;
• tid: è il codice identificativo dell’amministratore dell’applicazione richiedente,
in questo caso è il mio.36 CAPITOLO 5. PROGETTAZIONE E CODIFICA
Servizi realizzati
Il package principale che contiene l’implementazione dei servizi è il package
it.wintech.calendarutils. Successivamente verrà descritto il comportamento
delle classi in esso contenute e le implementazioni di ulcuni metodi utilizzati per
una demo aziendale avvenuta in occasione della presentazione del mio progetto al
termine dello stage.
it.wintech.calendarutils
figura 5.4: it.wintech.Calendarutils - Package utilizzato per la demo aziendale
Classi
Il package contiene le seguenti classi:
• CalendarController: Classe dove sono implementati i servizi richiesti, cioè
quelli di gestione dei calendari Office 365;
• ClassForTest: Classe che simula, in maniera semplificata, la piattaforma
WOW al momento della chiamata ai servizi.5.2. CODIFICA DEI SERVIZI 37
CalendarController
La classe CalendarController possiete i seguenti metodi:
Ritorno e descrizione Metodo e descrizione
java.lang.String getAuthorization()
The access token String This method sends a POST request to graph’s API
https://login.windows.net//oauth2/token,
the response is received through a json object contai-
ning also the access token. Some information, such as
the client id and the client secret is retrived from a
json file named config.
void getCalendars(java.lang.String accessToken,
java.lang.String principalName)
Method that print all calendars names referred to
the office 365 user named “principalName”. This
method use an http GET request to the graph’s API
https://graph.microsoft.com/v1.0/users/
/calendars, the response is received through a json
object containing all the names of the calendars.
void addEvent(java.lang.String accessToken,
java.lang.String principalName,
java.lang.String calendarName,
java.lang.String eventName, java.lang.String
customer, java.lang.String description,
java.time.LocalDateTime start,
java.time.LocalDateTime end, java.lang.String
location, java.utils.List attendees)
addEvent creates an event in a calendar throu-
gh an http POST request to the graph’s API
https://graph.microsoft.com/v1.0/users/
/calendars//events. The POST request’s
body is formed by a compless json object that contain
all the needed event’s information. The event’s
description is formed by HTML code. The response
is received through a json object containing also the
event’s id.
void deleteEvent(java.lang.String eventId,
java.lang.String accessToken,
java.lang.String principalName,
java.lang.String calendarName)38 CAPITOLO 5. PROGETTAZIONE E CODIFICA
deleteEvent deletes an event in a calendar th-
rough an http DELETE request to the graph API
https://graph.microsoft.com/v1.0/users/
/calendars//events/. The
response is received through a json object.
void updateEvent(java.lang.String
eventId, java.lang.String accessToken,
java.lang.String principalName,
java.lang.String calendarName,
java.lang.String eventName, java.lang.String
customer, java.lang.String description,
java.time.LocalDateTime start,
java.time.LocalDateTime end, java.lang.String
location, java.util.List attendees)
updateEvent update an event in a calendar th-
rough an http PATCH request to the graph API
https://graph.microsoft.com/v1.0/users/
/calendars//events/. The
PATCH request’s body is formed by a compless json
object that contain all new event’s informations. The
event’s description is formed by HTML code. The
response is received through a json object containing
also the event’s id.
tabella 5.1: CalendarController - Metodi contenuti nella classePuoi anche leggere
