Università degli Studi di Padova Dipartimento di Matematica "Tullio Levi-Civita" Corso di Laurea in Informatica

Sviluppo di un PreLogonAgent per il reset autonomo di password Active Directory su piattaforma macOS

Tesi di laurea triennale

Relatore Prof.Claudio Enrico Palazzi

Laureando Pardeep Singh

Matricola 1143264 ii

Anno Accademico 2018-2019 Pardeep Singh: Sviluppo di un PreLogonAgent per il reset autonomo di password Active Directory su piattaforma macOS, Tesi di laurea triennale, c Settembre 2019.

Sommario

Il presente documento descrive il lavoro svolto durante il periodo di stage, della durata di circa trecentoventi ore, dal laureando Pardeep Singh presso l’azienda NETCOM 1.

Lo stage consisteva nel trovare una valida soluzione per poter permettere all’utente finale di accedere al sito (tramite un browser opportunamente limitato) di Hydro- gen[g] direttamente dalla schermata di login di Apple macOS.

Gli obiettivi da raggiungere erano molteplici, e sono descritti di seguito. In primo luogo era richiesto lo studio del componente Hydrogen Custom Logon dispo- nibile per il sistema operativo Microsoft Windows e Ubuntu Linux. In secondo luogo era richiesta un’analisi delle problematiche derivanti dalla chiusura del sistema operativo Apple macOS, e delle varie versioni dello stesso. In seguito a ciò, era richiesta l’identificazione e tracciamento dei requisiti che deve possedere il componente software sviluppato. Terzo ed ultimo obiettivo era definire un’architettura ad alto livello e organizzare i componenti, passando infine alla fase di implementazione e test.

1https://www.netcom.it/

v

“If you cannot do great things, do small things in a great way” — Napoleon Hill

Ringraziamenti

Innanzitutto, vorrei esprimere la mia gratitudine al Prof. Claudio Enrico Palazzi, relatore della mia tesi, per l’aiuto e il sostegno fornitomi durante la stesura del lavoro.

Vorrei ringraziare tanto anche il tutor Claudio Guarisco di NETCOM 2, che mi ha segui- to con molta disponibilità per tutta la durata del tirocinio fornendomi tanti consigli utili.

Desidero ringraziare con affetto i miei genitori per il sostegno, il grande aiuto e per essermi stati vicini in ogni momento durante gli anni di studio.

Un grande ringraziamento a mio fratello e mia sorella, che mi hanno insegnato a non arrendersi mai e mi hanno sempre sostenuto.

Ho desiderio di ringraziare poi i miei cari amici per tutto il tempo passato insieme in questo percorso di studi.

Padova, Settembre 2019 Pardeep Singh

2https://www.netcom.it/

vii

Indice

0.1 Organizzazione del testo ...... 1

1 Descrizione dell’azienda3 1.1 L’azienda ...... 3 1.2 Organigramma ...... 4 1.3 I servizi offerti ...... 5 1.4 Tecnologie ...... 6

2 Descrizione dello stage9 2.1 Origini del progetto Hydrogen...... 9 2.2 Scopo dello stage ...... 9 2.3 Obiettivi ...... 10 2.3.1 Obbligatori ...... 10 2.3.2 Desiderabili ...... 10 2.3.3 Facoltativi ...... 11 2.4 Tecnologie adottate ...... 11

3 Organizzazione dello stage 13 3.1 Piano di lavoro ...... 13 3.2 Fasi del progetto ...... 13

4 Analisi dei requisiti 15 4.1 Analisi delle caratteristiche del prodotto finale ...... 15 4.1.1 Possibili approcci per lo sviluppo del componente ...... 15 4.1.2 Criteri di valutazione per la scelta della soluzione da sviluppare 16 4.1.3 Considerazioni sul browser da adottare ...... 16 4.2 Active Directory su macOS ...... 17 4.3 Casi d’uso ...... 17 4.3.1 Caso d’uso principale ...... 17 4.4 Tracciamento dei requisiti ...... 17 4.5 Approcci per la creazione del componente ...... 19 4.5.1 Authorization plug-in ...... 19 4.5.2 Pre-Logon Agents ...... 22

5 Progettazione e codifica 25 5.1 Tecnologie e strumenti ...... 25 5.2 Progettazione ...... 25 5.2.1 Struttura del progetto ...... 26 5.2.2 Namespace "MacLogonAgent.Core" ...... 26 5.2.3 Namespace "MacLogonAgent.Installer.Core" ...... 29

ix x INDICE

5.2.4 Namespace "MacLogonAgent.Installer.RequestURL" ...... 30 5.3 Codifica ...... 30 5.3.1 Installer per l’agent ...... 31

6 Verifica e validazione 33 6.1 Test ...... 33 6.1.1 Test di unità ...... 33 6.1.2 Test di sistema ...... 34

7 Documentazione 35 7.1 Manuale utente ...... 35 7.2 Manuale sviluppatore ...... 35

8 Conclusioni 37 8.1 Raggiungimento degli obiettivi ...... 37 8.1.1 Obbligatori ...... 37 8.1.2 Desiderabili ...... 37 8.1.3 Facoltativi ...... 37 8.2 Rispetto delle scadenze ...... 38 8.3 Conoscenze acquisite e valutazione personale ...... 38

Glossary 41

Acronyms 45

Bibliografia 47 Elenco delle figure

1.1 Logo di NETCOM ...... 3 1.2 Organigramma di NETCOM ...... 4 1.3 Panoramica dei servizi offerti da Ivanti Endpoint Manager ...... 7 1.4 Panoramica del servizio SRS di Snow ...... 8

3.1 Diagramma di Gantt per il progetto di stage ...... 13

4.1 Use Case - UC1: Scenario principale ...... 17 4.2 Diagramma dei package per l’authorization plug-in ...... 19 4.3 Schermata che rappresenta il form di login ottenuto con il plug-in... 21 4.4 Esempio di definizione di un’attività...... 24

5.1 Diagramma dei package di MacLogonAgent ...... 26 5.2 Diagramma delle classi del namespace "MacLogonAgent.Core". . . . . 27 5.3 Descrizione file MacLogonAgent_Core.plist...... 27 5.4 Pulsante principale che permette di aprire il browser ...... 28 5.5 Schermata del browser ...... 29 5.6 Schermata dell’installer grafico ...... 30 5.7 Script "postInstall.py" ...... 31 5.8 Script "silentInstall.py" ...... 32 5.9 Script di disinstallazione "uninstall.py" ...... 32 5.10 Script di modifica dell’URL “changeURL.py” ...... 32

7.1 Schermata del manuale utente in italiano ...... 35 7.2 Schermata del manuale sviluppatore in italiano ...... 36

8.1 Consuntivo delle ore per fase di progetto ...... 38

xi xii ELENCO DELLE TABELLE

Elenco delle tabelle

4.1 Tabella del tracciamento dei requisti funzionali ...... 18 4.2 Tabella del tracciamento dei requisiti di vincolo ...... 18 4.3 Tabella che illustra i percorsi interpretati da Launchd...... 23 0.1. ORGANIZZAZIONE DEL TESTO 1

0.1 Organizzazione del testo

Il primo capitolo descrive in breve quello che è la mission dell’azienda NETCOM 3 citando anche alcuni degli strumenti utilizzati. Il secondo capitolo descrive le origini del progetto di stage, elencando anche tutti gli obiettivi da raggiungere.

Il terzo capitolo approfondisce le varie attività inerenti il progetto di stage. Il quarto capitolo approfondisce l’attività di Analisi dei requisiti. Il quinto capitolo approfondisce le fasi di progettazione e implementazione del progetto di stage.

Il sesto capitolo descrive il modo in cui ci si è assicurati di produrre codice funzio- nante. Inoltre, si parla anche della documentazione del progetto. Nel settimo capitolo vengono descritti gli obiettivi che sono stati raggiunti a fine stage, e le conoscenze acquisite dallo stagista.

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 menzionati 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] . • i termini in lingua straniera o facenti parte del gergo tecnico sono evidenziati con il carattere corsivo. • alcuni termini importanti sono riportati in grassetto. • alcuni termini (ad esempio il nome di un metodo) sono riportati con sottolineatura.

3https://www.netcom.it/

Capitolo 1

Descrizione dell’azienda

Il presente capitolo si occupa di definire il contesto aziendale nel quale si è svolto lo stage. Viene presentata l’azienda NETCOM spiegando di cosa si occupa, i servizi offerti, e l’ambito d’innovazione in cui si inserisce.

Mentre il secondo capitolo si occupa di fornire un’introduzione al progetto di stage spiegando anche gli obiettivi da raggiungere.

1.1 L’azienda

Figura 1.1: Logo di NETCOM

NETCOM nasce nel 1999 con l’obiettivo di proporre sul mercato soluzioni e servizi per l’IT Life Cycle Management e l’IT Governance, e si rivolge alle aziende che vogliono migliorare l’efficienza dei sistemi IT, attraverso una corretta gestione dei software, ottenendo importanti risultati e risparmi in termini di investimenti, tempi e costi di gestione. L’IT Life Cycle Management è reso possibile da un insieme di processi, procedure, strumenti e conoscenze che puntano alla gestione di un sistema informativo durante tutto il suo ciclo di vita. L’obiettivo finale è ottimizzare l’intero sistema di un’organiz- zazione riducendo i costi, i rischi e producendo un generale aumento della qualità.

Entrando più in dettaglio, l’IT Life Cycle Management si compone di due aspetti:

