Configurer l’authentification Windows dans ASP.NET Core

L’authentification Windows (également appelée authentification Negotiate, Kerberos ou NTLM) peut être configurée pour les applications ASP.NET Core hébergées avec IIS, Kestrel, ou HTTP.sys.

L’authentification Windows s’appuie sur le système d’exploitation pour authentifier les utilisateurs des applications ASP.NET Core. L’authentification Windows est utilisée pour les serveurs qui s’exécutent sur un réseau d’entreprise à l’aide d’identités de domaine Active Directory ou de comptes Windows pour identifier les utilisateurs. L’authentification Windows est mieux adaptée aux environnements intranet où les utilisateurs, les applications clientes et les serveurs web appartiennent au même domaine Windows.

Scénarios avec un proxy et un équilibreur de charge

L’authentification Windows est un scénario avec état principalement utilisé dans un intranet, où un proxy ou un équilibreur de charge ne gère généralement pas le trafic entre les clients et les serveurs. Si un proxy ou un équilibreur de charge est utilisé, l’authentification Windows fonctionne uniquement si le proxy ou l’équilibreur de charge :

• Gère l’authentification.
• Transmet les informations d’authentification utilisateur à l’application (par exemple, dans un en-tête de demande), qui agit sur les informations d’authentification.

Une alternative à l’authentification Windows dans les environnements où les proxys et les équilibreurs de charge sont utilisés est Active Directory Federated Services (ADFS) avec OpenID Connect (OIDC).

IIS/IIS Express

Ajoutez le package NuGet Microsoft.AspNetCore.Authentication.Negotiate et les services d’authentification en appelant AddAuthentication dans Program.cs :

using Microsoft.AspNetCore.Authentication.Negotiate;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
   .AddNegotiate();

builder.Services.AddAuthorization(options =>
{
    options.FallbackPolicy = options.DefaultPolicy;
});
builder.Services.AddRazorPages();

var app = builder.Build();
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthentication();
app.UseAuthorization();

app.MapRazorPages();

app.Run();

Le code précédent a été généré par le modèle ASP.NET Core Razor Pages avec l’authentification Windows spécifiée.

Paramètres de lancement (débogueur)

La configuration des paramètres de lancement affecte uniquement le fichier Properties/launchSettings.json pour IIS Express et ne configure pas IIS pour l’authentification Windows. La configuration du serveur est expliquée dans la section IIS.

Les modèles d’application web disponibles via Visual Studio ou l’interface CLI .NET peuvent être configurés pour prendre en charge l’authentification Windows, qui met à jour le fichier Properties/launchSettings.json automatiquement.

"iisSettings": {
    "windowsAuthentication": true,
    "anonymousAuthentication": false,
    "iisExpress": {
        "applicationUrl": "http://localhost:52171/",
        "sslPort": 44308
    }
}

dotnet new webapp --auth Windows

"iisSettings": {
    "windowsAuthentication": true,
    "anonymousAuthentication": false,
    "iisExpress": {
        "applicationUrl": "http://localhost:52171/",
        "sslPort": 44308
    }
}

IIS

IIS utilise également le Module ASP.NET Core pour héberger des applications ASP.NET Core. L’authentification Windows est configurée pour IIS via le fichier web.config. Les sections suivantes décrivent diverses opérations :

• Fournissez un fichier web.config local qui active l’authentification Windows sur le serveur lorsque l’application est déployée.
• Utilisez le Gestionnaire des services IIS pour configurer le fichier web.config d’une application ASP.NET Core qui a déjà été déployée sur le serveur.

Si ce n’est déjà fait, activez IIS pour héberger des applications ASP.NET Core. Pour plus d’informations, consultez Héberger ASP.NET Core sur Windows avec IIS.

Activez le service de rôle IIS pour l’authentification Windows. Pour plus d’informations, consultez Activer l’authentification Windows dans les services de rôle IIS (voir Étape 2).

L’intergiciel d’intégration IIS est configuré pour authentifier automatiquement les requêtes par défaut. Pour plus d’informations, consultez Héberger ASP.NET Core sur Windows avec IIS : options IIS (AutomaticAuthentication).

