Forse non tutti sanno che… OAuth non è un protocollo di autenticazione, ma bensì un protocollo di autorizzazione il cui scopo, nello specifico, è quello di delegare un terzo attore ad accedere ad una risorsa verso cui il delegante è autenticato e autorizzato.

Diciamo che questo, OAuth non è un protocollo di autenticazione, è uno dei buoni motivi per cui Twitter non è uno degli IdentityProvider supportati dell’ACS di Windows Azure.

Diciamo anche che avete questo scenario:

• State lavorando ad un progetto che tra le tante cose espone un’API che sarà pubblica;
• Avete bisogno che le applicazioni che in qualche modo vorranno consumare quell’API siano autorizzate, dall’utente che le sta usando, ad accedere ai dati dell’utente stesso in sua vece;
• Avete scelto di delegare tutta la gestione della sicurezza all’ACS di Windows Azure, in modo da poter supportare vari IdentityProvider tra cui ad esempio Google Account e Microsoft Account;

L’obiettivo quindi è di far si che:

• L’applicazione, tipicamente un “app” su un device mobile, che l’utente ha scelto di usare sia in grado di connettersi all’API pubblica;
• Al primo tentativo di connessione esegua il processo di login delegandolo all’IdentityProvider scelto dall’utente;
• Se l’app non si è mai presentata all’API pubblica parta il processo di autorizzazione in cui l’utente decide se vuole delegare l’app per l’accesso ai suoi dati;
• Se l’utente decide di autorizzare l’applicazione venga rilasciato un token, con una scadenza, che garantisca l’accesso;

OAuth ha esattamente questo scopo, nonostante le critiche e le idiosincrasie del protocollo se ci si mette di buzzo buono non è poi così difficile realizzare il tutto (alla fine sono un po’ di chiamate HTTP, nulla a che vedere con lo scambio di messaggi di WS-Federation).

Il flusso tipico con OAuth è il seguente:

L’inghippo

in tutti gli esempi che trovate che parlano di OAuth si da per scontato che chi autorizza sia anche chi autentica, ma nel nostro caso vogliamo che il processo di autenticazione sia delegato all’ACS di Azure:

L’obiettivo è come al solito quello di delegare a chi lo sa fare bene tutta la gestione dell’infrastruttura di sicurezza.

Little gem

Una delle cose poco note è che l’ACS di Azure ha già tutto il supporto per:

• gestire l’elenco della applicazioni autorizzate;
• gestire l’elenco delle deleghe;
• gestire l’emissione dei token di accesso;

Questa funzionalità si chiama “Service Identities” e la trovate sul portale di amministrazione del namespace dell’ACS:

Una “Service Identity” rappresenta un’applicazione autorizzata a chiedervi la delega per accedere alle vostre risorse.

Contorto…una “Service Identity” è un’applicazione registrata da uno sviluppatore (un po’ come quando registrate una nuova applicazione su Facebook), ad una “Service Identity” corrispondono un “application id” e un “application secret” che sono username e password dell’applicazione, l’utente finale autorizzerà poi l’applicazione (identificata da app id e secret) ad accedere alle sue risorse, questa autorizzazione si chiama delega, anche la delega è completamente gestita da Azure, ma non è visibile dal portale, c’è invece un’API rest che vi consente di manipolare i contenuti delle deleghe di ogni applicazione in modo, ad esempio, da poter dare la possibilità all’utente finale di decidere se e come revocare ad un’applicazione la delega.

.m