web-dev-qa-db-fra.com

Qu'est-ce que l'interface IUserSecurityStampStore <TUser> d'ASP.NET Identity?

En regardant ASP.NET Identity (implémentation de nouveaux membres dans ASP.NET), je suis tombé sur cette interface lors de la mise en œuvre de ma propre 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 est implémenté par le défaut EntityFramework.UserStore<TUser> qui obtient et définit essentiellement la propriété TUser.SecurityStamp.

Après quelques efforts supplémentaires, il apparaît que SecurityStamp est un Guid nouvellement généré à des points clés de la UserManager (par exemple, modification des mots de passe).

Je ne peux pas vraiment déchiffrer beaucoup plus que cela puisque j'examine ce code dans Reflector . Presque toutes les informations de symbole et asynchrones ont été optimisées.

En outre, Google n'a pas beaucoup aidé.

Les questions sont:

  • Qu'est-ce qu'un SecurityStamp dans ASP.NET Identity et à quoi sert-il?
  • Est-ce que SecurityStamp joue un rôle quelconque lors de la création de cookies d'authentification?
  • Y a-t-il des ramifications de sécurité ou des précautions à prendre avec cela? Par exemple, n'envoyez-vous pas cette valeur en aval aux clients?

Mise à jour (16/09/2014)

Code source disponible ici:

163
Brian Chavez

Ceci est censé représenter l'instantané actuel des informations d'identification de votre utilisateur. Donc, si rien ne change, le tampon restera le même. Mais si le mot de passe de l'utilisateur est modifié ou si un identifiant est supprimé (dissociez votre compte google/fb), le cachet changera. Cela est nécessaire pour des tâches telles que la signature automatique des utilisateurs/le rejet des anciens cookies lorsque cela se produit, ce qui est une fonctionnalité à venir dans la version 2.0.

L'identité n'est pas encore open source, elle est toujours en cours de développement.

Edit: Updated for 2.0.0. Donc, le but principal de la SecurityStamp est d’autoriser la déconnexion partout. L'idée de base est que chaque fois que quelque chose lié à la sécurité est modifié sur l'utilisateur, tel qu'un mot de passe, il est judicieux d'invalider automatiquement tous les cookies de connexion existants. Ainsi, si votre mot de passe/compte a déjà été compromis, l'attaquant n'a plus accès.

Dans la version 2.0.0, nous avons ajouté la configuration suivante pour associer la méthode OnValidateIdentity à la méthode CookieMiddleware afin d’examiner le SecurityStamp et de rejeter les cookies lorsqu’elle a été modifiée. Il actualise également automatiquement les revendications de l'utilisateur à partir de la base de données chaque refreshInterval si le tampon est inchangé (ce qui prend en charge des tâches telles que la modification des rôles, 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 votre application souhaite déclencher ce comportement de manière explicite, elle peut appeler:

UserManager.UpdateSecurityStampAsync(userId);
208
Hao Kung

UseCookieAuthentication est obsolète à présent. J'ai réussi à le configurer en utilisant

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

Déplacé de réponse à réponse par demande .

4
riezebosch

J'ai observé que SecurityStamp était requis pour la vérification des jetons.

Pour repo: Définissez SecurityStamp sur null dans le databsae Générer un jeton (fonctionne bien) Vérifier le jeton (échec)

3
KierenH