Le module ASP.NET Core est configuré pour transférer le jeton d’authentification Windows à l’application par défaut. Pour plus d’informations, consultez Informations de référence sur la configuration du module ASP.NET Core : attributs de l’élément aspNetCore.

Utilisez l’une des approches suivantes :

• Avant de publier et de déployer le projet, ajoutez le fichier web.config suivant à la racine du projet :

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <location path="." inheritInChildApplications="false">
      <system.webServer>
        <security>
          <authentication>
            <anonymousAuthentication enabled="false" />
            <windowsAuthentication enabled="true" />
          </authentication>
        </security>
      </system.webServer>
    </location>
  </configuration>
  

  Lorsque le projet est publié par le kit SDK .NET Core (sans la propriété <IsTransformWebConfigDisabled> définie sur true dans le fichier projet), le fichier web.config publié inclut la section <location><system.webServer><security><authentication>. Pour plus d’informations sur la propriété <IsTransformWebConfigDisabled>, consultez Héberger ASP.NET Core sur Windows avec IIS.

• Après avoir publié et déployé le projet, effectuez une configuration côté serveur avec le Gestionnaire des services IIS :

  1. Dans le Gestionnaire des services IIS, sélectionnez le site IIS sous le nœud Sites de la barre latérale Connexions.
  2. Double-cliquez sur Authentification dans la zone IIS.
  3. Sélectionnez Authentification anonyme. Sélectionnez Désactiver dans la barre latérale Actions.
  4. Sélectionnez Authentification Windows. Sélectionnez Activer dans la barre latérale Actions.

  Lorsque ces actions sont effectuées, le Gestionnaire des services IIS modifie le fichier web.config de l’application. Un nœud <system.webServer><security><authentication> est ajouté avec les paramètres mis à jour pour anonymousAuthentication et windowsAuthentication :

  <system.webServer>
    <security>
      <authentication>
        <anonymousAuthentication enabled="false" />
        <windowsAuthentication enabled="true" />
      </authentication>
    </security>
  </system.webServer>
  

  La section <system.webServer> ajoutée au fichier web.config par le Gestionnaire des services IIS est en dehors de la section <location> de l’application ajoutée par le kit SDK .NET Core lors de la publication de l’application. Étant donné que la section est ajoutée en dehors du nœud <location>, les paramètres sont hérités par les sous-applications de l’application actuelle. Pour empêcher l’héritage, déplacez la section <security> ajoutée à l’intérieur de la section <location><system.webServer> fournie par le kit SDK .NET Core.

  Lorsque le Gestionnaire des services IIS est utilisé pour ajouter la configuration IIS, il affecte uniquement le fichier web.config de l’application sur le serveur. Un déploiement ultérieur de l’application peut remplacer les paramètres sur le serveur si la copie de web.config du serveur est remplacée par le fichier web.config du projet. Utilisez l’une des approches suivantes pour gérer les paramètres :

  • Utilisez le Gestionnaire des services IIS pour réinitialiser les paramètres du fichier web.config après le remplacement du fichier lors du déploiement.
  • Ajoutez un fichier web.config à l’application localement avec les paramètres.

Kestrel

Le package NuGet Microsoft.AspNetCore.Authentication.Negotiate peut être utilisé avec Kestrel pour prendre en charge l’authentification Windows à l’aide de Negotiate et Kerberos sur Windows, Linux et macOS.

L’authentification est activée par le code suivant mis en surbrillance pour Program.cs :

using Microsoft.AspNetCore.Authentication.Negotiate;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
   .AddNegotiate();

builder.Services.AddAuthorization(options =>
{
    options.FallbackPolicy = options.DefaultPolicy;
});
builder.Services.AddRazorPages();

var app = builder.Build();
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthentication();
app.UseAuthorization();

app.MapRazorPages();

app.Run();

Le code précédent a été généré par le modèle ASP.NET Core Razor Pages avec l’authentification Windows spécifiée. Les API suivantes sont utilisées dans le code précédent :

• AddAuthentication
• AddNegotiate
• UseAuthentication

Authentification Kerberos et contrôle d’accès en fonction du rôle (RBAC)

