web-dev-qa-db-fra.com

Quel est l'intérêt de configurer DefaultScheme et DefaultChallengeScheme sur ASP.NET Core?

J'apprends comment fonctionne la sécurité sur ASP.NET Core 2.0 et IdentityServer4. J'ai mis en place les projets avec IdentityServer, API et ASP.NET Core MVC Client App.

ConfigureService méthode sur l'application client comme ci-dessous. Ici, je suis confus sur DefaultScheme et DefaultChallengeScheme. Quel est l'intérêt de les configurer? Une description détaillée de son fonctionnement serait très utile si possible.

J'ai déjà vu au lieu de DefaultScheme, DefaultSignInScheme fonctionne aussi, mais comment ça marche? Quelle est la différence de ceux-ci?

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();
    JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();

    services.AddAuthentication(options =>
    {
        options.DefaultScheme = "Cookies";
        options.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
        //options.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
        //options.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
    })
    .AddCookie("Cookies")
    .AddOpenIdConnect(OpenIdConnectDefaults.AuthenticationScheme, options =>
    {
        options.SignInScheme = "Cookies";
        options.RequireHttpsMetadata = false;

        options.Authority = "http://localhost:5000/";
        options.ClientId = "mvcclient";
        options.SaveTokens = true;
    });
}
c#asp.net-coreidentityserver4asp.net-authentication
14
Amal Shalika

Tout d'abord, notez que vous n'utilisez pas ASP.NET Core Identity là-bas. L'identité est la pile de gestion des utilisateurs qui construit en haut du système d'authentification. Vous semblez utiliser OpenID Connect avec un IdentityServer en tant que fournisseur, de sorte que votre application Web ne consommera que les informations OIDC mais n'aura pas à gérer ses propres identités (il se peut cependant que l'IdentityServer utilise ASP.NET Core Identity).

La façon dont la pile d'authentification fonctionne dans ASP.NET Core est que vous pouvez configurer un ensemble de schémas d'authentification. Certains de ces schémas sont destinés à être utilisés en combinaison, par exemple le schéma d'authentification par cookie est rarement utilisé seul, mais il existe également des schémas qui peuvent être utilisés complètement séparément (par exemple l'authentification JWT Bearer).

Actions d'authentification

Dans le monde de l'authentification, vous pouvez effectuer certaines actions:

  • Authentifier : authentifier signifie essentiellement utiliser les informations fournies et tenter d'authentifier l'utilisateur avec ces informations. Donc, cela tentera de créer une identité d'utilisateur et de la rendre disponible pour le framework.

    Par exemple, le schéma d'authentification des cookies utilise des données de cookies pour restaurer l'identité de l'utilisateur. Ou le schéma d'authentification JWT Bearer utilisera le jeton fourni dans le cadre de l'en-tête Authorization dans la demande pour créer l'identité de l'utilisateur.

  • Challenge : Lorsqu'un schéma d'authentification est contesté, le schéma devrait inviter l'utilisateur à s'authentifier. Cela pourrait par exemple signifier que l'utilisateur est redirigé vers un formulaire de connexion, ou qu'il y aura une redirection vers un fournisseur d'authentification externe.

  • Interdire : Lorsqu'un schéma d'authentification est interdit, le schéma répond simplement par quelque chose qui dit à l'utilisateur qu'il ne peut pas faire ce qu'il a tenté de faire. Il s'agit généralement d'une erreur HTTP 4 , et peut être une redirection vers une page d'erreur.

  • Connexion : Lorsqu'un schéma d'authentification est connecté, alors le schéma est invité à prendre un utilisateur existant (un ClaimsPrincipal ) et de persister en quelque sorte. Par exemple, la connexion d'un utilisateur au schéma d'authentification par cookie créera essentiellement un cookie contenant l'identité de cet utilisateur.

  • Déconnexion : Ceci est l'inverse de la connexion et indiquera essentiellement au schéma d'authentification de supprimer cette persistance. La déconnexion du système de cookies expirera effectivement le cookie.

Notez que tous les schémas d'authentification ne peuvent pas exécuter toutes les options. La connexion et la déconnexion sont généralement des actions spéciales. Le schéma d'authentification des cookies est un exemple qui prend en charge la connexion et la déconnexion, mais le schéma OIDC, par exemple, ne peut pas le faire, mais s'appuiera sur un schéma différent pour se connecter et conserver l'identité. C'est pourquoi vous verrez généralement le schéma de cookies avec lui également.