• Gestione di Endpoint[g] con approccio UEM Riguarda la gestione degli Endpoint che compongono il sistema, tramite l’ap- proccio Unified Endpoint Management(UEM). Si occupa della risoluzione dei problemi che possono eventualmente verificarsi, ma anche tutte le altre attività

3 4 CAPITOLO 1. DESCRIZIONE DELL’AZIENDA

di cadenza regolare, quali ad esempio l’aggiornamento del pacchetto software, la distribuzione di patch di sicurezza o l’assistenza tecnica.

• Ottimizzazione degli investimenti software Riguarda la gestione degli Asset software. Infatti una corretta gestione di questi asset porta all’ottimizzazione dei loro costi (licenze), e aumenta l’efficienza operativa; inoltre si migliora la pianificazione del budget e soprattutto si gestiscono i rischi legati all’utilizzo improprio del software, come ad esempio: rischi legali, spese non pianificate, danni d’immagine ed interruzione del servizio. Tutto questo è reso possibile grazie all’adozione dell’approccio Software asset management (SAM).

È quindi evidente che, per la natura dell’ambito in cui opera, il cliente tipo è un’a- zienda di dimensioni medio-grandi che possiede un sistema informativo composto da un numero di Endpoint compreso tra le 250 e le 10000 unità. Attualmente il portfolio clienti conta più di 150 società italiane sia pubbliche che private operanti nei settori: fashion, manufacturing, sanità, pubblica amministrazione locale e centrale, università e settore bancario.

Il valore aggiunto di NETCOM, rispetto ai competitors è sicuramente il riconoscimento certificato della gestione dei processi aziendali sulla base di procedure standard. La società infatti nel 2009 ha ottenuto dall’Istituto BSI la certificazione di qualità ISO 9001[g] . Inoltre, tutti i consulenti di NETCOM sono certificati sulle best practice più consolidate (ITIL, PMI, Microsoft SAM, etc), seguendo un percorso continuo di formazione.

1.2 Organigramma

L’organizzazione interna dei reparti segue il seguente schema:

Figura 1.2: Organigramma di NETCOM

• Direzione: si occupa di dirigere e pianificare tutte le attività svolte dall’azienda.

• Amministrazione: gestisce la contabilità e l’infrastruttura.

• Gestione Risorse: gestisce le risorse umane.

• Dipartimento Tecnico: è composto da quattro sotto-dipartimenti.

– Assistenza Tecnica: svolge attività di assistenza ai clienti. 1.3. I SERVIZI OFFERTI 5

– Managed Services: svolge tutte le attività di gestione del sistema infor- mativo previste dal contratto stipulato con il cliente. – Desktop Management: aiuta il cliente a mettersi nella condizione di essere in grado di svolgere tutte le attività necessarie alla gestione del proprio sistema informativo. – IT Service Management: si occupa di istanziare ed automatizzare i processi previsti dal contratto con il cliente. Inoltre si occupa di gestire tutti i problemi che possono verificarsi. • Ricerca e Sviluppo: studia e implementa nuove soluzioni tecnologiche e migliora i servizi offerti. È la parte dell’azienda che permette una continua innovazione/evoluzione dell’azienda. • Approvvigionamento: si occupa di fornire e gestire tutti i beni necessari al funzionamento dell’azienda. • Dipartimento Commerciale: si occupa di vendere i servizi offerti. • Marketing: è il reparto che permette ai servizi offerti da NETCOM di risultare convenienti e visibili sul mercato.

1.3 I servizi offerti

L’azienda fornisce attività di consulenza ad imprese di medie e grandi dimensioni dove le tecnologie informatiche sono strategiche per il business.

I servizi offerti sono i seguenti: • Proof of concept: allo scopo di garantire il successo del progetto, prima di compiere l’investimento, è buona pratica valutarne la fattibilità verificando le funzionalità della soluzione con una simulazione realistica dell’implementazione che consenta di definire in anticipo anche i seguenti aspetti: – Compatibilità con il sistema informativo esistente. – Dettagli tecnici e modalità di installazione. – Cambiamenti organizzativi e impatto sulla situazione attuale. – Opportunità e rischi legati all’utilizzo della nuova tecnologia. – Requisiti formativi del personale riferiti all’utilizzo dello strumento. – Qualità e continuità dei servizi offerti dal fornitore. – Impatto economico. NETCOM mette a disposizione le competenze dei propri consulenti per supportare i clienti presso la loro sede nello sviluppo del PoC (Proof of Concept) in un ambiente che rispecchi la realtà aziendale ed evidenzi con precisione la convenienza ed i benefici che possono derivare dall’adozione della soluzione di management pensata per il caso. • Assessment: l’assessment è un servizio di consulenza, che consente di definire con esattezza le esigenze del cliente e di identificare le azioni da intraprendere, in funzione delle proprie strategie di business. Una analisi dettagliata dello stato del 6 CAPITOLO 1. DESCRIZIONE DELL’AZIENDA

sistema informativo e dei requisiti dell’azienda riduce il rischio e l’impatto delle azioni di cambiamento, favorendo il raggiungimento dei benefici attesi. Al termine dell’assessment, il personale di NETCOM sviluppa i report che evidenziano i risultati e le linee guida necessari ad una gestione efficace dell’implementazione nel contesto operativo. Esempi di documenti di report sono l’Executive Summary e l’Assessment Detail.

• Progettazione: l’introduzione di un sistema di IT management comporta un ciclo di innovazione per l’azienda, che impatta sulle tecnologie esistenti, coinvolgendo l’organizzazione dei sistemi informativi e di altri dipartimenti aziendali. NETCOM grazie all’esperienza dei propri consulenti, è in grado di determinare anticipamente i fattori critici. La pianificazione delle attività consente di raggiungere gli obiettivi aziendali e di rispettare i costi previsti evitando inefficienze.

• Implementazione: NETCOM mediante i suoi tecnici di Supporto Operativo, si occupa dell’installazione, della configurazione e dell’avviamento del sistema di management. Questa fase è molto delicata: tutte le operazioni vanno eseguite seguendo le linee guida del documento di progetto prodotto nella fase di proget- tazione. Il personale di Supporto Operativo, collabora con l’IT Manager e con il personale di Sistemi Informativi del cliente, come fossero membri del proprio staff, per garantire il successo dell’implementazione ed effettuare attività di tipo sistemico a supporto della realizazione dei progetti.

• Formazione: NETCOM propone sessioni di formazione al cliente per renderlo in grado di utilizzare il sistema di management al massimo delle sue potenzialità. Infatti la competenza del personale del cliente nell’utilizzo del sistema di mana- gement è essenziale per raggiungere il successo dell’implementazione. Esempi di queste sono training on the job, workshop dedicati o corsi strutturati.

• Security management: per assicurare la continuità nel funzionamento del sistema di management e aiutare il personale del cliente a risolvere i problemi che possono insorgere nell’utilizzo quotidiano della soluzione, NETCOM offre la possibilità di stipulare contratti annuali di assistenza tecnica, standard o personalizzati con vari livelli di Service Level Agreement(SLA).

1.4 Tecnologie

La mission dell’azienda è proprio l’innovazione dei processi aziendali tramite attività di rinnovamento e di ottimizzazione dei processi operativi per il governo dei sistemi IT. Per questo motivo, NETCOM ha stretto delle collaborazioni per offrire ai suoi clienti le seguenti tecnologie:

• Ivanti Endpoint Manager Si tratta di una soluzione software, proposta dall’azienda Ivanti, che fornisce agli amministratori IT la capacità di gestire tutti gli Endpoint del sistema informativo con un approccio centralizzato. Ivanti Endpoint Manager permette infatti la distribuzione, l’installazione e l’aggiornamento di software in modo automatico. Un’altra caratteristica importante è la gestione delle licenze software che ricopre un ruolo molto critico. Inoltre permette anche di incrementare il livello di sicurezza del sistema. 1.4. TECNOLOGIE 7

Figura 1.3: Panoramica dei servizi offerti da Ivanti Endpoint Manager. url: https://www. ivanti.it/products/unified-endpoint-manager

• Snow Snow è un software pensato per il SAM. L’obiettivo è l’ottimizzazione delle licenze software presenti in tutti i dispositivi del sistema informativo aziendale. Gene- rando report di utilizzo, permette agli amministratori di accorgersi dell’eventuale presenza di software inutilizzati e quindi superflui o, sempre nel rispetto delle condizioni contrattuali, consigliare eventuali licenze alternative. Inoltre, fatto non trascurabile, permette di evitare i rischi legali e di immagine collegati ad un uso improprio di licenze software. Una delle funzionalità più apprezzate di Snow è la capacità di identificare automa- ticamente i software presenti nei vari Endpoint in modo da creare un inventario che tra gli altri dati contiene le versioni e le possibili licenze necessarie ad auto- rizzare l’utilizzo del software stesso. Questo meccanismo è reso possibile da un servizio remoto denominato Software Recognition Service (SRS) che viene costantemente aggiornato. 8 CAPITOLO 1. DESCRIZIONE DELL’AZIENDA

Figura 1.4: Panoramica del servizio Snow Software Recognition. url: https : / / www . snowsoftware . com / int / blog / 2014 / 07 / 28 / importance - software - recognition Capitolo 2

Descrizione dello stage

In questo capitolo viene discusso il progetto di stage ad alto livello. D’ora in poi si usa l’identificativo "Hydrogen" per identificare un prodotto software realizzato da NETCOM per il recupero automatico delle password in contesti aziendali che fanno affidamento su Active Directory[g] .