L’authentification Kerberos sur Linux ou macOS ne fournit aucune information de rôle pour un utilisateur authentifié. Pour ajouter des informations de rôle et de groupe à un utilisateur Kerberos, le gestionnaire d’authentification doit être configuré pour récupérer les rôles à partir d’un domaine LDAP. La configuration la plus simple spécifie uniquement un domaine LDAP sur lequel interroger et utilise le contexte de l’utilisateur authentifié pour interroger le domaine LDAP :

using Microsoft.AspNetCore.Authentication.Negotiate;
using System.Runtime.InteropServices;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
    .AddNegotiate(options =>
    {
        if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
        {
            options.EnableLdap("contoso.com");
        }
    });

Certaines configurations peuvent nécessiter des informations d’identification spécifiques pour interroger le domaine LDAP. Les informations d’identification peuvent être spécifiées dans les options mises en évidence suivantes :

using Microsoft.AspNetCore.Authentication.Negotiate;
using System.Runtime.InteropServices;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
        .AddNegotiate(options =>
        {
            if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
            {
                options.EnableLdap(settings =>
                {
                    settings.Domain = "contoso.com";
                    settings.MachineAccountName = "machineName";
                    settings.MachineAccountPassword =
                                      builder.Configuration["Password"];
                });
            }
        });

builder.Services.AddRazorPages();

Par défaut, le gestionnaire d’authentification Negotiate résout les domaines imbriqués. Dans un environnement LDAP volumineux ou complexe, la résolution des domaines imbriqués peut entraîner une recherche lente ou une grande quantité de mémoire utilisée pour chaque utilisateur. La résolution de domaines imbriqués peut être désactivée à l’aide de l’option IgnoreNestedGroups.

Les requêtes anonymes sont autorisées. Utilisez l’autorisation ASP.NET Core pour valider les demandes anonymes d’authentification.

Configuration de l’environnement Windows

Le composant Microsoft.AspNetCore.Authentication.Negotiate effectue l’authentification en mode utilisateur. Les noms de principal du service (SPN) doivent être ajoutés au compte d’utilisateur exécutant le service, et non au compte d’ordinateur. Exécutez setspn -S HTTP/myservername.mydomain.com myuser dans un interpréteur de commandes d’administration.

Kerberos et NTLM

Le package Negotiate sur Kestrel for ASP.NET Core tente d’utiliser Kerberos, qui est un schéma d’authentification plus sécurisé et plus performant que NTLM :

using Microsoft.AspNetCore.Authentication.Negotiate;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
   .AddNegotiate();

builder.Services.AddAuthorization(options =>
{
    options.FallbackPolicy = options.DefaultPolicy;
});
builder.Services.AddRazorPages();

var app = builder.Build();

NegotiateDefaults.AuthenticationScheme spécifie Kerberos, car il s’agit de la valeur par défaut.

IIS, IISExpress et Kestrel prennent en charge Kerberos et NTLM.

L’examen de l’en-tête WWW-Authenticate: à l’aide d’IIS ou d’IISExpress avec un outil comme Fiddler affiche Negotiate ou NTLM.

Kestrel affiche uniquement WWW-Authenticate: Negotiate

L’en-tête WWW-Authenticate: Negotiate signifie que le serveur peut utiliser NTLM ou Kerberos. Kestrel nécessite le préfixe d’en-tête Negotiate. Il ne prend pas en charge la spécification NTLM directe dans les en-têtes d’authentification de demande ou de réponse. NTLM est pris en charge dans Kestrel, mais il doit être envoyé en tant que Negotiate.

Sur Kestrel, pour voir si NTLM ou Kerberos est utilisé, Base64 décode l’en-tête et affiche NTLM ou HTTP. HTTP indique que Kerberos a été utilisé.

Configuration de l’environnement Linux et macOS

Des instructions pour joindre une machine Linux ou macOS à un domaine Windows sont disponibles dans l’article Connecter Azure Data Studio à votre instance SQL Server à l’aide de l’authentification Windows - Kerberos. Les instructions créent un compte d’ordinateur pour la machine Linux sur le domaine. Les SPN doivent être ajoutés à ce compte d’ordinateur.

Une fois que la machine Linux ou macOS est jointe au domaine, des étapes supplémentaires sont nécessaires pour fournir un fichier keytab avec les SPN :

