Guardando ASP.NET Identity (nuova implementazione dell'appartenenza in ASP.NET), mi sono imbattuto in questa interfaccia durante l'implementazione della mia UserStore:

//Microsoft.AspNet.Identity.Core.dll

namespace Microsoft.AspNet.Identity
{ 
    public interface IUserSecurityStampStore<TUser> :
    {
        // Methods
        Task<string> GetSecurityStampAsync(TUser user);
        Task SetSecurityStampAsync(TUser user, string stamp);
    }
}

IUserSecurityStampStoreè implementato per impostazione predefinita EntityFramework.UserStore<TUser>che essenzialmente ottiene e imposta la TUser.SecurityStampproprietà.

Dopo qualche altro scavo, sembra che a SecurityStampsia un Guidche è appena generato nei punti chiave del UserManager(ad esempio, cambiando le password).

Non riesco davvero a decifrare molto oltre questo dato che sto esaminando questo codice in Reflector . Quasi tutte le informazioni su simboli e asincrono sono state ottimizzate.

Inoltre, Google non è stato di grande aiuto.

Le domande sono:

• Che cos'è SecurityStampun'identità ASP.NET ea cosa serve?
• Fa il SecurityStamp un ruolo quando vengono creati i cookie di autenticazione?
• Ci sono implicazioni o precauzioni di sicurezza che devono essere prese con questo? Ad esempio, non inviare questo valore a valle ai client?

Aggiornamento (16/09/2014)

Codice sorgente disponibile qui:

• https://github.com/aspnet/Identity/
• https://github.com/aspnet/Security/

Questo ha lo scopo di rappresentare l'istantanea corrente delle credenziali dell'utente. Quindi, se non cambia nulla, il timbro rimarrà lo stesso. Ma se la password dell'utente viene modificata o viene rimosso un accesso (scollega il tuo account google / fb), il timbro cambierà. Ciò è necessario per cose come la firma automatica degli utenti / il rifiuto dei vecchi cookie quando ciò si verifica, che è una funzionalità disponibile in 2.0.

L'identità non è ancora open source, è ancora in fase di elaborazione.

Modifica: aggiornato per 2.0.0. Quindi lo scopo principale di SecurityStampè abilitare la disconnessione ovunque. L'idea di base è che ogni volta che qualcosa di relativo alla sicurezza viene modificato sull'utente, come una password, è una buona idea invalidare automaticamente tutti i cookie di accesso esistenti, quindi se la tua password / account è stata precedentemente compromessa, l'attaccante non ha più accesso.

In 2.0.0 abbiamo aggiunto la seguente configurazione per agganciare il OnValidateIdentitymetodo nel CookieMiddlewareguardare SecurityStampe rifiutare i cookie quando è cambiato. Aggiorna inoltre automaticamente i reclami dell'utente dal database ogni volta refreshIntervalche il timbro è invariato (che si occupa di cose come cambiare i ruoli, ecc.)

app.UseCookieAuthentication(new CookieAuthenticationOptions {
    AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
    LoginPath = new PathString("/Account/Login"),
    Provider = new CookieAuthenticationProvider {
        // Enables the application to validate the security stamp when the user logs in.
        // This is a security feature which is used when you change a password or add an external login to your account.  
        OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<ApplicationUserManager, ApplicationUser>(
            validateInterval: TimeSpan.FromMinutes(30),
            regenerateIdentity: (manager, user) => user.GenerateUserIdentityAsync(manager))
    }
});

Se la tua app desidera attivare esplicitamente questo comportamento, può chiamare:

UserManager.UpdateSecurityStampAsync(userId);

Ormai UseCookieAuthentication è obsoleto . Sono riuscito a configurarlo usando

services.Configure<SecurityStampValidatorOptions>(o => 
    o.ValidationInterval = TimeSpan.FromSeconds(10));

Spostato da risposta a risposta per richiesta .

Ho osservato che SecurityStamp è richiesto per la verifica del token.

Per repository: impostare SecurityStamp su null nel databsae Genera un token (funziona bene) Verifica token (non riesce)