Flux d'authentification typique

Les schémas d'authentification peuvent être utilisés explicitement. Lorsque vous utilisez l'une des méthodes d'extension d'authentification HttpContext , par exemple httpContext.AuthenticateAsync() , vous pouvez toujours spécifier explicitement quelle authentification schéma que vous souhaitez utiliser pour cette opération.

Par exemple, si vous souhaitez vous connecter avec le schéma d'authentification des cookies "Cookie", vous pouvez simplement l'appeler ainsi à partir de votre code:

 var user = new ClaimsPrincipal(…);
 await httpContext.SignInAsync(user, "Cookie");

Mais en pratique, appeler l'authentification directement et explicitement comme ça n'est pas la chose la plus courante à faire. Au lieu de cela, vous comptez généralement sur le cadre pour effectuer l'authentification pour vous. Et pour cela, le framework doit savoir quel schéma d'authentification utiliser pour quelle opération.

C'est à cela que servent les AuthenticationOptions . Vous pouvez configurer ces options afin de pouvoir définir explicitement le schéma d'authentification à utiliser par défaut pour chacune de ces actions d'authentification:

Vous ne configurez généralement pas tous ces propriétés. Au lieu de cela, le cadre a des solutions de rechange par défaut, vous pouvez donc configurer uniquement un sous-ensemble de ces propriétés. La logique est la suivante:

  • Authentifier: DefaultAuthenticateScheme ou DefaultScheme
  • Défi: DefaultChallengeScheme ou DefaultScheme
  • Interdire: DefaultForbidScheme, ou DefaultChallengeScheme, ou DefaultScheme
  • Connexion: DefaultSignInScheme ou DefaultScheme
  • Déconnexion: DefaultSignOutScheme ou DefaultScheme

Comme vous pouvez le voir, chacune des actions d'authentification revient à DefaultScheme si la valeur par défaut de l'action spécifique n'est pas configurée. Donc, ce que vous verrez généralement, c'est la configuration de DefaultScheme, puis les actions spécifiques sont configurées pour celles où un schéma différent est requis.

Votre exemple le montre assez bien: avec OIDC, vous aurez besoin d'un schéma de connexion qui peut conserver l'identité fournie par le fournisseur d'authentification externe. Ainsi, vous verrez généralement les schémas d'authentification OIDC et cookie:

services.AddAuthentication(options =>
{
    options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
    options.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
})
.AddCookie()
.AddOpenIdConnect(options =>
{
    options.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
});

Pour l'utilisateur, l'interaction normale se fait via le schéma d'authentification des cookies: lorsqu'ils accèdent à l'application Web, le schéma d'authentification des cookies tentera de les authentifier à l'aide de leur cookie. Donc, en utilisant le schéma d'authentification des cookies comme schéma par défaut pour toutes les opérations.

L'exception est lors de la contestation de l'authentification: dans ce cas, nous voulons que l'utilisateur soit redirigé vers le fournisseur OIDC, afin qu'il puisse s'y connecter et revenir avec une identité. Nous avons donc défini le schéma par défaut challenge sur le schéma OIDC.

De plus, nous lions également le schéma OIDC au schéma de cookies. Lorsque l'utilisateur est mis au défi et se connecte avec son fournisseur d'authentification externe, il est renvoyé à l'application Web avec son identité externe. Le schéma OIDC ne peut cependant pas conserver cette identité, il signe donc en utilisant un schéma différent - le schéma des cookies - qui conservera ensuite l'identité au nom du schéma OIDC. Ainsi, le schéma de cookies créera un cookie pour l'identité OIDC, et à la prochaine demande, le schéma de cookies (qui est le schéma par défaut) pourra authentifier à nouveau l'utilisateur à l'aide de ce cookie.

Donc, la plupart du temps, vous pourrez simplement spécifier le schéma par défaut, puis en fonction de votre configuration d'authentification, vous pouvez modifier une ou deux actions explicites. Mais théoriquement, vous pouvez totalement configurer une configuration très complexe de différents paramètres par défaut et de plusieurs schémas: le cadre vous donne beaucoup de flexibilité ici.

24
poke