2.1 Origini del progetto Hydrogen

Il progetto Hydrogen era nato quando NETCOM si è accorta che sul mercato mancava un prodotto in grado di semplificare la questione del recupero delle password, evitando il più possibile la necessità di rivolgersi ad un help desk. Indagini di mercato mostrano che il 30% delle chiamate all’help-desk sono effettuate da utenti che hanno dimenticato la password del proprio account aziendale e ne chiedono il reset. É stato stimato che il costo medio di ogni telefonata sia di circa 25e, in termini di costo del servizio e produttività persa. Inoltre, è bene notare che l’identificazione dell’utente viene effettuata tramite il riconoscimento vocale da parte dell’operatore del servizio di helpdesk. In aziende medio-grandi questo presenta notevoli problemi di sicurezza, poiché è plausi- bile pensare che l’operatore non sia in grado di riconoscere chiunque unicamente dalla voce tramite una telefonata.

A tal proposito, NETCOM propone un’applicazione per permettere il self-reset delle password dimenticate o scadute da parte degli utenti, incrementando la sicurezza e riducendo i costi per il servizio di helpdesk. La possibilità di cambiare la propria password di dominio è offerta tramite un sito web (quindi accessibile da remoto) in modo sicuro. Per questo motivo si capisce come l’adozione di Hydrogen permetta di ridurre sia i costi ma anche aumentare l’efficienza operativa di un’azienda.

2.2 Scopo dello stage

Lo scopo del progetto Hydrogen è di offrire un’interfaccia web (quindi accessibile da remoto), che permetta agli utenti di cambiare o recuperare le proprie credenziali di

9 10 CAPITOLO 2. DESCRIZIONE DELLO STAGE accesso Active Directory; tale interfaccia deve essere visibile a seguito del click di un pulsante. Queste attività sono sicure in quanto un utente per farlo deve essere in grado di rispondere a delle domande personali che sono state inserite dallo stesso in una precedente fase di registrazione.

Il focus principale dell’applicativo sono la facilità d’uso e la facilità d’accesso. In particolare Hydrogen deve essere accessibile ad un’utente anche nella situazione in cui questo non abbia accesso ad un Endpoint autenticato. A tale scopo, sono state realizzate delle componenti software che integrandosi nella schermata di login del sistema operativo, permettono all’utente di accedere ad un browser limitato che mostra la user interface di Hydrogen. Tali componenti sono già disponibili sia per il sistema operativo Microsoft Windows, che per alcune distribuzioni Linux come Ubuntu. La mancanza (e quindi l’origine del progetto di stage in questione) era per il sistema Apple macOS, per il quale si sono analizzati due diversi approcci confrontandoli tra loro, e scegliendo quello più conveniente da realizzare. Una volta scelta una di queste due soluzioni, si è passati alla fase di progettazione e implementazione del componente, ed inoltre è stato realizzato un installer sia in versione grafica che silente (eseguibile da terminale).

La soluzione realizzata è stata chiamata MacLogonAgent, in quanto si tratta di un agent che viene avviato durante la fase di login del sistema macOS, e risulta visibile sulla schermata di login.

2.3 Obiettivi

All’inizio dell’attività di stage è stato definito un piano di lavoro contenente gli obiettivi suddivisi tra: obbligatori, desiderabili e facoltativi. Di seguito viene fatto un loro elenco.

2.3.1 Obbligatori Tra gli obiettivi obbligatori, rientrano:

• Realizzazione del componente "Hydrogen Custom Logon" per macOS (che possa funzionare sull’ultima release Mojave di macOS).

• Realizzazione di un installer del componente realizzato.

• Stesura del manuale utente (italiano).

• Stesura del manuale sviluppatore (italiano).

2.3.2 Desiderabili Tra gli obiettivi desiderabili, rientrano:

• Stesura dei manuali utente e sviluppatore in inglese.

• Implementazione della modalità di installazione silenziosa per il componente creato. 2.4. TECNOLOGIE ADOTTATE 11

2.3.3 Facoltativi Tra gli obiettivi facoltativi, rientrano: • Accertarsi della compatibilità del componente realizzato con versioni di ma- cOS antecedenti (quelle ancora ufficialmente supportate da Apple) alla versione Mojave.

2.4 Tecnologie adottate

Le scelte tecnologiche più significative sono state le seguenti:

• Xcode Xcode è un ambiente di sviluppo integrato, completamente sviluppato e mantenuto da Apple, contenente una suite di strumenti utili allo sviluppo di software per l’ecosistema dei prodotti Apple. • Swift È un linguaggio di programmazione object-oriented usato per lo sviluppo di applicazioni per i vari dispositivi prodotti da Apple (PC macOS, tvOS, etc). La sua peculiarità è la possibilità di coesistere con il linguaggio Objective-C. • Objective-C È un’estensione a oggetti del linguaggio C, ed è il linguaggio con il quale è scritto il framework Cocoa[g] di Apple. • Python È un linguaggio di programmazione ad alto livello, orientato agli oggetti, adatto, tra gli altri usi, a sviluppare applicazioni distribuite, scripting, computazione numerica e system testing.

Capitolo 3

Organizzazione dello stage

Nel presente capitolo si riportano le varie fasi del progetto di stage. Tali fasi sono state organizzate sul modello del documento "piano di lavoro".

3.1 Piano di lavoro

Per poter suddividere il progetto di stage in fasi più piccole e meglio gestibili, si è fatto affidamento al documento "piano di lavoro" che era stato redatto prima dell’avvio dello stage e concordato con il tutor aziendale. Di seguito si riporta il diagramma di Gantt che mostra come sia stato suddiviso il monte ore di 320 ore.

Figura 3.1: Diagramma di Gantt per il progetto di stage

3.2 Fasi del progetto

Di seguito sono elencate le fasi tramite le quali è stato organizzato il progetto di stage: • Introduzione e avvio del progetto Questa fase comprendeva come prima sotto-attività la presentazione del contesto aziendale e il conseguente inserimento del candidato all’interno di essa. A seguito di ciò, è stata presa visione di quanto esistente del progetto Hydrogen, come ad esempio la componente realizzata per il sistema operativo Microsoft Windows e Ubuntu Linux. • Analisi Durante questa fase sono state analizzate nel dettaglio tutte le informazioni

13 14 CAPITOLO 3. ORGANIZZAZIONE DELLO STAGE

raccolte nella fase precedente. A questo punto è stata avviata l’attività "studio di fattibilità" del progetto, avendo già chiari i requisiti che il componente da realizzare deve soddisfare. Alcune difficoltà sono state incontrate per quanto riguarda la poca documentazione (e difficile da reperire) riguardo alla possibilità di modificare la schermata di login del sistema macOS per aggiungere controlli personalizzati (come ad esempio un pulsante). Successivamente era prevista la formalizzazione dei casi d’uso. Questi servivano per definire nel dettaglio tutte le interazioni che un possibile utente avrebbe potuto avere con il componente. Inoltre costituivano una valida base di partenza per definire e successivamente tracciare i requisiti del prodotto. Durante questa fase sono stati analizzati i vari modi che era possibile seguire per sviluppare la componente, tra le quali ne andava scelto uno in modo da poi passare alle successive fasi di progetto. Durante questa fase è stata anche iniziata l’attività di documentazione.

• Progettazione La progettazione è stata affrontata sia tramite una progettazione architetturale che una progettazione di dettaglio. Nella progettazione architetturale si sono fatte le scelte ad alto livello per quanto riguarda quali classi realizzare e in che modo queste devono comunicare tra loro. Mentre nella progettazione di dettaglio sono state formalizzate le singole classi del programma, con tutti i metodi e le varie interazioni tra loro. • Implementazione A seguito della scelta di uno dei metodi per lo sviluppo del componente, si è proceduto alla fase di sviluppo del codice. A seguito della codifica del componente, è stato creato il relativo installer. • Verifica e validazione Sono stati formalizzati i test d’unità e di sistema per accertarsi di produrre software funzionante, e che rispetti i vincoli definiti nella fase di Analisi. L’ultima parte era il collaudo finale in presenza del tutor aziendale.

• Chiusura del progetto L’ultima fase prevedeva il completamento di tutti i documenti creati ai fini di documentazione del progetto. Inoltre era richiesta la stesura di un documento di fine stage che riassumesse in generale lo stato di conclusione del progetto, indi- cando gli obiettivi raggiunti, quelli eventualmente non raggiunti, e le prospettive di ampliamento future. Capitolo 4

Analisi dei requisiti

La fase di analisi ha considerato sia il software esistente di Hydrogen, in modo da ottenere tutti gli obiettivi da raggiungere con il progetto, che un’analisi della documentazione del sistema operativo macOS per quanto riguarda la possibilità di estendere/modificare la schermata di login del sistema per visualizzare un pulsante che al click mostri una nuova finestra di browser limitato.

4.1 Analisi delle caratteristiche del prodotto finale

Questa prima attività è partita considerando come sia possibile modificare/estendere la schermata di login di macOS, in quanto l’idea era (in linea teorica) di aggiungere un pulsante custom che permetta di aprire una finestra di browser che mostri il sito di Hydrogen.

4.1.1 Possibili approcci per lo sviluppo del componente A tal proposito sono state effettuate varie ricerche, e si è arrivati a considerare due diversi approcci per lo sviluppo del componente:

