Molte delle applicazioni che vengono sviluppate ogni giorno richiedono una forma di autenticazione dell'utente per personalizzare contenuti, consentire o vietare accessi, tracciare informazioni e in generale associare e sfruttare dati relativi all'utente o ad un gruppo di utenti. Questa necessità è presente sia in applicazioni web che in quelle client (Windows/Mac/Unix*), ma anche in quei servizi enterprise o meno che si rendono usufruibili dai internet o da reti più circoscritte.

Le soluzioni per permettere l'autenticazione sono molteplici e variano dal protocollo di comunicazione (HTTP, TCP e altro) e dalla tecnologia adottata (ASP.NET, PHP, Java o altro). Alcune sono specifiche di ogni tecnologia e linguaggio utilizzato, mentre altre sono standard, riconosciuti dai consorzi o de facto per il loro largo utilizzo.

Il problema: protocolli e credenziali

La varietà delle tecnologie e delle soluzioni unite alla forte crescita di internet e delle soluzioni che si affacciano su di essa ha però portato a due principali problemi:

• La moltitudine di credenziali che gli utenti devono creare e memorizzare;
• I numerosi sistemi di autenticazioni ognuno diverso dall'altro;

Per risolvere il problema delle molteplici credenziali sono stati effettuati numerosi tentativi, ma nessuno è mai riuscito ad imporsi per fornire un unico storage di credenziali. Questa torta invece è stata suddivisa tra grossi attori del world wide web che grazie alla loro larga diffusione sono in grado di coprire la quasi totalità dell'utenze. Tra questi i più importanti sono Facebook, Live ID, Yahoo! e Google, e la tendenza delle applicazioni è sempre più mirata a sfruttare i loro sistemi di autenticazione per agevolare l'utente e invogliarlo ad usufruire dei servizi che l'applicazione mette a disposizione.

Per quanto riguarda invece i sistemi di autenticazione il problema è anch'esso complesso. Molti si basano su cookie o sid di sessione, effettuano lookup su propri database, criptano le informazioni a loro modo e spesso lo sviluppatore commette l'errore di pensare che una propria soluzione sia migliore di una riconosciuta ed adottata.

Una terza via che quindi è possibile adottare consiste nel sfruttare le credenziali dei vendor prima citati, i quali però sfruttano protocolli diversi per permettere l'autenticazione, l'esecuzione di operazioni e passare informazioni all'applicazione che ne ha bisogno. Facebook ad esempio utilizza OAuth, Yahoo sfrutta OpenID, mentre Live ID usa WS-Trust. Questi protocolli sono tra i più utilizzati e standard, ma richiedono differenti implementazioni e configurazioni.

E' a questo punto che viene in aiuto Access Control Service (ACS) di Windows Azure, perché mette a disposizione un layer intermedio che rende univoco il protocollo di comunicazione per il proprio applicativo, ed apre il login ad infiniti identity provider con pochissimo sforzo.

L'architettura

Per capire come sfruttare ACS è bene partire dall'architettura e dagli elementi che permettono facilmente implementare il single sign-on nei propri applicativi. Molti dei concetti che si affrontano in questo articolo possono essere ripresi da questo link, anche se hanno subito un'evoluzione per venire incontro alle realtà di utilizzo.

Gli attori che entrano in gioco sono molteplici e sono:

• L'end user o subject: l'utente finale che deve effettuare il login;
• L'identity provider (IP): il fornitore dell'entità che detiene le credenziali e ospita la pagina di login e le API di accesso;
• Il relying party (RP): la propria applicazione che fa uso dell'identità per autenticare un subject;
• Il security token server (STS): il server che fornisce i token di sicurezza e le informazioni al relying party.

Dalla figura successiva è possibile vedere come questi attori collaborino tra di loro.

Image from MSDN

Prima di tutto l'utente utilizza un client applicativo che ha una relazione sicura, mediante certificato, con l'ACS di Windows Azure. Quando è necessario il login, all'utente vengono richieste le credenziali a seconda dell'identity provider per ottenere un token da passare al STS di ACS. Quest'ultimo si occupa, a seconda dell'identity provider, di effettuare il dialogo per ottenere le informazioni, le passa ad un motore di trasformazione e le restituisce al relying party. Attraverso poi il Management Portal di Windows Azure è consentito configurare gli identity provider, le trasformazioni, i certificati e tutte le configurazioni dell'ACS. I tutto a sua volta può essere configurato attraverso un endpoint OData (Open Data Protocol).

L'STS dell'ACS a sua volta espone più endpoint per supportare i protocolli più diffusi: OAuth WRAP, OAuth 2.0, WS-Trust e WS-Federation. Questo permette dal proprio applicativo di scegliere il protocollo preferito, il più adatto alle proprie esigenze e il più supportato dalla tecnologia di sviluppo, mentre dall'altra parte dell'ACS, di scegliere uno o più identity provider per supportare il login attraverso i sistemi più diffusi: Live ID, Google, Yahoo!, Facebook, ADFS v2 (autenticazione Windows) e OpenID.

Poiché ACS è di fatto un motore che sta nel mezzo, è implementato come servizio che lavora sulla piattaforma Windows Azure sotto la sezione AppFabric, ed è quindi sottoposto a dei costi in base al numero delle transazioni. Per utilizzarlo quindi è bene cominciare dal portale di Windows Azure.