Configurer l’authentification Windows dans ASP.NET Core
Par Rick Anderson et Kirk Larkin
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.
Notes
L’authentification Windows n’est pas prise en charge avec HTTP/2. Les défis d’authentification peuvent être envoyés sur les réponses HTTP/2, mais le client doit passer à HTTP/1.1 avant de s’authentifier.
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.
Nouveau projet
Créez une application Razor Pages ou MVC. Dans la boîte de dialogue Informations supplémentaires, définissez le type d’authentification sur Windows.
Exécutez l'application. Le nom d’utilisateur apparaît dans l’interface utilisateur de l’application rendue.
Projet existant
Les propriétés du projet activent l’authentification Windows et désactivent l’authentification anonyme. Ouvrez la boîte de dialogue Profils de lancement :
- Dans l’Explorateur de solutions, cliquez avec le bouton droit sur le projet et sélectionnez Propriétés.
- Sélectionnez l’onglet Débogage > Général et sélectionnez Ouvrir l’IU Profils de lancement de débogage.
- Décochez la case Activer l’authentification anonyme.
- Cochez la case Activer l’authentification Windows.
Vous pouvez également configurer les propriétés dans le nœud iisSettings
du fichier launchSettings.json
:
"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 surtrue
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 :
- Dans le Gestionnaire des services IIS, sélectionnez le site IIS sous le nœud Sites de la barre latérale Connexions.
- Double-cliquez sur Authentification dans la zone IIS.
- Sélectionnez Authentification anonyme. Sélectionnez Désactiver dans la barre latérale Actions.
- 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 pouranonymousAuthentication
etwindowsAuthentication
:<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.
Avertissement
Les informations d’identification peuvent être conservées entre les requêtes sur une connexion. L’authentification Negotiate ne doit pas être utilisée avec des proxys, sauf si le proxy conserve une affinité de connexion 1:1 (connexion persistante) avec Kestrel.
Notes
Le gestionnaire Negotiate détecte si le serveur sous-jacent prend en charge l’authentification Windows en mode natif et si elle est activée. Si le serveur prend en charge l’authentification Windows, mais qu’elle est désactivée, une erreur est générée vous demandant d’activer l’implémentation du serveur. Lorsque l’authentification Windows est activée sur le serveur, le gestionnaire Negotiate lui transfère de manière transparente les demandes d’authentification.
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 :
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.
Notes
Lorsque vous suivez les instructions de l’article Connecter Azure Data Studio à votre instance SQL Server à l’aide de l’authentification Windows - Kerberos, remplacez python-software-properties
par python3-software-properties
si nécessaire.
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.
Notes
Un fichier keytab contient des informations d’identification d’accès au domaine et doit être protégé en conséquence.
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;
});
}
Notes
HTTP.sys délègue l’authentification en mode noyau avec le protocole d’authentification Kerberos. L’authentification en mode utilisateur n’est pas prise en charge avec Kerberos et HTTP.sys. Le compte d’ordinateur doit être utilisé pour déchiffrer le ticket/jeton Kerberos obtenu à partir d’Active Directory et transféré par le client au serveur afin d’authentifier l’utilisateur. Inscrivez le nom de principal du service (SPN) pour l’hôte, et non l’utilisateur de l’application.
Notes
HTTP.sys n’est pas pris en charge sur Nano Server version 1709 ou ultérieure. Pour utiliser l’authentification Windows et HTTP.sys avec Nano Server, utilisez un conteneur Server Core (microsoft/windowsservercore) (voir https://hub.docker.com/_/microsoft-windows-servercore
). Pour plus d’informations sur Server Core, consultez Qu’est-ce que l’option d’installation Server Core dans Windows Server ?.
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]
] (xref:Microsoft.AspNetCore.Authorization.AuthorizeAttribute) 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]
] (xref:Microsoft.AspNetCore.Authorization.AuthorizeAttribute) et [AllowAnonymous]
. L’attribut [[Authorize]
] (xref:Microsoft.AspNetCore.Authorization.AuthorizeAttribute) 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.
Notes
Par défaut, les utilisateurs qui n’ont pas l’autorisation d’accéder à une page reçoivent une réponse HTTP 403 vide. L’intergiciel StatusCodePages peut être configuré pour offrir aux utilisateurs une meilleure expérience « Accès refusé ».
Emprunt d'identité
ASP.NET Core n’implémente pas l’emprunt d’identité. Les applications s’exécutent avec l’identité de l’application pour toutes les demandes, à l’aide d’un pool d’applications ou d’une identité de processus. Si l’application doit effectuer une action pour le compte d’un utilisateur, utilisez WindowsIdentity.RunImpersonated ou RunImpersonatedAsync dans un intergiciel en ligne 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 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
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.
Notes
L’authentification Windows n’est pas prise en charge avec HTTP/2. Les défis d’authentification peuvent être envoyés sur les réponses HTTP/2, mais le client doit passer à HTTP/1.1 avant de s’authentifier.
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.
Nouveau projet
- Créez un projet.
- Sélectionnez Application web ASP.NET Core. Sélectionnez Suivant.
- Indiquez un nom dans le champ Nom du projet. Vérifiez que l’entrée Emplacement est correcte ou indiquez un emplacement pour le projet. Sélectionnez Create (Créer).
- Sélectionnez Modifier sous Authentification.
- Dans la fenêtre Modifier l’authentification, sélectionnez Authentification Windows. Sélectionnez OK.
- Sélectionnez Application web.
- Sélectionnez Create (Créer).
Exécutez l'application. Le nom d’utilisateur apparaît dans l’interface utilisateur de l’application rendue.
Projet existant
Les propriétés du projet activent l’authentification Windows et désactivent l’authentification anonyme :
- Cliquez avec le bouton droit sur le projet dans l’Explorateur de solutions, puis sélectionnez Propriétés.
- Sélectionnez l’onglet Débogage.
- Décochez la case Activer l’authentification anonyme.
- Cochez la case Activer l’authentification Windows.
- Enregistrez et fermez la page Propriétés.
Vous pouvez également configurer les propriétés dans le nœud iisSettings
du fichier launchSettings.json
:
"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 surtrue
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 :
- Dans le Gestionnaire des services IIS, sélectionnez le site IIS sous le nœud Sites de la barre latérale Connexions.
- Double-cliquez sur Authentification dans la zone IIS.
- Sélectionnez Authentification anonyme. Sélectionnez Désactiver dans la barre latérale Actions.
- 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 pouranonymousAuthentication
etwindowsAuthentication
:<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.
Avertissement
Les informations d’identification peuvent être conservées entre les requêtes sur une connexion. L’authentification Negotiate ne doit pas être utilisée avec des proxys, sauf si le proxy conserve une affinité de connexion 1:1 (connexion persistante) avec Kestrel.
Notes
Le gestionnaire Negotiate détecte si le serveur sous-jacent prend en charge l’authentification Windows en mode natif et si elle est activée. Si le serveur prend en charge l’authentification Windows, mais qu’elle est désactivée, une erreur est générée vous demandant d’activer l’implémentation du serveur. Lorsque l’authentification Windows est activée sur le serveur, le gestionnaire Negotiate lui transfère de manière transparente les demandes d’authentification.
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.
Notes
Lorsque vous suivez les instructions de l’article Connecter Azure Data Studio à votre instance SQL Server à l’aide de l’authentification Windows - Kerberos, remplacez python-software-properties
par python3-software-properties
si nécessaire.
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.
Notes
Un fichier keytab contient des informations d’identification d’accès au domaine et doit être protégé en conséquence.
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;
});
});
}
Notes
HTTP.sys délègue l’authentification en mode noyau avec le protocole d’authentification Kerberos. L’authentification en mode utilisateur n’est pas prise en charge avec Kerberos et HTTP.sys. Le compte d’ordinateur doit être utilisé pour déchiffrer le ticket/jeton Kerberos obtenu à partir d’Active Directory et transféré par le client au serveur afin d’authentifier l’utilisateur. Inscrivez le nom de principal du service (SPN) pour l’hôte, et non l’utilisateur de l’application.
Notes
HTTP.sys n’est pas pris en charge sur Nano Server version 1709 ou ultérieure. Pour utiliser l’authentification Windows et HTTP.sys avec Nano Server, utilisez un conteneur Server Core (microsoft/windowsservercore) (voir https://hub.docker.com/_/microsoft-windows-servercore
). Pour plus d’informations sur Server Core, consultez Qu’est-ce que l’option d’installation Server Core dans Windows Server ?.
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.
Notes
Par défaut, les utilisateurs qui n’ont pas l’autorisation d’accéder à une page reçoivent une réponse HTTP 403 vide. L’intergiciel StatusCodePages peut être configuré pour offrir aux utilisateurs une meilleure expérience « Accès refusé ».
Emprunt d'identité
ASP.NET Core n’implémente pas l’emprunt d’identité. Les applications s’exécutent avec l’identité de l’application pour toutes les demandes, à l’aide d’un pool d’applications ou d’une identité de processus. Si l’application doit effectuer une action pour le compte d’un utilisateur, utilisez WindowsIdentity.RunImpersonated ou RunImpersonatedAsync dans un intergiciel en ligne de terminal 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.