• Sviluppare un Pre-Logon Agent: In questo caso, il Pre-Logon Agent è come una applicazione desktop sviluppata (tramite Xcode) per la piattaforma macOS, che viene eseguita durante la fase di login. A tal proposito, l’applicazione viene avviata durante la fase di login grazie al processo di sistema Launchd[g] . Tale applicazione consisterebbe di un unico pulsante visualizzato a schermo che permette di aprire una nuova finestra di browser, e tale pulsante non sarebbe "inserito" all’interno di qualche componente della schermata di login, ma sarebbe semplicemente visualizzato al di sopra della schermata esistente rimanendo comunque indipendente da essa. La soluzione è stata creata sul modello dell’esempio 1 disponibile.

• Sviluppare un Authorization plug-in: Il plug-in permette di rimpiazzare il form di login di sistema predisposto nella

1PreLogonAgent Example. url: https://developer.apple.com/library/archive/samplecode/ PreLoginAgents/Introduction/Intro.html

15 16 CAPITOLO 4. ANALISI DEI REQUISITI

finestra di login, con un altro form realizzato (sempre tramite Xcode) grazie alla classe 2, che è stata appositamente creata a tale scopo. In questo modo è possibile visualizzare un pulsante che ha lo scopo di aprire una nuova finestra di browser, e tale pulsante è posizionato vicino alle altre componenti grafiche del form (campi per l’inserimento di username e password).

Le considerazioni sull’approccio dei Pre-Logon Agent sono riportate alla sezione 4.5.2, mentre le considerazioni sullo sviluppo di un Authorization plug-in sono riportate alla sezione 4.5.1.

4.1.2 Criteri di valutazione per la scelta della soluzione da sviluppare Sono stati valutati entrambi gli approcci per trovare quello che avrebbe permesso di raggiungere gli obiettivi prefissati nel miglior modo possibile rispettando le scadenze. Alcuni dei criteri usati per la valutazione di ciascun approccio sono elencati di seguito:

• Livello di compatibilità con le varie versioni di macOS.

• Facilità di sviluppo della soluzione (che avrebbe permesso di ottenere un manuale sviluppatore di più facile comprensione), preferendo l’utilizzo del linguaggio Swift rispetto a Objective-C il più possibile.

• Facilità nello sviluppo del relativo installer.

• Facilità nello svolgimento delle attività di testing e debug.

4.1.3 Considerazioni sul browser da adottare Visto che la user interface di Hydrogen necessita di un browser web, è apparso chiaro che era sufficiente fare in modo che venisse aperta una nuova finestra di browser limitato e compatibile sulla schermata di login.

I requisiti di Hydrogen riguardo alla compatibilità con i vari browser è risultata essere:

• Internet Explorer 8 e superiori.

• Google Chrome 34 e superiori.

• Safari 7 e superiori.

• Mozilla Firefox 8 e superiori.

Essendo macOS il sistema target, si è arrivati a considerare Safari e comunque delle solzioni che sfruttassero le librerie native messe a disposizione da macOS a tale scopo. Da questa considerazione è stato valutato che è possibile sfruttare direttamente la classe 3 che si basa sul motore 4 per visualizzare una nuova finestra di browser.

2SFAuthorizationPluginView. url: https : / / developer . apple . com / documentation / securityinterface/sfauthorizationpluginview 3WKWebView. url: https://developer.apple.com/documentation/webkit/wkwebview 4WebKit. url: https://webkit.org/ 4.2. ACTIVE DIRECTORY SU MACOS 17

4.2 Active Directory su macOS

Uno dei punti da capire era come poter fare login su macOS autenticandosi come un utente appartenente al dominio Active Directory dell’azienda. Il progetto di stage ha proprio lo scopo di poter permettere il reset autonomo di password per utenti registrati su Active Directory, e non gli utenti registrati localmente su un PC macOS.

È stato possibile collegare il PC macOS usato a scopo di sviluppo ad un dominio Active Directory in vari modi, uno tra i quali è stato direttamente dall’utility Utility Directory 5. In seguito è stato possibile eseguire il login tramite un account di rete selezionandolo dalla lista degli utenti nella finestra di login.

4.3 Casi d’uso

Per lo studio dei casi di utilizzo del prodotto sono stati creati dei diagrammi UML[g] dedicati alla descrizione delle funzioni o servizi offerti dal sistema, così come sono percepiti e utilizzati dagli attori che interagiscono col sistema stesso. I diagrammi dei casi d’uso realizzati sono stati molto semplici e immediati, in quanto è stato individuato un singolo attore chiamato "Utente" che può compiere una quantità di azioni molto limitate.

4.3.1 Caso d’uso principale Di seguito si riporta il caso d’uso principale del prodotto, cioè l’utente che ha la possibilità di poter cliccare un pulsante che apre una finestra del browser direttamente dalla schermata di login di macOS.

Figura 4.1: Use Case - UC1: Scenario principale

4.4 Tracciamento dei requisiti

A seguito dell’analisi dei requisiti e degli use case effettuata sul progetto, sono state stilate delle tabelle che tracciano i requisiti in relazione alla loro provenienza. Sono stati individuati diversi tipi di requisiti e si è quindi fatto utilizzo di un codice identificativo per distinguerli. Sono state identificate quattro categorie di requisiti: F = Funzionali (descrivono una funzionalità offerta dal software) Q = Qualità (descrivono una qualità minima che il software deve possedere)

5https://support.apple.com/it-it/guide/directory-utility/welcome/mac 18 CAPITOLO 4. ANALISI DEI REQUISITI

P = Prestazionali (descrivono i requisiti di tipo prestazionale che il prodotto deve soddisfare)

V = Vincolo (descrivono i vincoli che il software deve rispettare)

L’importanza dei requisiti è rappresentata nel seguente modo:

N = obbligatorio

D = desiderabile

Z = opzionale

Per identificare i requisiti è stato fatto uso della seguente nomenclatura: R{Categoria}{Importanza}-{Numero}.

Nelle tabelle 4.1e 4.2 sono riassunti i requisiti assieme alla loro provenienza.

Tabella 4.1: Tabella del tracciamento dei requisti funzionali

Requisito Descrizione Provenienza RFN-2. La pressione di un pulsante deve aprire una UC1 finestra di browser a tutto schermo RFN-3 L’installer (grafico e silente) deve permette- Vincoli del progetto re all’utente di specificare l’URL del server di Hydrogen

Tabella 4.2: Tabella del tracciamento dei requisiti di vincolo

Requisito Descrizione Provenienza RVN-4 Il browser deve essere limitato Vincoli del progetto (mostrare solo il sito di Hydrogen), per cui non deve: mostrare la bar- ra degli indirizzi, il pulsante dei preferiti e i pulsanti "avanti" ed "indietro". RVN-5 Il prodotto deve funzionare su Vincoli del progetto macOS Mojave RVN-6 L’installer (grafico e silente) ese- Vincoli del progetto gue l’installazione del software so- lo se eseguito dall’amministratore del computer RVZ-7 Il prodotto deve funzionare su tut- Vincoli del progetto te le versioni di macOS (antece- denti la versione Mojave) che sono ancora supportate da Apple 4.5. APPROCCI PER LA CREAZIONE DEL COMPONENTE 19

4.5 Approcci per la creazione del componente

Come citato in precedenza, sono stati analizzati due approcci che era possibile seguire per lo sviluppo del componente, e per primo si discute riguardo alla creazione di un Authorization plug-in.

4.5.1 Authorization plug-in La base di questa soluzione deriva da una demo prodotta da Apple chiamata "Na- meAndPassword" 6, che dimostra come sia possibile (derivando la classe SFAuthoriza- tionPluginView 7) creare un plug-in di autorizzazione che vada a rimpiazzare il processo di login predisposto dal sistema. Ad esempio, risulta utile per creare procedimenti di login alternativi (tramite lettore di impronte, dispositivi esterni di autenticazione, etc). La soluzione è codificata interamente in linguaggio Objective-C (e non Swift) per via del fatto che al momento non è sicuro implementare un plug-in di autorizzazione in Swift per possibili problemi di incompatibilità a runtime con altri processi di sistema.

Una visione di insieme di questa soluzione è data dal seguente diagramma UML di package che illustra la sua composizione:

Figura 4.2: Diagramma dei package per l’authorization plug-in

Il progetto è composto dai seguenti file: • AuthPlugin.{h,m} Questa parte contiene il codice che gestisce la chiamata invoke che viene fatta dalla loginwindow[g] , e inizializza la view del plugin (in particolare il form che verrà visualizzato sulla schermata di login). Questa classe ha lo stesso contenuto di codice rispetto alla rispettiva classe del progetto demo indicato in precedenza. • NameAndPasswordPlugin.{h,m} Definisce una classe che eredita dalla classe SFAuthorizationPluginView 7 citata in precedenza. La classe quindi definisce il nuovo form che andrà a sostituire il form

6 https://developer.apple.com/library/archive/samplecode/NameAndPassword/Introduction/Intro.html 20 CAPITOLO 4. ANALISI DEI REQUISITI

di login del sistema; contiene quindi due campi di testo uno per l’inserimento della username, e uno per l’inserimento della password. Secondo la documentazione, la classe che estende il tipo SFAuthorizationPlugin- View 7 deve anche ri-definire i metodi buttonPressed e viewForType. Il primo di questi (buttonPressed) viene richiamato ogni qualvota un pulsante viene premuto all’interno del plug-in, in questo modo è possibile distinguere se l’utente ha premuto il pulsante per effettuare il login (pulsante rappresentato con la freccia ’->’) oppure ha premuto il pulsante per la cancellazione (rappresentato dalla freccia ’<’ per tornare alla schermata con tutti gli utenti). Nel caso di intenzione di effetture il login, viene presa la coppia username/password e fatto un tentativo di login dell’utente nel database di autenticazione del sistema. Se la coppia username/password è valida, in quel caso l’utente viene correttamente autenticato.