• Sur le contrôleur de domaine, ajoutez de nouveaux SPN de service web au compte d’ordinateur :
  • setspn -S HTTP/mywebservice.mydomain.com mymachine
  • setspn -S HTTP/mywebservice@MYDOMAIN.COM mymachine
• Utilisez ktpass pour générer un fichier keytab :
  • ktpass -princ HTTP/mywebservice.mydomain.com@MYDOMAIN.COM -pass myKeyTabFilePassword -mapuser MYDOMAIN\mymachine$ -pType KRB5_NT_PRINCIPAL -out c:\temp\mymachine.HTTP.keytab -crypto AES256-SHA1
  • Certains champs doivent être spécifiés en majuscules comme indiqué.
• Copiez le fichier keytab sur l’ordinateur Linux ou macOS.
• Sélectionnez le fichier keytab via une variable d’environnement : export KRB5_KTNAME=/tmp/mymachine.HTTP.keytab
• Appelez klist pour afficher les SPN actuellement disponibles.

HTTP.sys

HTTP.sys prend en charge l’authentification Windows en mode noyau à l’aide de l’authentification Negotiate, NTLM ou de base.

Le code suivant ajoute l’authentification et configure l’hôte web de l’application pour utiliser HTTP.sys avec l’authentification Windows :

using Microsoft.AspNetCore.Server.HttpSys;
using System.Runtime.InteropServices;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(HttpSysDefaults.AuthenticationScheme);

if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
{
    builder.WebHost.UseHttpSys(options =>
        {
            options.Authentication.Schemes =
                AuthenticationSchemes.NTLM |
                AuthenticationSchemes.Negotiate;
            options.Authentication.AllowAnonymous = false;
        });
}

Autoriser les utilisateurs

L’état de configuration de l’accès anonyme détermine la façon dont les attributs [Authorize] et [AllowAnonymous] sont utilisés dans l’application. Les deux sections suivantes expliquent comment gérer les états de configuration non autorisé et autorisé de l’accès anonyme.

Interdire l’accès anonyme

Lorsque l’authentification Windows est activée et que l’accès anonyme est désactivé, les attributs [Authorize] et [AllowAnonymous] n’ont aucun effet. Si un site IIS est configuré pour interdire l’accès anonyme, la demande n’atteint jamais l’application. Pour cette raison, l’attribut [AllowAnonymous] n’est pas applicable.

Autoriser l'accès anonyme

Lorsque l’authentification Windows et l’accès anonyme sont activés, utilisez les attributs [Authorize] et [AllowAnonymous]. L’attribut [Authorize] vous permet de sécuriser les points de terminaison de l’application qui nécessitent une authentification. L’attribut [AllowAnonymous] remplace l’attribut [Authorize] dans les applications qui autorisent l’accès anonyme. Pour plus d’informations sur l’utilisation des attributs, consultez Autorisation simple dans ASP.NET Core.

Emprunt d'identité

ASP.NET Core n’implémente pas l’emprunt d’identité. Les applications s’exécutent avec l’identity de l’application pour toutes les demandes, à l’aide d’un pool d’applications ou d’une identity de processus. Si l’application doit effectuer une action pour le compte d’un utilisateur, utilisez WindowsIdentity.RunImpersonated ou RunImpersonatedAsync dans un middleware terminal en ligne dans Program.cs. Exécutez une seule action dans ce contexte, puis fermez le contexte.

app.Run(async (context) =>
{
    try
    {
        var user = (WindowsIdentity)context.User.Identity!;

        await context.Response
            .WriteAsync($"User: {user.Name}\tState: {user.ImpersonationLevel}\n");

        await WindowsIdentity.RunImpersonatedAsync(user.AccessToken, async () =>
        {
            var impersonatedUser = WindowsIdentity.GetCurrent();
            var message =
                $"User: {impersonatedUser.Name}\t" +
                $"State: {impersonatedUser.ImpersonationLevel}";

            var bytes = Encoding.UTF8.GetBytes(message);
            await context.Response.Body.WriteAsync(bytes, 0, bytes.Length);
        });
    }
    catch (Exception e)
    {
        await context.Response.WriteAsync(e.ToString());
    }
});

Bien que le package Microsoft.AspNetCore.Authentication.Negotiate active l’authentification sur Windows, Linux et macOS, l’emprunt d’identité n’est pris en charge que sur Windows.

