Qualche giorno fa sono andato a trovare un mio grande amico, che mi ha accolto indossando la maglietta in figura.

Ho subito capito che aveva indossatto la maglietta in mio onore, poichè la scritta era celebrativa per la serie che stavo scrivendo, e di cui questo post fa parte.

Evidentemente l'occhiata cui faceva riferimento era alle configurazioni introdotte sui servizi Azure Mobile, e di cui ho parlato nei post precedenti.

Il mio amico dapprima ha negato la connessione tra la mia serie e la sua maglietta, ma poi, dopo alcune mie insistenze, ha confermato le mie supposizioni.

Non ho capito molto il referimento al ginecologo, ma lo stesso amico mi ha assicurato che mi avrebbe spiegato nei prossimi giorni.

Per questo motivo ho pensato di mettere la foto che ritrae la sua bellissima T-Shirt: ho anche deciso di parlarne qui per sfatare il falso mito che chi si occupa di informatica non capisce mai le battute o le frasi spiritose !

Non la si fa a Giampaolo TUCCI !

Premesso questo fatto buttiamoci nella parte finale dell'autenticazione server-flow.

Quando ho esposto la configurazione all'interno del portale Azure per l'autenticazione in analisi avevo detto che avrei discusso del campo Allowed External Redirect URLs.

L'autenticazione server-flow con l'utilizzo dell'SDK Azure Mobile Client richiede che si definisca un nuovo URL Schema nonchè un host per la nostra app. L'URL Schema sono quei caratteri prima dell'indirizzo in un URL.

<URL Schema>://<Host>

L'utilizzo è quello di permettere il redirect dei servzi Azure al device (step 4 autenticazione server-flow - vedi post precedenti).

Dopo aver configurato il servizio backend in Azure è possibile proseguire nella costruzione della app aggiungendo l'autenticazione. Il codice lo trovate in linkografia.

Iniziamo a vedere che nella classe delegata a chiaccherare con il backend Azureè stato aggiunto un metodo che server per eseguire il login.

public Task LoginAsync()
{

	var loginProvider = DependencyService.Get(<ILoginProvider>);
	return loginProvider.LoginAsync(client);
}

In questo post esporrò come implementare la funzionalità di autenticazione di tipo server-flow usando come identity provider nientemeno che Facebook.

Occorre dire che se si vuole usare un IdP tra quelli supportati da Azure il processo di configurazione è praticamente uguale per tutti.

> Accedere alla console developer dell’IdP scelto

> Creare una nuova App e abilitare l’utilizzo dell’autenticazione Oauth

> Configurare la parte impostando l’URL del redirect del mobile app service di Azure e quindi prelevare gli identificativi proposti (App Id e App Secret) e che saranno usati da Azure per verificare la correttezza dei dati ricevuti dall’IdP.

> Accedere al portale Azure Impostare i dati sopra ottenuti dall’IdP nel Mobile App service.

Proteggere i controller del backend da accessi non autenticati (attributo [Authorize])

Sembra un bel casino, ma vedrete che è una passeggiata di salute !

Rimarco nuovamente che qui useremo Facebook come identity provider, ma il processo è assolutamente analogo per gli altri IdP supportati in Azure.

Per accedere al portale developer di facebook usare il link in llinkografia, e quindi selezionare nuova app "Add New App".

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.