asp.net - tables - identity asp mvc
¿Qué es la interfaz IUserSecurityStampStore<TUser> de ASP.NET Identity? (3)
Al examinar ASP.NET Identity (nueva implementación de membresía en ASP.NET), encontré esta interfaz al implementar mi propia 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
es implementado por el EntityFramework.UserStore<TUser>
por defecto EntityFramework.UserStore<TUser>
que esencialmente obtiene y configura la propiedad TUser.SecurityStamp
.
Después de excavar un poco más, parece que un SecurityStamp
es un Guid
que se genera nuevamente en puntos clave del UserManager
(por ejemplo, cambio de contraseñas).
Realmente no puedo descifrar mucho más allá de esto ya que estoy examinando este código en Reflector . Casi todo el símbolo y la información asíncrona han sido optimizados.
Además, Google no ha sido de mucha ayuda.
Las preguntas son:
- ¿Qué es un
SecurityStamp
en ASP.NET Identity y para qué se utiliza? - ¿
SecurityStamp
juega algún papel cuando se crean cookies de autenticación? - ¿Hay alguna ramificación de seguridad o precauciones que deben tomarse con esto? Por ejemplo, no envíe este valor en sentido descendente a los clientes?
Actualización (16/09/2014)
Código fuente disponible aquí:
Esto pretende representar la instantánea actual de las credenciales de su usuario. Entonces, si nada cambia, el sello seguirá siendo el mismo. Pero si se cambia la contraseña del usuario o se elimina un inicio de sesión (desvincula su cuenta de google / fb), el sello cambiará. Esto es necesario para cosas como la firma automática de usuarios / rechazo de cookies antiguas cuando esto ocurre, que es una característica que viene en 2.0.
La identidad aún no es de código abierto, todavía está en la fase de tramitación.
Editar: actualizado para 2.0.0. Por lo tanto, el objetivo principal de SecurityStamp
es habilitar el cierre de sesión en todas partes. La idea básica es que cada vez que se modifique algo relacionado con la seguridad del usuario, como una contraseña, es una buena idea anular automáticamente cualquier cookie de inicio de sesión existente, por lo que si su contraseña / cuenta se vio comprometida previamente, el atacante ya no tendrá acceso.
En 2.0.0 agregamos la siguiente configuración para enganchar el método OnValidateIdentity
en CookieMiddleware
para mirar SecurityStamp
y rechazar cookies cuando ha cambiado. También actualiza automáticamente las reclamaciones del usuario de la base de datos cada refreshInterval
si el sello no se modifica (lo cual se encarga de cosas como cambiar roles, etc.)
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))
}
});
Si su aplicación desea activar este comportamiento explícitamente, puede llamar a:
UserManager.UpdateSecurityStampAsync(userId);
La UseCookieAuthentication está en deprecated por ahora. Logré configurarlo usando
services.Configure<SecurityStampValidatorOptions>(o =>
o.ValidationInterval = TimeSpan.FromSeconds(10));
Se movió de la respuesta a la respuesta por request .
Observé que se requiere SecurityStamp para la verificación de tokens.
Para repo: Establecer SecurityStamp para anular en el databsae Generar un token (funciona bien) Verificar token (falla)