Client/Server

Lo stile architetturale client/server è uno tra i vincoli REST che merita di non essere trascurato. É vero infatti che REST è soltanto una filosofia, che deve essere applicata in modo intelligente in base alle caratteristiche del servizio che sta progettando. Raramente infatti vengono rispettati tutti i suoi vincoli, ma sicuramente è bene fare un’analisi dei requisiti del servizio in esame e un’analisi su quali vincoli di REST portino effettivamente a benefici e ad una metodologia di sviluppo e gestione agile. Quello che è emerso dalle moderne filosofie di sviluppo (REST oriented) è che il vincolo client/server è estremamente importante per il supporto e lo sviluppo contemporaneo del servizio su più piattaforme (desktop, mobile, tablet). Lo sviluppo del client e del server vengono infatti disaccoppiati ed evolvono in modo parallelo ma indipendente.

Nello sviluppo di un servizio di tipo SaaSS_{, che si utilizzi o meno il framework}

presentato in questa dissertazione, disaccoppiare da un punto di vista logico/fun- zionale il client e il server non solo è importante dal punto di vista dello sviluppo e della scalabilità, ma anche e soprattutto dal punto di vista della sicurezza del- l’utente finale. Il client e il server devono infatti essere due entità altamente disaccoppiate ed è importante identificare quali siano i dati sensibili che entrano in gioco per evitare che transitino sul server in modo non sicuro.

Server

Affinché siano soddisfatti i requisiti e le promesse dallo stile SaaSS_{, il server}

non deve mai essere in grado di ottenere dei dati sensibili che possano ledere la privacy dell’utente finale. Ogni contenuto o informazione sensibile deve essere memorizzata quindi in modo cifrato nel server, secondo quanto visto nel capitolo 4 e ovviamente in base alle tipologie del servizio che si intende implementare. Il server viene visto quindi esclusivamente come un punto di storage non trusted e come fornitore di tutto l’environment a contorno della fruizione del servizio che viene esclusivamente effettuata lato client (dal punto di vista dei dati dell’utente). Questo comporta l’uso dell’approccio REST per la creazione di API che consen- tano di gestire le entità e i dati trattati nel capitolo 4 (come Risorse, Clienti, Collezioni e Gruppi in base alla tipologia del servizio che si vuole implementa- re). Considerando un servizio web based è chiaro che la scelta del protocollo di comunicazione tra client server ricada sull’HTTP. Dettagli aggiuntivi sull’imple- mentazione di API funzionali e sicure vengono trattati nelle sezioni 5.2 e 5.3, mentre questa sezione mira a fornire un punto di partenza sul modo di pensare e di strutturare l’intero servizio.

Si ricorda inoltre che REST è essenzialmente una filosofia, spesso molto utile (come nell’implementazione di API) ma a volte fuorviante e più complessa da gestire per naturali soluzioni più semplici. Il lettore (o l’implementatore) quin- di non deve necessariamente nel rendere il suo servizio il 100% conforme a tale approccio, ma a volte e in alcune situazioni è bene considerare l’utilizzo di solu- zioni meno eleganti ma più semplici e di rapida implementazione. Basti pensare alla necessità di fornire un pannello di amministrazione per eventuali operazioni di gestione del servizio o dell’infrastruttura: in questo caso potrebbe essere più semplice creare una semplice applicazione web lato desktop poco disaccoppiata e poco fruibile da altri dispositivi (mobile e tablet) con un occhio esclusivo sulla funzionalità. La scelta delle tecnologie deve essere quindi ben oculata in base alle necessità ed è consigliabile (ove possibile) di privilegiare l’approccio di sviluppo agile piuttosto che ad uno stile troppo teorico e filosofico (per approfondimenti si faccia riferimento a [10]).

Client

La parte client è fondamentale per il corretto funzionamento dell’approccio SaaSS

e per la risoluzione dei problemi analizzati nella sezione 3.3. Il client deve esse- re responsabile infatti della decifratura di tutte le informazioni contenute nelle catene crittografiche analizzate nel capitolo 4 (link simmetrici e asimmetrici). É sul client che ricade infatti il maggior peso computazionale, e in base al tipo di servizio che si vuole implementare è bene prevedere nell’analisi dei requisiti dei test sufficienti a verificare le varie performance sui vari device client che il servizio intende supportare. I test sono necessari per verificare i requisiti di scalabilità del servizio che si intende offrire e per verificare che le tecnologie e gli algorit- mi crittografici scelti siano adatti. Sulla parte client ricadrà inoltre il compito dell’implementazione degli algoritmi necessari a percorrere, mantenere ed utiliz- zare le catene crittografiche presentate nel capitolo 4. In base alla tipologia di servizio devono essere realizzate soluzioni più o meno complesse, ma l’approccio giusto è sempre quello incrementale fino ad arrivare alle ottimizzazioni necessarie a rendere il servizio scalabile e sicuro.

É bene ricordare inoltre di verificare le caratteristiche di sicurezza di ogni de- vice client che si intende supportare. Il primo punto di attacco per un hacker sarà senz’altro il device in cui i dati verranno decifrati, data la complessità intrinseca di un attacco crittografico lato server (non conoscendo le chiavi di cifratura/decifra- tura). A titolo di esempio il capitolo 4 considera l’utilizzo di una coppia di chiavi asimmetriche per un generico cliente (utente), tuttavia tali chiavi sono molto dif- ficili da gestire per un’utenza poco tecnica. Un approccio sensato potrebbe essere quello di fare in modo che l’utente debba memorizzare e ricordare una password (meglio passphrase) con cui sia in grado di decifrare la propria chiave privata (nella terminologia del capitolo 4, si creerebbe un link simmetrico tra la password e la chiave privata). Il server quindi (che funge da storage) potrebbe offrire anche il servizio di portachiavi dell’utente, mentre le funzionalità del client verrebbero arricchite con la necessità di dover recuperare anche la chiave privata (cifrata: link simmetrico) dell’utente e decifrarla. Il client (device) inoltre potrebbe essere dotato di meccanismi di sicurezza per evitare che la chiave privata venga memo- rizzata o mantenuta in memoria per troppo tempo. Il servizio potrebbe essere provvisto inoltre di meccanismi di controllo degli accessi alla catena crittografica da parte di esclusivi client registrati (approfondito nella sezione 5.3).