Il metodo viewForType invece si occupa di presentare la View corretta a seconda dello stato della finestra di login: se è necessario elencare tutti gli utenti presenti nel sistema viene visualizzato un elenco che mostra solo la username (e la casella per la password viene nascosta) dei singoli utenti; mentre se l’utente ha selezionato un utente dalla lista allora viene presentata un’altra View con i due campi per l’inserimento della username/password. Questa classe contiene (oltre al codice originario) alcuni metodi di prova utilizzati per testare la visualizzazione di una nuova finestra a schermo intero direttamente dalla schermata di login.

• plugin-objc.{h,m} Contiene metodi che gestiscono la creazione/distruzione del plugin. In particolare all’interno del file "plugin-objc.m" è definita l’interfaccia AuthorizationPluginIn- terface 8, che definisce i nomi dei vari metodi (definiti sempre all’interno del medesimo file) necessari al motore di autorizzazione per gestire il ciclo di vita del plug-in (creazione, distruzione, etc). Questa classe ha lo stesso contenuto di codice rispetto alla rispettiva classe del progetto demo indicato in precedenza.

• TestWindow.{h,m} Rappresenta la View della classe di prova utilizzata per testare la visualizzazione di una finestra a schermo intero sulla schermata di login.

Per poter testare l’apertura di una nuova finestra è stato predisposto il pulsante con la scritta "Hydrogen" come visibile nella figura 4.3.

7https://developer.apple.com/documentation/securityinterface/ sfauthorizationpluginview 8https://developer.apple.com/documentation/security/authorizationplugininterface?language=objc 4.5. APPROCCI PER LA CREAZIONE DEL COMPONENTE 21

Figura 4.3: Schermata che rappresenta il form di login ottenuto con il plug-in.

Installazione componente Per l’installazione del componente sono stati eseguiti i seguenti passaggi:

1. copia del file .bundle dell’applicazione (risultante dalla compilazione del progetto nell’IDE Xcode) nel percorso di sistema /Library/Security/SecurityAgentPlugins.

2. cambio del proprietario del file .bundle copiato in precedenza, rendendo l’utente "root" il proprietario. A tal proposito era stato usato il seguente comando:

sudo chown -R root:wheel /Library/Security/ SecurityAgentPlugins/HydrogenPlugin.bundle

¥ 3. cambio dei permessi del file tramite il seguente comando:

sudo chmod -R 755 /Library/Security/ SecurityAgentPlugins/HydrogenPlugin.bundle

¥ 4. lettura del contenuto del file di sistema denominato security.login.console tramite il seguente comando:

security authorizationdb read system.login.console > system .login.console.custom.txt

¥ 5. Modifica del file di testo creato in precedenza (system.login.console.custom.txt) rimpiazzando la riga "loginwindow:login" con "HydrogenPlugin:invoke". A segui- to di ciò è necessario sostituire il file di sistema (security.login.console) con quello modificato tramite il seguente comando:

sudo security authorizationdb write system.login. console < system.login.console.custom.txt

Quest’ultima operazione permette di scambiare il form di login di sistema con ¥ il form creato tramite il plug-in, infatti "loginwindow:login" è la direttiva che avvia il form di login di sistema, che viene sostituito con il nuovo form tramite la direttiva "HydrogenPlugin:invoke" (definita nel file AuthPlugin). 22 CAPITOLO 4. ANALISI DEI REQUISITI

Considerazioni riguardo alla soluzione Authorization plug-in Per quanto riguarda questa soluzione esistono delle considerazioni che hanno portato a cercare soluzioni alternative. Di seguito sono elencati i motivi principali: • Complessità nel provare le modifiche alla componente e farne il debug, in quanto l’unico modo per fare ciò è eseguire il log out e rifare il login. Inoltre, nel caso di malfunzionamenti gravi del componente, l’utente non è più in grado di eseguire il login lasciando come unica soluzione la re-installazione completa del sistema operativo (a tal proposito era stata usata una macchina virtuale che facilitava il ripristino ad uno stato precedente del sistema operativo). • Il fatto che il form di login di sistema venga sostituita con un’altra non è stata considerata come una cosa positiva, in quanto l’aspetto delle componenti grafiche (ad esempio i campi per l’inserimento di username e password) non risulta identico come quello che si ha nel form presente di default. • Complessità della soluzione (soprattutto per la mancanza di commenti/docu- mentazione) e necessità di possedere una conoscenza approfondita del linguaggio Objective-C se si ha la necessità di modificare il processo di login. • Impossibilità di usare codice Swift (che presenta una sintassi più moderna e facile da leggere) per codificare il plug-in.

4.5.2 Pre-Logon Agents Questa tipologia di soluzione è stata subito ben vista per via della semplicità di sviluppo e testing, cosa che nell’altra soluzione era molto complicata e laboriosa. Quest’approccio permette di realizzare un’applicazione dotata di interfaccia grafica (GUI) che è possibile avviare durante la fase di login di sistema, mantenendo intatta la schermata di login così come di default, e visualizzando un pulsante che si pone al di sopra degli altri elementi di sistema già pre-esistenti.

Di seguito si fa un’introduzione al processo di sistema denominato Launchd[g] che rende possibile l’implementazione di questa tipologia di soluzione.

Il processo Launchd Launchd è un framework open-source che nei sistemi operativi macOS avvia i servizi di base del computer e permette all’utente di effettuare il login. Inoltre permette di avviare, fermare e gestire sia daemon, applicazioni che processi. La prima versione di macOS a dotarsi di questo framework è stata macOS X Tiger. Di seguito si sintetizza la differenza tra un daemon e un agent: • Daemon: applicazione (priva di GUI ) eseguita in background senza bisogno di interazione con l’utente. Un esempio tipico di daemon è un programma che esegue quotidianamente dei task di manutenzione. • Agent: viene eseguito per conto dell’utente attualmente autenticato nel sistema, a differenza di un daemon che viene eseguito per conto dell’utente root o un altro utente specificato tramite la proprietà "UserName" presente all’interno del file di configurazione (che ha formato ".plist") del daemon. Un agent, inoltre, ha la possibilità di possedere una interfaccia grafica (GUI). Inoltre, un agent può essere eseguito per conto di tutti gli utenti presenti nel 4.5. APPROCCI PER LA CREAZIONE DEL COMPONENTE 23

sistema se il relativo file "property list" viene copiato nella cartella di sistema /Library/LaunchAgents/.

Tipologie di attività Il comportamento di un daemon/agent è specificato in un file XML[g] chiamato "property list" (con estensione ".plist"). Il posizionamento del file in questione all’interno di alcune directory di sistema (descritte di seguito), determina se l’attività sarà trattata come un daemon o un agent. Ad esempio per le attività del sistema operativo, i vari file del tipo "property list" sono posizionati al percorso /System/Library. Per quanto riguarda attività non di sistema, queste possono essere definite al percorso /Library ; mentre quelle specifiche per un utente sono situate nella cartella ~/Library (il carattere "~" indica la directory home dell’utente).

La tabella 4.3 mostra la differenza tra i vari percorsi per quanto riguarda la defi- nizione di attività (le directory descritte indicano le possibili destinazioni per i file "property list" di un’attività).

Tabella 4.3: Tabella che illustra i percorsi interpretati da Launchd

Tipo Percorso Eseguito per conto di User Agents ~/Library/LaunchAgents Utente attualmente autentica- to Global Agents /Library/LaunchAgents Utente attualmente autentica- to Global Daemons /Library/LaunchDaemons Utente root oppure quello specificato tramite la chiave "UserName" System Agents /System/Library/ Utente attualmente autentica- LaunchAgents to System Daemons /System/Library/ Utente root oppure quello spe- LaunchDaemons cificato tramite la proprietà "UserName"

Definizione di un’attività E’ possibile definire un’attività specificando le seguenti tre proprietà nel relativo file "property list":

• Label: Da specificare obbligatoriamente. Identifica univocamente l’attività rendendola identificabile da Launchd.

• Program: Specifica cosa avviare (nell’esempio seguente uno script shell presente al percorso /Users/Me/Scripts/cleanup.sh).

• RunAtLoad: Specifica in che momento l’attività deve iniziare (nell’esempio si specifica di iniziare l’attività appena è stata caricata).

Di seguito si riporta l’esempio a cui è stato fatto riferimento: 24 CAPITOLO 4. ANALISI DEI REQUISITI

Figura 4.4: Esempio di definizione di un’attività.

Caricamento di definizioni delle attività Durante l’avvio del sistema, il pro- cesso Launchd scansiona le cartelle /System/Library/LaunchDaemons e /Library/ LaunchDaemons in cerca di definizione di attività (del tipo daemon).

All’avvio della schermata di login, invece vengono scansionate le cartelle /System/ Library/LaunchAgents, /Library/LaunchAgents e ~/Library/LaunchAgents in cer- ca di definizioni di attività (del tipo agent) da caricare.

Caricamento vs Avvio di attività Durante la fase di caricamento dell’attività, non necessariamente essa viene avviata immediatamente. L’avvio effettivo è determinato dalla definizione del suo file "property list". Infatti solo se le proprietà "RunAtLoad" o "KeepAlive" sono specificate, il processo Launchd avvierà l’attività appena questa è stata caricata.