Transformations de revendication

Dans le cas d’un hébergement avec IIS, AuthenticateAsync n’est pas appelé en interne pour initialiser un utilisateur. Par conséquent, une implémentation de IClaimsTransformation utilisée pour transformer les revendications après chaque authentification n’est pas activée par défaut. Pour plus d’informations et un exemple de code qui active les transformations de revendications, consultez Différences entre l’hébergement in-process et out-of-process.

Ressources supplémentaires

• dotnet publish
• Héberger ASP.NET Core sur Windows avec IIS
• Module ASP.NET Core (ANCM) pour IIS
• Profils de publication Visual Studio (.pubxml) pour le déploiement d’applications ASP.NET Core

L’authentification Windows (également appelée authentification Negotiate, Kerberos ou NTLM) peut être configurée pour les applications ASP.NET Core hébergées avec IIS, Kestrel, ou HTTP.sys.

L’authentification Windows s’appuie sur le système d’exploitation pour authentifier les utilisateurs des applications ASP.NET Core. Vous pouvez utiliser l’authentification Windows lorsque votre serveur s’exécute sur un réseau d’entreprise à l’aide d’identités de domaine Active Directory ou de comptes Windows pour identifier les utilisateurs. L’authentification Windows est mieux adaptée aux environnements intranet où les utilisateurs, les applications clientes et les serveurs web appartiennent au même domaine Windows.

Scénarios avec un proxy et un équilibreur de charge

L’authentification Windows est un scénario avec état principalement utilisé dans un intranet, où un proxy ou un équilibreur de charge ne gère généralement pas le trafic entre les clients et les serveurs. Si un proxy ou un équilibreur de charge est utilisé, l’authentification Windows fonctionne uniquement si le proxy ou l’équilibreur de charge :

• Gère l’authentification.
• Transmet les informations d’authentification utilisateur à l’application (par exemple, dans un en-tête de demande), qui agit sur les informations d’authentification.

Une alternative à l’authentification Windows dans les environnements où les proxys et les équilibreurs de charge sont utilisés est Active Directory Federated Services (ADFS) avec OpenID Connect (OIDC).

IIS/IIS Express

Ajoutez des services d’authentification en appelant AddAuthentication (espace de noms Microsoft.AspNetCore.Server.IISIntegration) dans Startup.ConfigureServices :

services.AddAuthentication(IISDefaults.AuthenticationScheme);

Paramètres de lancement (débogueur)

La configuration des paramètres de lancement affecte uniquement le fichier Properties/launchSettings.json pour IIS Express et ne configure pas IIS pour l’authentification Windows. La configuration du serveur est expliquée dans la section IIS.

Le modèle d’application web disponible via Visual Studio ou l’interface CLI .NET peut être configuré pour prendre en charge l’authentification Windows, qui met à jour le fichier Properties/launchSettings.json automatiquement.

"iisSettings": {
    "windowsAuthentication": true,
    "anonymousAuthentication": false,
    "iisExpress": {
        "applicationUrl": "http://localhost:52171/",
        "sslPort": 44308
    }
}

dotnet new webapp --auth Windows

"iisSettings": {
    "windowsAuthentication": true,
    "anonymousAuthentication": false,
    "iisExpress": {
        "applicationUrl": "http://localhost:52171/",
        "sslPort": 44308
    }
}

Lorsque vous modifiez un projet existant, vérifiez que le fichier projet inclut une référence de package pour le métapackage Microsoft.AspNetCore.App ou le package NuGet Microsoft.AspNetCore.Authentication.

IIS

IIS utilise également le Module ASP.NET Core pour héberger des applications ASP.NET Core. L’authentification Windows est configurée pour IIS via le fichier web.config. Les sections suivantes décrivent diverses opérations :

• Fournissez un fichier web.config local qui active l’authentification Windows sur le serveur lorsque l’application est déployée.
• Utilisez le Gestionnaire des services IIS pour configurer le fichier web.config d’une application ASP.NET Core qui a déjà été déployée sur le serveur.

Si ce n’est déjà fait, activez IIS pour héberger des applications ASP.NET Core. Pour plus d’informations, consultez Héberger ASP.NET Core sur Windows avec IIS.

