Implementare l'autenticazione con Windows Live ID
L'idea che ci guida in questa scoperta di Windows Live ID è quella di rendere possibile questo scenario:
- L'utente ha già un account sul nostro sito, fatto con ASP.NET e che utilizza Membership API;
- L'utente ha già un account su Windows Live ID (molto facile, visto che basta un account Messenger, ad esempio);
- L'utente vuole fare login senza necessità di ricordare un altro account e relativa password, sfruttando invece il suo account Live ID.
L'idea è che usando un servizio così diffuso come Live ID, un utente faccia meno fatica ad autenticarsi che con l'ennesima coppia username/password da ricordare.
L'integrazione con Live ID comincia da una scelta di tipo architetturale: renderla integrata con Membership API. La maggior parte delle soluzioni che si trovano in giro, inclusa quella dell'SDK, non tengono presente minimamente che nella maggior parte dei casi si cerca semplicità e non si vuole stravolgere quello che esiste. E la semplicità è quella di rendere possibile per l'utente di associare un proprio account a quello Live ID, perchè uno username scelto in maniera precisa o un'eventuale associazione dell'account dopo la sua creazione sono casi reali, più che obbligare l'utente a crearsi un account ex novo.
Purtroppo in questo caso ci si scontra con un limite di Membership API (e per certi versi, anche di Profile): l'impossibilità di poter usare un identificativo diverso dallo username (o dal Provider Key, che però non si può cambiare a cuor leggero con la sicurezza assoluta di non "rompere" il funzionamento del provider) come chiave di filtro. L'alternativa sarebbe caricarsi tutti i profili in memoria e poi usare LINQ per filtrarli, o usare direttameante LINQ to SQL, che però rende questa soluzione poco performante oppure molto legata al provider che si utilizza.
Per questo motivo, la scelta è ricaduta sull'uso di Roles API: quando ci sarà l'assocazione dell'ID di Live all'account, verrà creato un ruolo ed associato allo username: in questo modo in fase di login con Live verrà cercato il corrispondente account associato al ruolo e verrà garantito l'accesso all'utente. La soluzione non presenta punti di vulnerabilità a proposito di sicurezza semplicemente perchè tutte le comunicazioni dai servizi Live verso la nostra pagina intermedia prevedono una criptazione, dunque è impossibile arrivare alla nostra pagina senza passare l'esatto Token criptato che Live ID si aspetta di passarci, data la nostra chiave di criptazione, che è e deve rimanere segreta.
Tornando al nostro progetto di integrazione, supponiamo di aver già integrato Membership e Roles API nel nostro sito, sia utilizzando provider custom che quelli integrati in ASP.NET (fa poca differenza, visto che il codice usa le API). In questo scenario è essenziale che andiamo a recuperare dall'SDK una classe che include molta della logica necessaria a gestire il Token, così da fare meno fatica. Per chi ama capire come funzionano le cose, su questa pagina c'è la documentazione del formato del Token.
Le tre fasi che saranno gestite sono:
- SignIn
- SignOut
- ClearCookie
Sulle prime due c'è poco da aggiungere, la seconda invece è una azione che viene richiesta da Live quando siamo loggati a più di un sito, perchè il meccanismo che sta dietro a questo sistema di autenticazione prevede che nello stesso tempo possiamo usare il nostro account su vari siti. In questo caso, devono essere ripuliti i cookie (cioè, deve essere fatto il SignOut dalla Forms Authentication, nel nostro caso) e restituita una gif 1x1, trasparente. Ancora una volta la classe WindowsLiveLogin contenuta nell'SDK ci viene in auto, grazie ai suoi metodi. Si trova, per comodità, inclusa nell'allegato con gli esempi.
A questo punto è necessario salvare nel web.config le credenziali necessarie a questa classe per funzionare, che sono riportate di seguito:
<appSettings>
<add key="wll_appid" value="chiave"/>
<add key="wll_secret" value="01234567890123456789"/>
<add key="wll_securityalgorithm" value="wsignin1.0"/>
</appSettings>Fatto questo dobbiamo incominciare ad implementare la logica necessaria alla pagina designata in fase di registrazione (nel nostro caso live.aspx, sotto la root dell'applicazione) per fare il login. Le routine di Logout e ClearCookie sono facili da creare e si possono trovare nel codice allegato. Ecco come si presenta la nostra implementazione:
// sto cercando di associare l'utente ad un account
// prendo il token salvato nel cookie prima del login
if (user == null && Request.Cookies["LiveID"] != null && !string.IsNullOrEmpty(Request.Cookies["LiveID"]["token"]))
{
string token = Request.Cookies["LiveID"]["token"];
user = wll.ProcessToken(token);
}
if (user == null)
FormsAuthentication.RedirectToLoginPage();
string userID = user.Id;
string returnUrl = user.Context;
bool persistent = user.UsePersistentCookie;
// uso Roles API per associare l'utente
string roleName = string.Concat("Live-", userID);
// è autenticato già nel sito, associo il suo token
if (Request.IsAuthenticated)
{
// verifico se è già stato associato
if (!Roles.IsUserInRole(roleName))
{
if (!Roles.RoleExists(roleName))
Roles.CreateRole(roleName);
Roles.AddUserToRole(User.Identity.Name, roleName);
}
// rimuovo il cookie temporaneo
Response.Cookies.Remove("LiveID");
Login(User.Identity.Name, persistent);
}
// login via Live
else
{
if (Roles.RoleExists(roleName))
{
// l'utente è associato
string username = Roles.GetUsersInRole(roleName)[0];
Login(username, persistent);
}
else
{
// forzo il login e poi faccio tornare qui
Response.Cookies["LiveID"]["token"] = user.Token;
FormsAuthentication.RedirectToLoginPage(string.Concat("LiveID=1&ReturnUrl=", Request.Url.ToString()));
}
}
// nel caso qualcosa non vada a buon fine, torna al login
FormsAuthentication.RedirectToLoginPage();
Secondo la logica che abbiamo implementato, se l'utente arriva a questa pagina, viene prima verificato se è stato inviato il token corretto da Live ID. Se lo è, allora nel caso in cui non sia autenticato, viene recuperato l'utente associato al ruolo specificato, altrimenti viene chiesto il login classico al sito, successivamente al quale viene associato il Token. Dalle volte successive, si viene automaticamente riconosciuti con lo username con il quale ci si è autenticati, rendendo molto più semplice l'intera operazione.
Attenzione: Questo articolo contiene un allegato
Contenuti dell'articolo
- Pagina 1
- Pagina 2
- Pagina 3
- Pagina 5
- Galleria fotografica dinamica con ASP.NET AJAX
- Usare Search come un servizio nei tuoi siti e nei tuoi client
- Mappe nel tuo sito con Virtual Earth
- Introduzione ai cloud based service con Windows Live Services
- Realizzare un custom extender AJAX con ASP.NET 3.5
- Tracciare le modifiche ai dati e allineare i datawarehouse con il Change Data Capture in SQL Server 2008
- Le nuove caratteristiche di IIS 7.0 per sviluppatori e sistemisti
Aggiungi un nuovo commento »»»
Per inserire un commento, devi registrarti alla nostra community.
Difficoltà
Utilità
Stampa 
Download
10annidi.ASPItalia.com: iscriviti alla competizione e vinci fantastici premi ogni mese!
