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.

Quand utiliser l’authentification Windows

L’authentification Windows convient aux applications web qui fonctionnent dans le réseau interne privé d’une organisation, accessibles uniquement aux employés (et aux autres utilisateurs autorisés) au sein du même réseau. La gestion des utilisateurs est effectuée dans Active Directory (AD) et les utilisateurs utilisent leur compte de domaine Windows existant pour s’authentifier.

L’authentification Windows offre plusieurs avantages pour les applications intranet :

• Expérience utilisateur transparente : les utilisateurs sont automatiquement authentifiés en fonction de leur session Windows active ou sont invités à entrer leurs informations d’identification Windows via une boîte de dialogue de navigateur standard.
• Intégration à Active Directory : tire parti des stratégies de sécurité et d’infrastructure Windows existantes, notamment les groupes d’utilisateurs, les verrouillages de compte et l’authentification multifacteur (MFA).
• Gestion des informations d’identification sécurisées : l’authentification est gérée par le biais de protocoles sécurisés tels que Kerberos, sans avoir besoin de gérer des informations d’identification utilisateur distinctes.
• Autorisation basée sur les rôles : les applications peuvent accéder aux informations d’utilisateur et de groupe à partir d’Active Directory, ce qui permet le contrôle d’accès en fonction du rôle (RBAC) au sein de l’application.
• Réduction de la surcharge administrative : il n’est pas nécessaire de gérer une base de données utilisateur ou un système de gestion des informations d’identification distinct.

Cela rend l’authentification Windows idéale pour les organisations qui souhaitent utiliser leur infrastructure Windows existante, comme les portails intranet.

Pour les applications publiques, l’authentification Windows n’est pas recommandée en raison de problèmes de sécurité et d’utilisation. Ces raisons sont les suivantes :

• L’authentification Windows est mieux conservée interne pour protéger Active Directory, l’exposant en dehors d’un réseau interne introduit des risques de sécurité.
• Les utilisateurs externes n’ont pas de comptes de domaine Windows.
• Il est complexe de configurer l’infrastructure réseau nécessaire en toute sécurité, et les pare-feu ou proxys peuvent interférer avec le processus d’authentification.
• Il n’est pas multiplateforme et ne fournit pas d’options de personnalisation pour les conceptions et les expériences utilisateur.

Alternatives pour différents scénarios

Selon vos besoins en matière d’application, tenez compte des alternatives suivantes :

Pour les applications publiques :

• OpenID Connect avec des fournisseurs d’identité externes
• ASP.NET Core Identity avec des comptes d’utilisateur locaux (Présentation sur Identity ASP.NET Core)
• Azure Active Directory (AAD) pour les environnements Microsoft 365

Pour les environnements mixtes avec des utilisateurs intranet et externes :

• Services de fédération Active Directory (ADFS) avec OpenID Connect
• Azure Active Directory avec une configuration hybride

Pour les environnements d’entreprise utilisant l’authentification moderne :

• Azure Active Directory avec l’authentification unique
• Solutions SAML avec des fournisseurs d’identité tiers

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 et lesMicrosoft.AspNetCore.Authentication.Negotiate services d’authentification en appelant AddAuthentication :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 de développement logiciel (SDK) .NET (sans la <IsTransformWebConfigDisabled> propriété définie true dans le fichier projet), le fichier web.config publié inclut la <location><system.webServer><security><authentication> section. Pour plus d’informations sur la <IsTransformWebConfigDisabled> propriété, consultez web.config fichier.

• 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 <system.webServer> section ajoutée au fichier web.config par le Gestionnaire d’IIS se trouve en dehors de la section de <location> l’application ajoutée par le Kit de développement logiciel (SDK) .NET 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 ajoutée <security> à l’intérieur de la <location><system.webServer> section fournie par le Kit de développement logiciel (SDK) .NET.

  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 Microsoft.AspNetCore.Authentication.Negotiate package NuGet peut être utilisé pour Kestrel activer l’authentification Windows à l’aide de Negotiate et Kerberos sur Windows, Linux et macOS.

L’authentification et une stratégie d’autorisation de secours sont activées par le code mis en surbrillance suivant 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.

Lignes mises en surbrillance :

• 5 à 6 : AddAuthentication et AddNegotiate enregistrer et configurer le gestionnaire d’authentification Negotiate.
• 8 à 11 : AddAuthorization avec une politique de repli, les utilisateurs doivent être authentifiés par défaut.
• 26 : UseAuthentication exécute des gestionnaires d’authentification pour chaque requête et remplit HttpContext.User.
• 27 : UseAuthorization évalue les stratégies d’autorisation, y compris la stratégie de secours.

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

L’API effectue Microsoft.AspNetCore.Authentication.Negotiate 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.

Impersonation

