Nello script precedente (http://aspit.co/a2d) abbiamo iniziato ad analizzare le modalità per configurare l'autenticazione basata su cookie in ASP.NET Identity. Come abbiamo già accennato, tutto avviene tramite un metodo contenuto all'interno del file Startup.Auth.cs:

app.UseCookieAuthentication(new CookieAuthenticationOptions
{
    AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
    LoginPath = new PathString("/Account/Login"),
    Provider = new CookieAuthenticationProvider
    {
        OnValidateIdentity = SecurityStampValidator
          .OnValidateIdentity<ApplicationUserManager, ApplicationUser>(
            validateInterval: TimeSpan.FromMinutes(30),
            regenerateIdentity: 
              (manager, user) => user.GenerateUserIdentityAsync(manager))
    }
});

Cerchiamo di capire quali siano le altre possibilità di manovra che abbiamo.

Sfruttare l'estendibilità di ASP.NET Identity

• Provider è la proprietà da valorizzare con un'istanza di ICookieAuthenticationProvider se vogliamo intervenire sulle proprietà del cookie nel momento in cui viene emesso, oppure, di eseguire logica personalizzata all'atto della sua conseguente validazione. Nel template di Visual Studio 2013, troviamo questa proprietà valorizzata con un CookieAuthenticationProvider che sfrutta il SecurityStampValidator per consentire il sign-out remoto di un utente, di cui abbiamo parlato in un precedente script (http://aspit.co/a11).
• SystemClock accetta un ISystemClock che ha il solo scopo di restituire la data/ora UTC corrente. ASP.NET Identity è costruito per essere debolmente accoppiato ad ogni altro componente esterno (il clock di sistema, in questo caso). Questo lo rende estremamente testabile infatti, in ambito di unit testing, con una nostra implementazione di ISystemClock potremmo facilmente simulare il passaggio del tempo e la conseguente scadenza del cookie.
• TicketDataFormat può essere valorizzato con un ISecureDataFormat per personalizzare la cifratura (e decifratura) del contenuto del cookie. In questo modo siamo potenzialmente in grado di intepretare i cookie emessi da un'altra applicazione, anche non ASP.NET, che usi un proprio algoritmo di crittografia.

Modificare gli attributi del cookie

• CookieDomain indica il dominio di validità del cookie. Tipicamente, un cookie è valido solo all'interno del dominio per il quale è stato emesso ma, se volessimo estenderne la validità ad altri sottodomini che ospitano altre nostre applicazioni, allora potremmo valorizzarlo con la stringa ".nomedominio.ext"
• CookiePath accetta un percorso virtuale, come ad esempio "/App1", usato per restringere la validità del cookie ad una data sottocartella. Utile quando ospitiamo più applicazioni nello stesso dominio, e vogliamo tenere isolati i rispettivi meccanismi di autenticazione.
• CookieHttpOnly di default impostato a true, impedisce che il cookie sia accessibile lato client, per mezzo di codice javascript.
• CookieName contiene il nome con il quale il browser salverà il cookie. Modificare il nome mentre l'applicazione è in produzione vuol dire ignorare tutti i cookie di autenticazione emessi in precedenza e costringere gli utenti ad effettuare di nuovo l'accesso.
• CookieSecure può restringere la validità del cookie alle sole pagine protette da HTTPS. Il valore di default è invece CookieSecureOption.SameAsRequest, che è un'opzione molto versatile perché consente l'emissione del cookie sia quando siamo in fase di sviluppo (su HTTP) che in produzione (idealmente su HTTPS).

Un'ultima nota relativa alla configurazione: come abbiamo visto, usando ASP.NET Identity, la configurazione si sposta dal tradizionale web.config ad un oggetto CookieAuthenticationOptions di cui valorizziamo le proprietà.

Questo potrebbe suggerirci che, ad ogni piccola modifica della configurazione, sia necessario ricompilare e ridistribuire l'applicazione. In realtà, siamo liberi di continuare ad usare il web.config e di leggere le impostazioni da chiavi appSettings predisposte allo scopo. Se lo preferiamo, possiamo scrivere un'apposita configSection personalizzata, in modo da lavorare con un oggetto di configurazione che permette l'accesso ai valori in maniera fortemente tipizzata.