Activez le service de rôle IIS pour l’authentification Windows. Pour plus d’informations, consultez Activer l’authentification Windows dans les services de rôle IIS (voir Étape 2).

L’intergiciel d’intégration IIS est configuré pour authentifier automatiquement les requêtes par défaut. Pour plus d’informations, consultez Héberger ASP.NET Core sur Windows avec IIS : options IIS (AutomaticAuthentication).

Le module ASP.NET Core est configuré pour transférer le jeton d’authentification Windows à l’application par défaut. Pour plus d’informations, consultez Informations de référence sur la configuration du module ASP.NET Core : attributs de l’élément aspNetCore.

Utilisez l’une des approches suivantes :

• Avant de publier et de déployer le projet, ajoutez le fichier web.config suivant à la racine du projet :

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <location path="." inheritInChildApplications="false">
      <system.webServer>
        <security>
          <authentication>
            <anonymousAuthentication enabled="false" />
            <windowsAuthentication enabled="true" />
          </authentication>
        </security>
      </system.webServer>
    </location>
  </configuration>
  

  Lorsque le projet est publié par le kit SDK .NET Core (sans la propriété <IsTransformWebConfigDisabled> définie sur true dans le fichier projet), le fichier web.config publié inclut la section <location><system.webServer><security><authentication>. Pour plus d’informations sur la propriété <IsTransformWebConfigDisabled>, consultez Héberger ASP.NET Core sur Windows avec IIS.

• Après avoir publié et déployé le projet, effectuez une configuration côté serveur avec le Gestionnaire des services IIS :

  1. Dans le Gestionnaire des services IIS, sélectionnez le site IIS sous le nœud Sites de la barre latérale Connexions.
  2. Double-cliquez sur Authentification dans la zone IIS.
  3. Sélectionnez Authentification anonyme. Sélectionnez Désactiver dans la barre latérale Actions.
  4. Sélectionnez Authentification Windows. Sélectionnez Activer dans la barre latérale Actions.

  Lorsque ces actions sont effectuées, le Gestionnaire des services IIS modifie le fichier web.config de l’application. Un nœud <system.webServer><security><authentication> est ajouté avec les paramètres mis à jour pour anonymousAuthentication et windowsAuthentication :

  <system.webServer>
    <security>
      <authentication>
        <anonymousAuthentication enabled="false" />
        <windowsAuthentication enabled="true" />
      </authentication>
    </security>
  </system.webServer>
  

  La section <system.webServer> ajoutée au fichier web.config par le Gestionnaire des services IIS est en dehors de la section <location> de l’application ajoutée par le kit SDK .NET Core lors de la publication de l’application. Étant donné que la section est ajoutée en dehors du nœud <location>, les paramètres sont hérités par les sous-applications de l’application actuelle. Pour empêcher l’héritage, déplacez la section <security> ajoutée à l’intérieur de la section <location><system.webServer> fournie par le kit SDK .NET Core.

  Lorsque le Gestionnaire des services IIS est utilisé pour ajouter la configuration IIS, il affecte uniquement le fichier web.config de l’application sur le serveur. Un déploiement ultérieur de l’application peut remplacer les paramètres sur le serveur si la copie de web.config du serveur est remplacée par le fichier web.config du projet. Utilisez l’une des approches suivantes pour gérer les paramètres :

  • Utilisez le Gestionnaire des services IIS pour réinitialiser les paramètres du fichier web.config après le remplacement du fichier lors du déploiement.
  • Ajoutez un fichier web.config à l’application localement avec les paramètres.

Kestrel

Le package NuGet Microsoft.AspNetCore.Authentication.Negotiate peut être utilisé avec Kestrel pour prendre en charge l’authentification Windows à l’aide de Negotiate et Kerberos sur Windows, Linux et macOS.

Ajoutez des services d’authentification en appelant AddAuthentication et AddNegotiate dans Startup.ConfigureServices :

// using Microsoft.AspNetCore.Authentication.Negotiate;
// using Microsoft.Extensions.DependencyInjection;

services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
   .AddNegotiate();

Ajoutez un intergiciel d’authentification en appelant UseAuthentication dans Startup.Configure :

app.UseAuthentication();

Pour plus d’informations sur les intergiciels, consultez Intergiciels ASP.NET Core.