ASP.NET Core n’implémente pas l’emprunt d’identité. Les applications fonctionnent avec l’identité de l’application pour toutes les requêtes, en utilisant le pool d’applications ou l’identité du processus. Si l’application doit effectuer une action pour le compte d’un utilisateur, utilisez WindowsIdentity.RunImpersonated ou RunImpersonatedAsync dans un intergiciel inline de terminal 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 active l’authentification Microsoft.AspNetCore.Authentication.Negotiate sur Windows, Linux et macOS, l’emprunt d’identité n’est pris en charge que sur Windows.

Transformations d'assertions

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.

Quand utiliser l’authentification Windows

L’authentification Windows convient aux applications web qui fonctionnent dans le réseau interne privé d’une organisation, accessibles uniquement aux employés (et aux autres utilisateurs autorisés) au sein du même réseau. La gestion des utilisateurs est effectuée dans Active Directory (AD) et les utilisateurs utilisent leur compte de domaine Windows existant pour s’authentifier.

L’authentification Windows offre plusieurs avantages pour les applications intranet :

• Expérience utilisateur transparente : les utilisateurs sont automatiquement authentifiés en fonction de leur session Windows active ou sont invités à entrer leurs informations d’identification Windows via une boîte de dialogue de navigateur standard.
• Intégration à Active Directory : tire parti des stratégies de sécurité et d’infrastructure Windows existantes, notamment les groupes d’utilisateurs, les verrouillages de compte et l’authentification multifacteur (MFA).
• Gestion des informations d’identification sécurisées : l’authentification est gérée par le biais de protocoles sécurisés tels que Kerberos, sans avoir besoin de gérer des informations d’identification utilisateur distinctes.
• Autorisation basée sur les rôles : les applications peuvent accéder aux informations d’utilisateur et de groupe à partir d’Active Directory, ce qui permet le contrôle d’accès en fonction du rôle (RBAC) au sein de l’application.
• Réduction de la surcharge administrative : il n’est pas nécessaire de gérer une base de données utilisateur ou un système de gestion des informations d’identification distinct.

Cela rend l’authentification Windows idéale pour les organisations qui souhaitent utiliser leur infrastructure Windows existante, comme les portails intranet.

Pour les applications publiques, l’authentification Windows n’est pas recommandée en raison de problèmes de sécurité et d’utilisation. Ces raisons sont les suivantes :

• L’authentification Windows est mieux conservée interne pour protéger Active Directory, l’exposant en dehors d’un réseau interne introduit des risques de sécurité.
• Les utilisateurs externes n’ont pas de comptes de domaine Windows.
• Il est complexe de configurer l’infrastructure réseau nécessaire en toute sécurité, et les pare-feu ou proxys peuvent interférer avec le processus d’authentification.
• Il n’est pas multiplateforme et ne fournit pas d’options de personnalisation pour les conceptions et les expériences utilisateur.

Alternatives pour différents scénarios

Selon vos besoins en matière d’application, tenez compte des alternatives suivantes :

Pour les applications publiques :

• OpenID Connect avec des fournisseurs d’identité externes
• ASP.NET Core Identity avec des comptes d’utilisateur locaux (Présentation sur Identity ASP.NET Core)
• Azure Active Directory (AAD) pour les environnements Microsoft 365

Pour les environnements mixtes avec des utilisateurs intranet et externes :

• Services de fédération Active Directory (ADFS) avec OpenID Connect
• Azure Active Directory avec une configuration hybride

Pour les environnements d’entreprise utilisant l’authentification moderne :

• Azure Active Directory avec l’authentification unique
• Solutions SAML avec des fournisseurs d’identité tiers

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
    }
}

Lors de la modification d’un projet existant, vérifiez que le fichier projet inclut une référence de package pour le Microsoft.AspNetCore.App métapackageou le Microsoft.AspNetCore.Authentication package NuGet.

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 de développement logiciel (SDK) .NET (sans la <IsTransformWebConfigDisabled> propriété définie true dans le fichier projet), le fichier web.config publié inclut la <location><system.webServer><security><authentication> section. 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 <system.webServer> section ajoutée au fichier web.config par le Gestionnaire d’IIS se trouve en dehors de la section de <location> l’application ajoutée par le Kit de développement logiciel (SDK) .NET 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 ajoutée <security> à l’intérieur de la <location><system.webServer> section fournie par le Kit de développement logiciel (SDK) .NET.

  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 Microsoft.AspNetCore.Authentication.Negotiate package NuGet peut être utilisé pour Kestrel 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 Microsoft.AspNetCore.Authentication.Negotiate package NuGet.

Configuration de l’environnement Windows

L’API effectue Microsoft.AspNetCore.Authentication.Negotiate 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.

Impersonation

ASP.NET Core n’implémente pas l’emprunt d’identité. Les applications fonctionnent avec l’identité de l’application pour toutes les requêtes, en utilisant le pool d’applications ou l’identité du 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 active l’authentification Microsoft.AspNetCore.Authentication.Negotiate sur Windows, Linux et macOS, l’emprunt d’identité n’est pris en charge que sur Windows.

Transformations d'assertions

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