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
  • Autenticazione con Windows Live ID
• Pagina 2
  • Implementare l'autenticazione con Windows Live ID
• Pagina 3
  • Visualizare il link per il login con Windows Live ID
  • Windows Live Presence e Messenger
• Pagina 5
  • E per finire: Live Contacts!
  • Un caso pratico: ASPItalia.com
  • Conclusioni
  • La serie completa su Windows Live Services

• L'object model di Microsoft SharePoint - Seconda parte
• L'object model di Microsoft SharePoint - Prima parte
• La gestione dello stato da ASP.NET 1.x ad ASP.NET 3.5
• Routing e dynamic data control di ASP.NET 3.5 SP1
• I nuovi controlli di ASP.NET 3.5: LinqDataSource, ListView e DataPager
• 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

Aggiungi un nuovo commento »»»
Per inserire un commento, devi registrarti alla nostra community.