Authentification Kerberos et contrôle d’accès en fonction du rôle (RBAC)

L’authentification Kerberos sur Linux ou macOS ne fournit aucune information de rôle pour un utilisateur authentifié. Pour ajouter des informations de rôle et de groupe à un utilisateur Kerberos, le gestionnaire d’authentification doit être configuré pour récupérer les rôles à partir d’un domaine LDAP. La configuration la plus simple spécifie uniquement un domaine LDAP sur lequel interroger et utilise le contexte de l’utilisateur authentifié pour interroger le domaine LDAP :

services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
    .AddNegotiate(options =>
    {
        if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
        {
            options.EnableLdap("contoso.com");
        }
    });

Certaines configurations peuvent nécessiter des informations d’identification spécifiques pour interroger le domaine LDAP. Les informations d’identification peuvent être spécifiées dans les options mises en évidence suivantes :

public void ConfigureServices(IServiceCollection services)
{
    services.AddDbContext<ApplicationDbContext>(options =>
        options.UseSqlServer(
            Configuration.GetConnectionString("DefaultConnection")));
    services.AddDatabaseDeveloperPageExceptionFilter();
    services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)
        .AddEntityFrameworkStores<ApplicationDbContext>();

    services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
        .AddNegotiate(options =>
        {
            if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
            {
                options.EnableLdap(settings =>
                {
                    settings.Domain = "contoso.com";
                    settings.MachineAccountName = "machineName";
                    settings.MachineAccountPassword = Configuration["Password"]
                });
            }
        });

    services.AddRazorPages();
}

Par défaut, le gestionnaire d’authentification Negotiate résout les domaines imbriqués. Dans un environnement LDAP volumineux ou complexe, la résolution des domaines imbriqués peut entraîner une recherche lente ou une grande quantité de mémoire utilisée pour chaque utilisateur. La résolution de domaines imbriqués peut être désactivée à l’aide de l’option IgnoreNestedGroups.

Les requêtes anonymes sont autorisées. Utilisez l’autorisation ASP.NET Core pour valider les demandes anonymes d’authentification.

AuthenticationScheme nécessite le package NuGet Microsoft.AspNetCore.Authentication.Negotiate.

Configuration de l’environnement Windows

Le composant Microsoft.AspNetCore.Authentication.Negotiate effectue l’authentification en mode utilisateur. Les noms de principal du service (SPN) doivent être ajoutés au compte d’utilisateur exécutant le service, et non au compte d’ordinateur. Exécutez setspn -S HTTP/myservername.mydomain.com myuser dans un interpréteur de commandes d’administration.

Configuration de l’environnement Linux et macOS

Des instructions pour joindre une machine Linux ou macOS à un domaine Windows sont disponibles dans l’article Connecter Azure Data Studio à votre instance SQL Server à l’aide de l’authentification Windows - Kerberos. Les instructions créent un compte d’ordinateur pour la machine Linux sur le domaine. Les SPN doivent être ajoutés à ce compte d’ordinateur.

Une fois que la machine Linux ou macOS est jointe au domaine, des étapes supplémentaires sont nécessaires pour fournir un fichier keytab avec les SPN :

• Sur le contrôleur de domaine, ajoutez de nouveaux SPN de service web au compte d’ordinateur :
  • setspn -S HTTP/mywebservice.mydomain.com mymachine
  • setspn -S HTTP/mywebservice@MYDOMAIN.COM mymachine
• Utilisez ktpass pour générer un fichier keytab :
  • ktpass -princ HTTP/mywebservice.mydomain.com@MYDOMAIN.COM -pass myKeyTabFilePassword -mapuser MYDOMAIN\mymachine$ -pType KRB5_NT_PRINCIPAL -out c:\temp\mymachine.HTTP.keytab -crypto AES256-SHA1
  • Certains champs doivent être spécifiés en majuscules comme indiqué.
• Copiez le fichier keytab sur l’ordinateur Linux ou macOS.
• Sélectionnez le fichier keytab via une variable d’environnement : export KRB5_KTNAME=/tmp/mymachine.HTTP.keytab
• Appelez klist pour afficher les SPN actuellement disponibles.

HTTP.sys

HTTP.sys prend en charge l’authentification Windows en mode noyau à l’aide de l’authentification Negotiate, NTLM ou de base.

