Sinora nel progetto oggetto di questa serie non abbiamo in alcun modo introdotto alcun tipo di sicurezza: chiunque usi la nostra app è in grado di utilizzarne i servizi senza nessun limite o controllo.

Inoltre per sempicità il campo nome utente che correda ogni post è un semplice campo di testo, dove ognuno può metterci il valore che desidera.

Ovviamente per molti utilizzi questa libertà non rappresenta il comportamento voluto: nel nostro caso occorre che almeno il campo nome utente all'atto di inserimento del post sia riempito in modo sensato e con un minimo di sicurezza in modo da comprendere chi-ha-scritto-cosa.

E' arrivato il momento di parlare di autenticazione e autorizzazione ! Prima però occorre introdurre un minimo di teoria.

Iniziamo con qualche definizione.

L’autenticazione è il processo che permette di identificare l’utilizzatore del software in modo sicuro: cioè identificare in modo certo un nome utente.

Questo processo nel passato veniva svolto escluivamente tramite l’ausilio di una userid e una password: il concetto che sottende questo tipo di autenticazione è che solo chi conosce la relativa password è in grado di sostenere di essere realmente l’utente specificato.

Però oramai l'epoca delle giacce con sotto le spalline rinforzanti è passata da un pezzo...... e i sistemi più recenti usano approcci diversi. Per esempio è comune al giorno d'oggi supportare un processo di autenticazione basato su OAuth.

Usando questo standard un utilizzatore che vuole utilizzare una risorsa dovrà prima autenticarsi presso un attore esterno (per esempio google, facebook, etc etc), che in questo contesto prende il nome di identity provider (abbreviato IdP).

L’atto finale del processo di autenticazione è un certificato di validità (token), rilasciato dallo stesso IdP, che quindi sarà presentato alle risorse (nel nostro caso il mobile app service presso Azure) prima di poterle utilizzare e rappresenterà una sorta di carta di identità digitale emessa dall’IdP prescelto.

Una volta identificato in modo ragionevolmente sicuro un utente è possibile quindi introdurre dei comportamenti che limitano l'utilizzo del backend o parte di esso a secondo dell'utente che li sta utilizzando: questo processo è l'autorizzazione.

La nostra app utilizzerà OAuth per autenitcarsi presso Facebook, usando OAuth: nel prosieguo della serie Vi esporrò come configurare e implementare il tutto.

Processo di Autenticazione con IdP esterno tramite OAuth: un minimo di teoria

Ora ci tengo a specificare che qui fornirò la versione "esemplificata" del processo, e in salsa "azure app service": ovviamente lo standard OAuth prevede molte più funzionalità e caratteristiche cui qui non farò minimamente cenno per non appesantire la trattazione.

Insomma qui Vi presenterò la versione distillata dell'autenticazione OAuth presso IdP esterno e "tagliata" per i nostri scopi.

 In un’autenticazione OAuth ci sono tre attori che vengono coinvolti, e che svolgono ruoli ben distinti.

> Il client, che è l’applicazione che deve accedere alle risorse (la nostra App).

> La risorse che offre le sue funzionalità a utenze autenticate (mobile backend).

> L’identity provider che è il servizio responsabile dell’autenticazione del client.

Il modo con cui questi attori interagiscono per eseguire l’autenticazione oAuth propone due processi ben distinti: server-flow e client-flow. L'effetto fianle è sempre lo stesso: un rilascio di un token da parte di un IdP che sarà presentato al backend azure, e che servirà per identificare l'utilizzatore.

Server Flow

Nel caso del server-flow in ambito Mobile Azure SDK l’algoritmo del processo di autenticazione è il seguente.

