À quoi sert CookieAuthenticationOptions.AuthenticationType?

Question

Dans ma configuration Asp.Net Identity Auth application middleware Je

app.UseCookieAuthentication(new CookieAuthenticationOptions { 
    LoginPath = new PathString("/Login/"), 
    //AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie, 
    Provider = new CookieAuthenticationProvider { 
    OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<MyUserManager, MyUser>(
         TimeSpan.FromMinutes(30), 
         (manager, user) => manager.CreateIdentityAsync(user, DefaultAuthenticationTypes.ApplicationCookie) 
        ), 
    }, 
}); 

j'avais copié cette d'une autre application et je viens de remarquer que si je décommentez la ligne AuthenticationType, connexion réussit (je reçois un message de réussite dans mon enregistreur écrit à partir de mon contrôleur) mais toujours redirige vers l'écran de connexion.

Dans le documentation for CookieAuthenticationOptions il dit

Le AuthenticationType dans les options correspond à la propriété IIdentity AuthenticationType. Une valeur peut être assignée afin d'utiliser le même type de middleware d'authentification plus d'une fois dans un pipeline. (Hérité de AuthenticationOptions.)

Je ne comprends pas vraiment ce que cela signifie, pourquoi cela causerait ma connexion demande d'être redirigé (après une connexion réussie pas moins), ni ce que cette option serait utile.

Answer 1

Ceci est une chaîne de caractères et peut être n'importe quoi. Mais ceci est un identifiant pour le type d'authentification. Et vous pouvez avoir plusieurs types d'authentification: votre base de données avec les utilisateurs, Google, Facebook, etc. Autant que je me souvienne, ceci est ajouté comme une réclamation au cookie généré lors de la connexion.

Vous devez connaître le fournisseur d'authentification lorsque vous vous déconnectez. Si votre middleware d'authentification est définie comme ceci:

app.UseCookieAuthentication(new CookieAuthenticationOptions { 
     LoginPath = new PathString("/Login/"), 
     AuthenticationType = "My-Magical-Authentication", 
     // etc... 
     }, 
    }); 

alors la connexion utilisateur dont vous avez besoin sur la même chaîne magique: AuthenticationManager.SignOut("My-Magical-Authentication")

De plus, cette chaîne est passée dans ClaimsIdentity quand principale est créée.Et sans AuthenticationType principale ne peut pas être authentifié because:

/// <summary> 
/// Gets a value that indicates whether the identity has been authenticated. 
/// </summary> 
/// 
/// <returns> 
/// true if the identity has been authenticated; otherwise, false. 
/// </returns> 
public virtual bool IsAuthenticated 
{ 
    get 
    { 
    return !string.IsNullOrEmpty(this.m_authenticationType); 
    } 
} 

Cette méthode IsAuthenticated est utilisé par le code-base entière MVC, avec tous les mécanismes d'authentification reposant sur ce point.

En théorie, vous pouvez également vous connecter via plusieurs fournisseurs et n'en signer qu'un seul à la fois, laissant le reste des fournisseurs encore authentifiés. Bien que je n'ai jamais essayé ça.

Une autre utilisation que je viens de trouver - si vous ne fournissez pas CookieName dans votre configuration de middleware, alors Options.CookieName = CookieAuthenticationDefaults.CookiePrefix + Options.AuthenticationType; (see second if statement in constructor).

Je suis sûr qu'il y a plus d'endroits où il est utilisé. Mais le plus important est de le fournir et d'être cohérent avec le nom ou vous obtiendrez des bugs subtils dans le système d'authentification.

Answer 2

Je ne connais pas toute la réponse, mais j'ai un exemple sur ce que serait utile pour.

J'ai un site Web multi-locataire: le site Web s'exécute comme une instance unique plusieurs domaines sont liés à celui-ci. Chaque domaine est un locataire distinct (avec un ensemble distinct d'utilisateurs). Pour mettre en place une connexion Facebook par locataire, j'avais besoin d'une application Facebook par locataire. Pour configurer cela, je devais mettre un CallbackPath unique, et un AuthenticationType unique par locataire:

var facebookOptions = new FacebookAuthenticationOptions 
{ 
    AuthenticationType = "Facebook-{tenantID}", 
    CallbackPath = new PathString($"/signin-facebook-{tenantID}") 
} 

Je pensais que c'était aussi utilisé comme un nom de cookie, mais ce n'est pas le cas pour une connexion externe comme FacebookAuthentication. Ce que j'ai remarqué est que cette valeur de AuthenticationType surgit lors de la demande:

1. la IdentityUserLogin.LoginProvider via authenticationManager.GetExternalLoginInfoAsync()
2. la AuthenticationDescription.AuthenticationType via authenticationManager.GetExternalAuthenticationTypes() (semble logique ;-))
3. le IdentityUserLogin.LoginProvider pour chaque user.Logins (semblables à 1)

et dernier mais pas moins: la valeur de AuthenticationType est stockée dans la colonne de base de données AspNetU serLogins.LoginProvider.

Answer 3

Si vous configurez une nouvelle solution de asp.net, le code de configuration standard (par opposition au code copié d'une autre application) dans Startup.Auth COMPREND la ligne AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,

Cela crée une cookie (avec un nom par défaut de .AspNet.ApplicationCookie), que vous pouvez voir si vous regardez dans la liste des cookies actifs de votre navigateur, qui est utilisé (entre autres) pour vérifier si l'utilisateur est authentifié pour chaque demande. Si le cookie n'est pas présent (ou si l'utilisateur n'est pas authentifié), le logiciel intermédiaire redirige vers l'itinéraire spécifié dans votre ligne. il existe une autre configuration non standard dans votre code pour authentifier l'utilisateur. Si vous décommentez cette ligne et que la connexion réussit mais redirige vers la connexion, cela suggère qu'il y a un conflit entre le code non standard et le middleware qui entraîne le middleware à déterminer que l'utilisateur n'est pas authentifié et est redirigé vers le LoginPath .

Je voudrais savoir s'il existe un code d'authentification non standard dans votre application et déterminer ce que cela fait spécifiquement, et la réponse au conflit devrait se présenter. Le conseil général n'est pas de changer le code d'authentification standard à moins que vous sachiez exactement quelles sont les implications de cela (et cela peut devenir compliqué, avec beaucoup de pièges pour les imprudents).

Spécifiquement à votre question, cette option n'est pas seulement utile, elle est fondamentale pour le fonctionnement standard du middleware Identity. Vous semblez avoir un code non standard dans votre application. Si c'est le cas, vous devez déterminer entièrement ce qu'il fait (et ses implications) en ce qui concerne la sécurité de connexion, ou revenir au code d'identité standard si vous le pouvez.