Ajoutez des services d’authentification en appelant AddAuthentication (espace de noms Microsoft.AspNetCore.Server.HttpSys) dans Startup.ConfigureServices :

services.AddAuthentication(HttpSysDefaults.AuthenticationScheme);

Configurez l’hôte web de l’application pour utiliser HTTP.sys avec l’authentification Windows (Program.cs). UseHttpSys est dans l’espace de noms Microsoft.AspNetCore.Server.HttpSys.

public class Program
{
    public static void Main(string[] args)
    {
        CreateHostBuilder(args).Build().Run();
    }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>()
                    .UseHttpSys(options =>
                    {
                        options.Authentication.Schemes = 
                            AuthenticationSchemes.NTLM | 
                            AuthenticationSchemes.Negotiate;
                        options.Authentication.AllowAnonymous = false;
                    });
            });
}

Autoriser les utilisateurs

L’état de configuration de l’accès anonyme détermine la façon dont les attributs [Authorize] et [AllowAnonymous] sont utilisés dans l’application. Les deux sections suivantes expliquent comment gérer les états de configuration non autorisé et autorisé de l’accès anonyme.

Interdire l’accès anonyme

Lorsque l’authentification Windows est activée et que l’accès anonyme est désactivé, les attributs [Authorize] et [AllowAnonymous] n’ont aucun effet. Si un site IIS est configuré pour interdire l’accès anonyme, la demande n’atteint jamais l’application. Pour cette raison, l’attribut [AllowAnonymous] n’est pas applicable.

Autoriser l'accès anonyme

Lorsque l’authentification Windows et l’accès anonyme sont activés, utilisez les attributs [Authorize] et [AllowAnonymous]. L’attribut [Authorize] vous permet de sécuriser les points de terminaison de l’application qui nécessitent une authentification. L’attribut [AllowAnonymous] remplace l’attribut [Authorize] dans les applications qui autorisent l’accès anonyme. Pour plus d’informations sur l’utilisation des attributs, consultez Autorisation simple dans ASP.NET Core.

Emprunt d'identité

ASP.NET Core n’implémente pas l’emprunt d’identité. Les applications s’exécutent avec l’identity de l’application pour toutes les demandes, à l’aide d’un pool d’applications ou d’une identity de processus. Si l’application doit effectuer une action pour le compte d’un utilisateur, utilisez WindowsIdentity.RunImpersonated ou RunImpersonatedAsync dans un middleware terminal en ligne dans Startup.Configure. Exécutez une seule action dans ce contexte, puis fermez le contexte.

app.Run(async (context) =>
{
    try
    {
        var user = (WindowsIdentity)context.User.Identity;

        await context.Response
            .WriteAsync($"User: {user.Name}\tState: {user.ImpersonationLevel}\n");

        WindowsIdentity.RunImpersonated(user.AccessToken, () =>
        {
            var impersonatedUser = WindowsIdentity.GetCurrent();
            var message =
                $"User: {impersonatedUser.Name}\t" +
                $"State: {impersonatedUser.ImpersonationLevel}";

            var bytes = Encoding.UTF8.GetBytes(message);
            context.Response.Body.Write(bytes, 0, bytes.Length);
        });
    }
    catch (Exception e)
    {
        await context.Response.WriteAsync(e.ToString());
    }
});

Bien que le package Microsoft.AspNetCore.Authentication.Negotiate active l’authentification sur Windows, Linux et macOS, l’emprunt d’identité n’est pris en charge que sur Windows.

Transformations de revendication

Dans le cas d’un hébergement avec IIS, AuthenticateAsync n’est pas appelé en interne pour initialiser un utilisateur. Par conséquent, une implémentation de IClaimsTransformation utilisée pour transformer les revendications après chaque authentification n’est pas activée par défaut. Pour plus d’informations et un exemple de code qui active les transformations de revendications, consultez Différences entre l’hébergement in-process et out-of-process.

Ressources supplémentaires

• dotnet publish
• Héberger ASP.NET Core sur Windows avec IIS
• Module ASP.NET Core (ANCM) pour IIS
• Profils de publication Visual Studio (.pubxml) pour le déploiement d’applications ASP.NET Core