• Alla partenza del processo di autenticazione il client (app) visualizza una pagina web (generalmente una web views o anche, nelle nuove versione dell’SDK, il browser del device). Questa pagina web punta a un URL che afferisce al mobile backend su Azure
• Il backend all’arrivo della chiamata http di autenticazione la redireziona alla pagina di richiesta credenziali dell’IdP (quindi per esempio la pagina di login di facebook)
• Una volta che il processo di login presso l’IdP è andato a buone fine l’IdP stesso redireziona la chiamata al backend, allegando a questa un identity provider token
• Il backend valida il token ricevuto (per verificare che sia veramente stato rilasciato dall'IdP), e quindi conia un nuovo token che ritorna al client.
• Tutte le successive chiamate del client verso il mobile backend dovranno aggiungere quest’ultimo token (cioè quello rilasciato dai servizi Azure) alle richieste (precisamente nell'header delle chiamate http).

Il token è un oggetto che prova che l’utente è stato autenticato dall’Idp o dal bakend azure.

Client Flow

Il client-flow authentication lavora in modo diverso.

• Il client comunica direttamente all’IdP la userId e password o eventuali altri elementi identificativi, usando l'SDK apposito del provider.
• L’IdP autentica le credenziali ricevute e restituisce un identity provider token.
• Il client userà questo token per richiamare i servizi del backend Azure, che quindi, dopo averlo eseguito le verifiche del caso, conierà un nuovo token.
• Questo nuovo token rilasciato dai servizi Azure che dovrà essere incluso ad ogni chiamata ai servizi similmente a quanto avviene per il server-flow.

Note Finali

L’autenticazione server-flow è implementata totalmente dall’Azure Mobile Client SDK, e quindi non prevede l’utilizzo di strumenti aggiuntivi ma solo di un processo di configurazione dell’Azure Mobile App nel portale.

Di contro la client-flow usa pesantemente l’SDK messo a disposizione dell’IdP, e i metodi di questo: se questo introduce delle difficoltà nel codice (occorre comoscere un nuovo SDk esterno a quello di Azure Mobile Service) di contro permette una esperienza d’uso più omogenea (generalmente non vengono usate webview/custom chrome tab).

Comunque sia una volta ottenuto il token di autorizzazione dall'IdP questo dovrà essere inoltrato ai servizi Azure che, dopo averlo verificato, ne conieranno un’altro da utilizzarsi per ogni chiamata.

A costo di essere ripetitivo in modo insopportabile: per entrambi i processi il token rilasciato dall'IdP serve solo per essere inoltrato agli Azure service, che a loro volta ne conieranno uno nuovo "di pacca". Solo quest'utimo dovrà essere utilizzato per utilizzare i servizi Azure Mobile: quello rilasciato dall'IdP è utilizzato solo nella fase iniziale del processo di autenticazione !

Gli Azure App Service hanno il supporto nativo i seguenti IdP esterni, sia per processi server-flow che client-flow.

• Facebook
• Google
• Microsoft (.....strano, non trovate ?)
• Twitter

Detto in altri termini usando uno di questi IdP il processo risulta essere molto semplice e intuitivo.

A quanto sopra occorre aggiungere anche un ulteriore tipo di autenticazione: l’autenticazione di tipo custom.

In pratica il client può passare le proprie credenziali al backend, che a sua volta può essere programmato per generare un token di autenticazione.

Grazie a questa possibilità è possibile gestire l’autenticazione semplicemente con l’ausilio di una tabella di user/password, o anche introdurre autenticazioni con altri IdP diversi da quelli supportati.

Infatti in questo caso lato backend sarebbe possibile accettare eventuali token ricevuti da Idp esterni e validarli, e quindi rilasciare un token di autorizzazione valido per usare i servizi Azure. Però essendo tutto custom occorre mettere mano al codice sia lato client che lato server. Nulla di particolarmente difficile, che sia ben chiaro, ma sicuramente occorre qualche conoscenza in più !

Nel seguito della serie esporrò un’autenticazione server-flow usando Facebook come IdP: per non farsi mancare nulla presenterò anche un’analoga autenticazione però usando client-flow.

In questo modo potrete comprendere gioie e dolori di ciascuna possibilità