Considerazioni sull’approccio dei PreLogon Agents Questa tipologia di solu- zione, come citato in precedenza, è stata favorita rispetto alla soluzione Authorization plug-in per i principali motivi elencati di seguito:

• Semplicità nel provare le modifiche alla componente e farne il debug, in quanto non era necessario fare il log-out dal sistema per provare ogni modifica. Essendo un’applicazione desktop, era possibile provare le modifiche direttamente eseguendo l’applicazione dall’IDE Xcode. • Semplicità della soluzione, in quanto non è stata modificata alcuna componente del sistema. • Possibilità di codificare tutto il componente in linguaggio Swift. • Semplicità nella realizzazione dell’installer (sia grafico che silente) rispetto alla versione Authorization plug-in.

A seguito di queste considerazioni (assieme al tutor aziendale), si è deciso quindi di implementare una soluzione del tipo PreLogon Agent. Capitolo 5

Progettazione e codifica

Il presente capitolo tratta della progettazione e codifica dell’agent MacLogonAgent, che è la soluzione che è stato deciso di realizzare e portare a termine scartando la soluzione "Authorization plug-in".

5.1 Tecnologie e strumenti

Di seguito viene data una panoramica delle tecnologie e strumenti utilizzati per portare a termine la realizzazione dell’agent oltre a quelli citati nella sezione 2.4.

IDE Xcode e tool "Packages"

Per la creazione della parte Core di MacLogonAgent e’ stato fatto uso dell’IDE Xcode reso disponibile da Apple. Tramite questo IDE e’ risultato possibile la creazione di un PreLogon Agent codificato in linguaggio Swift. Inoltre anche per il progetto identificato dal package denominato "MacLogonAgent.Installer.RequestURL" è stato usato l’IDE in questione, e in questo caso il codice è stato scitto in linguaggio Objective-C per mantenere la compatibilità con l’installer grafico realizzato con il tool "Packages" 1.

Microsoft Visual Studio Code

Per la realizzazione dell’installer silente è stato fatto uso del linguaggio Python, utilizzando come ambiente di sviluppo l’editor Visual Studio Code.

5.2 Progettazione

La soluzione sviluppata viene identificata con il nome "MacLogonAgent" e può essere descritta con il seguente diagramma UML dei package:

1http://s.sudre.free.fr/Software/Packages/about.html

25 26 CAPITOLO 5. PROGETTAZIONE E CODIFICA

Figura 5.1: Diagramma dei package di MacLogonAgent

Per fare riferimento alle varie componenti del progetto si farà riferimento al nome del relativo package: MacLogonAgent è il package principale che si riferisce a tutta la soluzione software sviluppata.

5.2.1 Struttura del progetto Di seguito sono elencate le componenti che costituiscono il progetto:

• MacLogonAgent.Core: progetto di tipo Cocoa realizzato con l’IDE Xcode (in linguaggio Swift); questo progetto contiene tutto il necessario per mostrare un pulsante cliccabile sulla schermata di login di macOS, che una volta cliccato apre una finestra del browser con la pagina identificata dall’URL inserito in fase di installazione.

• MacLogonAgent.Installer: progetto realizzato con il tool "Packages" che con- siste di un installer grafico che permette di installare il prodotto MacLogonAgent su macOS.

• MacLogonAgent.Installer.RequestURL: progetto (sviluppato in Objective- C) basato sul template "Installer Plug-in" reso disponibile da Xcode, il cui file .bundle (che viene generato a seguito della compilazione del progetto) viene incorporato all’interno dell’installer grafico per chiedere all’utente di inserire l’URL del server di Hydrogen. Questo progetto è stato creato per personalizzare il processo di installazione standard aggiungendo un’ulteriore schermata al processo di installazione.

5.2.2 Namespace "MacLogonAgent.Core" Per descrivere questo namespace e le sue componenti, si è creato il seguente diagramma delle classi: 5.2. PROGETTAZIONE 27

Figura 5.2: Diagramma delle classi del namespace "MacLogonAgent.Core".

Ulteriori file di supporto A supporto di questo progetto sono stati creati i seguenti file:

• MacLogonAgent_Core.plist: Si tratta di un file plist con formato XML. Questo file è stato definito in modo che possa essere interpretato dal processo Launchd durante la fase di login di macOS. Il file ha la seguente struttura:

Figura 5.3: Descrizione file MacLogonAgent_Core.plist.

Il file sarà presente al seguente percorso una volta che l’agent è stato in- stallato: /Library/PrivilegedHelperTools/MacLogonAgent.app/Contents/ Resources/MacLogonAgent_Core.plist.

Di seguito una descrizione di alcune delle proprietà elencate in questo file:

– "LimitLoadToSessionType": imposta l’applicazione come un pre-logon agent che viene eseguito nel contesto del login di sistema; il valore associato a questa chiave è in questo caso la keyword "LoginWindow", che rappresenta il contesto di login. – "KeepAlive": permette all’applicazione di risultare visibile (se impostata con valore "true") all’interno della schermata di login; il valore associato a questa chiave è quindi "true". – "ProgramArguments": indica il percorso dove è presente l’eseguibile dell’ap- plicazione da avviare durante la fase di login. In questo caso al percorso indicato visibile nell’immagine è presente un file con estensione .app (quindi MacLogonAgent.app) che rappresenta il "application bundle" che può essere avviato come un’applicazione desktop. 28 CAPITOLO 5. PROGETTAZIONE E CODIFICA

• Hydrogen_Conf.plist: Si tratta di un file plist che contiene il valore dell’URL che l’utente ha specificato durante la fase di installazione. Questo valore è identi- ficato dalla chiave "URL_Hydrogen". Questo file viene letto dall’agent quando l’utente fa click sul pulsante che apre la finestra Web. Il file in questione sarà presente al seguente percorso una volta che l’agent è stato installato: /Library/PrivilegedHelperTools/MacLogonAgent.app/Contents/ Resources/Hydrogen_Conf.plist. • Info.plist: Il file è autogenerato dall’IDE Xcode, e l’unica aggiunta a questo file è stata la proprietà "NSAllowsArbitraryLoads" impostata con valore "true"; questa proprietà permette dal browser di navigare anche link HTTP (oltre a quelli HTTPS), in quanto le impostazioni di sicurezza delle versioni più recenti di macOS non permettono di default di aprire link HTTP non sicuri. Il file sarà presente al seguente percorso a seguito dell’installazione dell’agent: /Library/PrivilegedHelperTools/MacLogonAgent.app/Contents/Info.plist.

Descrizione delle classi

FileOperations: Classe astratta che dichiara le operazioni che è possibile fare su un file, in questo caso queste operazioni sono lettura/scrittura. FileOperations_Plist: Classe derivata dalla classe base FileOperations, che imple- menta le varie operazioni dichiarate nella classe base, in modo da poter operare su un file "property list" (con estensione .plist). In particolare per poter operare su un file con estensione .plist (che è un file XML) lo si è trattato come un oggetto dictionary, rendendo così facilmente realizzabili le operazioni citate in precedenza. ViewController: Classe controller principale dell’intera applicazione. Durante la fase di inizializzazione della grafica dell’applicazione viene impostata la proprietà "canBecomeVisibleWithoutLogin" 2 della finestra della View principale impo- standolo con valore "true". Tramite questo attributo è possibile specificare se la finestra possa essere visibile, o meno, sulla schermata di login di sistema. Inoltre, sempre in fase di inizializzazione, è stata impostata la proprietà "order- Front" 3 della finestra della View principale per indicare di spostarla davanti ad altre eventuali finestre aperte in modo da non venire nascosta da queste. La finestra, corrispondente a questo controller, che viene mostrata sulla schermata di login di sistema è la seguente:

Figura 5.4: Pulsante principale che permette di aprire il browser

2https://developer.apple.com/documentation/appkit/nswindow/1419179- canbecomevisiblewithoutlogin 3https://developer.apple.com/documentation/appkit/nswindow/1419495-orderfront 5.2. PROGETTAZIONE 29

Il pulsante in questione viene visualizzato nell’angolo inferiore sinistro della finestra di login di sistema, ed è inoltre possibile spostarlo in altre posizioni. WebViewController: Classe controller per la gestione di una finestra Web a schermo intero. Anche qui durante la fase di inizializzazione della View, si è impostato a "true" la proprietà "canBecomeVisibleWithoutLogin" 4 della finestra contenente la View. Inoltre, sempre riferendosi alla finestra, è stata impostata la proprietà "level" con un valore molto alto in modo che possa risultare visibile sopra al pulsante principale di MacLogonAgent (descritto in precedenza). La schermata del browser che si presenta a seguito del click del pulsante appare nel modo seguente:

Figura 5.5: Schermata del browser

Dopo l’inizializzazione della finestra del browser, si legge dal file Hydrogen_Conf.plist l’URL da aprire e viene aperto il collegamento. AppDelegate: Gestisce lo stato di esecuzione dell’applicazione. In questo caso è stato definito un signal handler che si occupa di terminare l’intera applicazione nel caso riceva un signal di tipo SIGTERM.

5.2.3 Namespace "MacLogonAgent.Installer.Core" Il namespace in questione identifica il progetto che permette di ottenere l’installer grafico; quest’ultimo è stato creato sfruttando il tool open-source denominato "Pac- kages". Il codice sorgente di questo tool è disponibile al link (https://github.com/ packagesdev/packages), mentre un manuale utente è disponibile al link (http://s. sudre.free.fr/Software/documentation/Packages/en_2017/index.html). Que- sto tool permette anche di specificare degli script da avviare durante la fase "pre-install"

4https://developer.apple.com/documentation/appkit/nswindow/1419179- canbecomevisiblewithoutlogin 30 CAPITOLO 5. PROGETTAZIONE E CODIFICA

(prima dell’installazione) e "post-install" (dopo l’installazione). Il processo di installazione viene descritto in una sezione successiva.

5.2.4 Namespace "MacLogonAgent.Installer.RequestURL" Rappresenta il progetto che permette di personalizzare il processo di installazione dell’installer grafico; viene infatti aggiunta una schermata che permette all’utente (tramite una text field) di inserire l’URL del server di Hydrogen. L’URL in questione viene salvato nel campo identificato dalla chiave "URL_Hydrogen" in un file temporaneo denominato "urlHydrogen.plist" creato nella directory /tmp del sistema. A partire da questo file temporaneo si va (tramite uno script di tipo "post-install") a recuperare il valore dell’URL e salvarlo nel file Hydrogen_Conf.plist ( da cui viene letto durante l’esecuzione dell’agent). Di seguito una schermata che illustra lo step in questione dell’installer grafico:

Figura 5.6: Schermata dell’installer grafico

Descrizione delle classi Il progetto è composto principalmente da una classe denominata "InstallerPane".

InstallerPane: Classe con funzione di controller che gestisce il salvataggio su file del- l’URL ottenuto dalla text field. Il salvataggio viene effettuato sul file temporaneo "urlHydrogen.plist" descritto in precedenza.

5.3 Codifica

L’attività di codifica si è svolta in modo molto lineare, in quanto durante la fase di analisi dei requisiti si era arrivati a confermare la fattibilità della soluzione e il fatto che essa poteva soddisfare tutti quanti i requisiti. 5.3. CODIFICA 31

L’attività in questione quindi è stata svolta affrontando prima i requisiti obbligatori (in modo da dedicare più tempo in caso di qualche ostacolo) fino ad arrivare a quelli facoltativi.

5.3.1 Installer per l’agent Come voluto dai requisiti, l’installer è stato realizzato sia in versioni grafica che silente (eseguibile da terminale).

Risultato dell’installazione A seguito dell’installazione, nel file system si trovano i seguenti file:

• La cartella dell’applicazione, cioè "MacLogonAgent.app", viene copiata al per- corso /Library/PrivilegedHelperTools/MacLogonAgent.app. La directory di sistema /Library/PrivilegedHelperTools/ ha lo scopo di con- tenere applicazioni che vengono avviate dal processo Launchd con permessi di root.

• Il file "MacLogonAgent.plist" viene copiato al percorso /Library/LaunchAgents/ MacLogonAgent.plist.

Script "post-install" usati dall’installer grafico • "postInstall.py": contiene delle funzioni che vanno a recuperare il valore del- l’URL di Hydrogen salvato nel file presente al percorso \tmp\urlHydrogen.plist e salvarlo all’interno del file "Hydrogen_Conf.plist" descritto in precedenza. Questo script viene eseguito automaticamente nella fase dopo che il file .bundle dell’applicazione viene copiato nella cartella di destinazione. Di seguito un diagramma di classe che illustra la struttura di questo script:

Figura 5.7: Script "postInstall.py"

Script usati dall’installer silente • "silentInstall.py": permette l’installazione dell’agent tramite terminale. Ri- chiede dei parametri che permettono di specificare il percorso dove è presente il file .bundle dell’applicazione e l’URL di Hydrogen da salvare. Di seguito un diagramma di classe che ne illustra la struttura: 32 CAPITOLO 5. PROGETTAZIONE E CODIFICA

Figura 5.8: Script "silentInstall.py"

Script di disinstallazione • "uninstall.py": permette di disinstallare l’agent dal sistema. Di seguito un diagramma di classe relativo a questo script:

Figura 5.9: Script di disinstallazione "uninstall.py"

Script per modificare l’URL di Hydrogen salvato • "changeURL.py": permette di modificare l’URL di Hydrogen che era stato specificato durante la fase di installazione. Di seguito un diagramma di classe relativo a questo script:

Figura 5.10: Script di modifica dell’URL “changeURL.py” Capitolo 6

Verifica e validazione

6.1 Test

I test realizzati sono stati di 2 tipi:

• Test di unità

• Test di sistema

6.1.1 Test di unità I test di unità hanno riguardato principalmente le funzioni che vanno a leggere/scrivere sui vari file di configurazione. I test hanno seguito la seguente logica:

• è stata realizzata una classe di test per ogni classe che opera con i file.

• le classi di test possiedono un metodo di test per ciascuna funzione del codice sviluppato da testare.

• un test è stato considerato superato se l’operazione di lettura/scrittura su file forniva il risultato atteso.

Progetti creati con Xcode Per i progetti creati con Xcode, è stata sfruttata la possibilità di definire dei test di unità direttamente dall’IDE, e perciò sono state definite delle funzioni specifiche per testare ogni singola operazione e confrontare il valore atteso con quello letto/scritto.

Codice scritto in Python Per quanto riguarda i vari script in Python, è stata creata una classe di test per ogni script, in modo da testare tutte le funzioni definite all’interno di questi. A tal proposito le classi di test fanno riferimento al modulo unittest 1 incluso nelle librerie ufficiali del linguaggio.

1https://docs.python.org/2/library/unittest.html

33 34 CAPITOLO 6. VERIFICA E VALIDAZIONE

6.1.2 Test di sistema Per quanto riguarda l’agent, un test principale è stato provare che il pulsante sia visibile sulla schermata di login di sistema in versioni differenti di macOS, e che al suo click sia possibile aprire una nuova finestra a schermo intero. Oltre a ciò è stato testato che il browser si apra con la pagina che l’utente ha specificato durante la fase di installazione. A tal proposito sono state provate varie macchine macOS con versioni che vanno dalla 10.10 Yosemite fino alll’ultima release disponibile 10.14 Mojave. In tutte le diverse versioni, l’agent ha mostrato sempre lo stesso comportamento sia in fase di installazione (tramite installer grafico e quello silente) che nell’utilizzo. Tramite questa tipologia di test è stato accertato che sono stati coperti i requisiti definiti con l’attività di analisi. Questi test, essendo di tipo funzionale, accertano che non sia sfuggita nessuna delle caratteristiche stabilite per il prodotto. Al termine di questi, è avvenuto il collaudo in presenza del tutor aziendale: prima è stato provato il processo di installazione, e poi il funzionamento di MacLogonAgent. Capitolo 7

Documentazione

Come previsto dagli obiettivi di progetto e dal documento "piano di lavoro", al termine dell’attività di codifica sono stati stilati i vari manuali previsti: manuale utente e manuale sviluppatore (entrambi con una versione in lingua inglese e una in italiano).

7.1 Manuale utente

Tramite il manuale utente si è descritto come installare l’agent sul sistema, e in seguito, come utilizzarlo; sono state inoltre fornite delle indicazioni su come comportarsi nel caso si verifichino delle situazioni particolari (ad esempio la pagina Web non viene caricata, il browser mostra una pagina vuota, etc). Di seguito si fornisce un estratto del manuale utente:

Figura 7.1: Schermata del manuale utente in italiano

7.2 Manuale sviluppatore

Per quanto riguardo il manuale sviluppatore, sono state riportate tutte le informazioni riguardo all’ambiente di sviluppo e le varie tecnologie utilizzate, con anche una completa

35 36 CAPITOLO 7. DOCUMENTAZIONE descrizione di tutto il codice sviluppato. Di seguito si fornisce un estratto del manuale sviluppatore:

Figura 7.2: Schermata del manuale sviluppatore in italiano Capitolo 8

Conclusioni

Il capitolo esegue un’analisi retrospettiva su tutta l’attività di stage evidenziando gli obiettivi che si sono raggiunti e le esperienze maturate.

8.1 Raggiungimento degli obiettivi

Di seguito sono elencati tutti gli obiettivi che erano stati posti dal piano di lavoro, e per ogni uno di questi, è indicato (tra parentesi in fondo all’ultima riga della relativa voce) se sia stato raggiunto (scritta in colore verde) o meno (scritta in colore rosso) al termine dello stage.

8.1.1 Obbligatori Tra gli obiettivi obbligatori, rientrano: • Realizzazione del componente "Hydrogen Custom Logon" per macOS (che possa funzionare sull’ultima release Mojave di macOS) (Raggiunto). • Realizzazione di un installer del componente realizzato (Raggiunto). • Stesura del manuale utente (italiano) (Raggiunto). • Stesura del manuale sviluppatore (italiano) (Raggiunto).

8.1.2 Desiderabili Tra gli obiettivi desiderabili, rientrano: • Stesura dei manuali utente e sviluppatore in inglese (Raggiunto). • Implementazione della modalità di installazione silenziosa per il componente creato (Raggiunto).

8.1.3 Facoltativi Tra gli obiettivi facoltativi, rientrano: • Accertarsi della compatibilità del componente realizzato con versioni di macOS antecedenti alla versione Mojave (Raggiunto).

37 38 CAPITOLO 8. CONCLUSIONI

8.2 Rispetto delle scadenze

Al termine delle 320 ore prefissate, si è riusciti a raggiungere tutti quanti gli obiettivi prefissati (obbligatori, desiderabili e facolatativi). Questo è stato reso possibile da una buona attività di analisi dei requisiti del progetto, in quanto l’ecosistema macOS era poco conosciuto sia dal sottoscritto che dal tutor aziendale. Dopo l’esito positivo dello studio di fattibilità, si era capito che il progetto sarebbe terminato in positivo (rispettando comunque il piano di lavoro per non sforare le tempistiche).

Figura 8.1: Consuntivo delle ore per fase di progetto

A proposito di tempistiche (come da figura 8.1), il progetto ha seguito abbastanza fedelmente il percorso tracciato dal piano di lavoro, ad esclusione della fase di analisi della soluzione, in quanto non era ben chiaro fin da subito in che modo intervenire sulla schermata di login di macOS. Questo non ha causato problemi per l’andamento dello stage, in quanto con le successive fasi del progetto si è riusciti a seguire le tempistiche così come da piano di lavoro; inoltre, si è riusciti perfino a finire un paio di giorni in anticipo rispetto alla scadenza prefissata del progetto, e tale tempo avanzato (circa 20 ore) è stato utilizzato per scopi di formazione personale riguardo ad alcuni strumenti software utilizzati dal personale di NETCOM.

8.3 Conoscenze acquisite e valutazione personale

Questa esperienza di stage mi ha permesso di avere un’idea più chiara su come sia possibile creare applicazioni per il sistema operativo macOS, e oltre a questo ho avuto la possibilità di capire come sia possibile cambiare alcuni aspetti del sistema operativo creando ad esempio dei plug-in (come visto nel capitolo 4 riguardo alla creazione di un "Authorization plug-in"), oppure creare dei programmi che possono essere eseguiti in 8.3. CONOSCENZE ACQUISITE E VALUTAZIONE PERSONALE 39 situazioni particolari (nel nostro caso il MacLogonAgent). Oltre a progredire con gli obiettivi di stage, ho potuto (in alcune occasioni), poter conoscere in modo più approfondito alcuni degli strumenti che vengono quotidianamente usati dal personale di Netcom. Infatti ho potuto seguire (in parte) un corso introduttivo sul software "Ivanti Endpoint Manager", e anche visionare in che modo risultano utili software come "Snow" in contesti aziendali reali. Inoltre ho avuto l’occasione di poter assistere ad alcune attività di assistenza tecnica da remoto che sono state eseguite da parte del personale di Assistenza tecnica di NETCOM.

Glossario

A

Active Directory Active Directory è un insieme di servizi di rete, meglio noti come directory service, adottati dai sistemi operativi Microsoft a partire da Windows 2000 Server e gestiti da un domain controller. Esso si fonda sui concetti di dominio (in particolare di un Dominio Windows Server e di directory, ovvero la modalità con cui vengono assegnate agli utenti tutte le risorse della rete attraverso i concetti di: account utente, account computer, cartelle condivise, stampanti ecc... secondo l’assegnazione da parte dell’amministratore di sistema di Group Policy ovvero criteri di gruppo .9, 10, 17

C

Cocoa Cocoa è l’ambiente nativo di programmazione orientato agli oggetti sviluppato dalla Apple Inc. per i sistemi operativi di Apple, come macOS e iOS. Le applicazioni Cocoa sono normalmente sviluppate utilizzando gli strumenti di sviluppo messi a disposizione da Apple che sono l’IDE Xcode (precedentemente Project Builder) e Interface Builder. I linguaggi supportati da Xcode sono Objective C, AppleScript, C++, Java e Swift, ma l’ambiente Cocoa è utilizzabile anche con altri programmi di sviluppo e utilizzando anche linguaggi come Perl, Python (grazie al bridge PyObjC) e Ruby (grazie a RubyCocoa) . 11, 26

E

Endpoint Con il termine endpoint si indica un generico dispositivo facente parte di un sistema informativo.3,4,6,7, 10

H

Hydrogen Hydrogen si propone come soluzione per aziende medio-grandi, composte da 50-50.000 dipendenti. Tale applicazione si integra completamente con l’interfaccia di accesso di Windows e Ubuntu Linux (fase di richiesta login e password) aggiungendovi la funzionalità

41 42 Glossary

di reset password. L’architettura client-server mette a disposizione una com- ponente di BackEnd (Admin interface) ed una componente di FrontEnd (User Interface). Attraverso la User Interface l’utente è in grado di resettare la propria password di dominio mediante la risposta ad una serie di domande precedentemente impostate .v, ix,9, 10, 13, 15, 16, 18, 26, 30–32

I

ISO 9001 E’ lo standard di riferimento internazionalmente riconosciuto per la gestione della Qualità di qualsiasi organizzazione che intenda rispondere contemporaneamente:

• all’esigenza dell’aumento dell’efficacia ed efficienza dei processi interni. • alla crescente competitività nei mercati attraverso il miglioramento della soddisfazione e della fidelizzazione dei clienti

.4

L

Launchd Launchd è un processo che nei sistemi operativi macOS avvia i servizi di base del computer e permette all’utente di effettuare il login. Inoltre permette di avviare, fermare e gestire sia daemons, applicazioni che processi . xii, 15, 22–24, 27, 31 loginwindow loginwindow è il processo responsabile della visualizzazione della schermata di accesso (o meno, se è stata impostata la funzione di accesso automatico), della convalida dei tentativi di accesso e della configurazione dell’ambiente utente (avvio di Finder, Dock, eventuali app di accesso, ecc.) al momento del login . 19

S

SAM Software asset management è una pratica aziendale che prevede la gestione e l’ottimizzazione dell’acquisto, distribuzione, manutenzione, utilizzo e smaltimento delle applicazioni software all’interno di un’organizzazione. 45

SLA I Service Level Agreement sono strumenti contrattuali attraverso i quali si defini- scono le metriche di servizio (es. qualità di servizio) che devono essere rispettate da un fornitore di servizi (provider) nei confronti dei propri clienti/utenti. Di fat- to, una volta stipulato il contratto, assumono il significato di obblighi contrattuali . 45

U Glossary 43

UEM Unified Endpoint Management è una classe di strumenti software che forniscono un’unica interfaccia di gestione per dispositivi mobili, PC e altri dispositivi. Fornisce funzionalità per la gestione e la protezione di applicazioni mobili, conte- nuti, collaborazione e altro ancora. È un approccio unico alla gestione di tutti gli endpoint come smartphone, tablet, laptop, stampanti, dispositivi rinforzati, Internet of Things (IoT) e dispositivi indossabili. 45

UML in ingegneria del software UML, Unified Modeling Language (ing. linguaggio di modellazione unificato) è un linguaggio di modellazione e specifica basato sul paradigma object-oriented. L’UML svolge un’importantissima funzione di “lingua franca” nella comunità della progettazione e programmazione a oggetti. Gran parte della letteratura di settore usa tale linguaggio per descrivere soluzioni analitiche e progettuali in modo sintetico e comprensibile a un vasto pubblico. 17, 19, 25, 45

X XML eXtensible Markup Language, è un linguaggio di markup, ovvero un linguaggio marcatore basato su un meccanismo sintattico che consente di definire e controllare il significato degli elementi contenuti in un documento. Il nome indica che si tratta di un linguaggio marcatore estensibile in quanto permette di creare tag personalizzati. Rispetto all’HTML, l’XML ha uno scopo ben diverso: mentre il primo definisce una grammatica per la descrizione e la formattazione di pagine web e, in generale,di ipertesti, il secondo è un metalinguaggio utilizzato per creare nuovi linguaggi,atti a descrivere documenti strutturati. Mentre l’HTML ha un insieme ben definito e ristretto di tag, con l’XML è invece possibile definirne di propri a seconda delle esigenze. Viene spesso utilizzato anche nello scambio di dati tra software diversi. 23, 27, 28, 45

Acronimi

S SAM Software asset management.4,7, 42 SLA Service Level Agreement.6, 42

U UEM Unified Endpoint Management.3, 43

UML Unified Modeling Language. 43

X XML eXtensible Markup Language. 43

45

Bibliografia

Siti web consultati

AuthorizationPluginInterface. url: https://developer.apple.com/documentation/ security/authorizationplugininterface?language=objc. Daemons and Agents. url: https://developer.apple.com/library/archive/ technotes/tn2083/_index.html. ISO 9001. url: https://en.wikipedia.org/wiki/ISO_9000. ITIL. url: https://en.wikipedia.org/wiki/ITIL. Ivanti Endpoint Manager. url: https : / / www . ivanti . it / products / unified - endpoint-manager (cit. a p.7). Launchd. url: https://www.launchd.info/. NameAndPassword Example. url: https : / / developer . apple . com / library / archive/samplecode/NameAndPassword/Introduction/Intro.html. NETCOM. url: https://www.netcom.it/. PreLogonAgent Example. url: https://developer.apple.com/library/archive/ samplecode/PreLoginAgents/Introduction/Intro.html (cit. a p. 15). SFAuthorizationPluginView. url: https://developer.apple.com/documentation/ securityinterface/sfauthorizationpluginview (cit. a p. 16). SLA. url: https://en.wikipedia.org/wiki/Service-level_agreement. Snow Software Recognition. url: https://www.snowsoftware.com/int/blog/2014/ 07/28/importance-software-recognition (cit. a p.8). Tool "Packages" per l’installer grafico. url: http://s.sudre.free.fr/Software/ Packages/about.html. Utility Directory. url: https://support.apple.com/it- it/guide/directory- utility/welcome/mac. WebKit. url: https://webkit.org/ (cit. a p. 16). WKWebView. url: https : / / developer . apple . com / documentation / webkit / wkwebview (cit. a p. 16).

47