Configurare l'autenticazione di Windows in ASP.NET Core

L'autenticazione di Windows (nota anche come autenticazione Negotiate, Kerberos o NTLM) può essere configurata per ASP.NET app Core ospitate con IIS, Kestrelo HTTP.sys.

L'autenticazione di Windows si basa sul sistema operativo per autenticare gli utenti delle app ASP.NET Core. L'autenticazione di Windows viene usata per i server eseguiti in una rete aziendale usando identità di dominio Active Directory o account Di Windows per identificare gli utenti. L'autenticazione di Windows è più adatta agli ambienti Intranet in cui gli utenti, le app client e i server Web appartengono allo stesso dominio di Windows.

Scenari di proxy e bilanciamento del carico

L'autenticazione di Windows è uno scenario con stato usato principalmente in una intranet, in cui un proxy o un servizio di bilanciamento del carico in genere non gestisce il traffico tra client e server. Se si usa un proxy o un servizio di bilanciamento del carico, l'autenticazione di Windows funziona solo se il proxy o il servizio di bilanciamento del carico:

• Gestisce l'autenticazione.
• Passa le informazioni di autenticazione utente all'app (ad esempio, in un'intestazione di richiesta), che agisce sulle informazioni di autenticazione.

Un'alternativa all'autenticazione di Windows negli ambienti in cui vengono usati proxy e servizi di bilanciamento del carico è Active Directory Federated Services (ADFS) con OpenID Connect (OIDC).

IIS/IIS Express

Aggiungere il pacchetto NuGet Microsoft.AspNetCore.Authentication.Negotiate e i servizi di autenticazione chiamando AddAuthentication in 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();

Il codice precedente è stato generato dal modello ASP.NET Core Razor Pages con l'autenticazione di Windows specificata.

Impostazioni di avvio (debugger)

La configurazione per le impostazioni di avvio influisce solo sul Properties/launchSettings.json file per IIS Express e non configura IIS per l'autenticazione di Windows. La configurazione del server è illustrata nella sezione IIS .

I modelli di applicazione Web disponibili tramite Visual Studio o l'interfaccia della riga di comando di .NET possono essere configurati per supportare l'autenticazione di Windows, che aggiorna automaticamente il Properties/launchSettings.json file.

"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 usa il modulo ASP.NET Core per ospitare ASP.NET app Core. L'autenticazione di Windows è configurata per IIS tramite il file web.config . Le sezioni seguenti mostrano come:

• Specificare un file web.config locale che attiva l'autenticazione di Windows nel server quando l'app viene distribuita.
• Usare Gestione IIS per configurare il file web.config di un'app ASP.NET Core già distribuita nel server.

Se non è già stato fatto, abilitare IIS per ospitare ASP.NET app Core. Per altre informazioni, vedere Host ASP.NET Core on Windows with IIS (Host ASP.NET Core in Windows con IIS).

Abilitare il servizio ruolo IIS per l'autenticazione di Windows. Per altre informazioni, vedere Abilitare l'autenticazione di Windows in Servizi ruolo IIS (vedere Passaggio 2).

Il middleware di integrazione IIS è configurato per autenticare automaticamente le richieste per impostazione predefinita. Per altre informazioni, vedere Host ASP.NET Core in Windows con IIS: opzioni IIS (AutomaticAuthentication).For more information, see Host ASP.NET Core on Windows with IIS: IIS options (AutomaticAuthentication).

Il modulo ASP.NET Core è configurato per inoltrare il token di autenticazione di Windows all'app per impostazione predefinita. Per altre informazioni, vedere ASP.NET Informazioni di riferimento sulla configurazione del modulo core: Attributi dell'elemento aspNetCore.

Usare uno degli approcci seguenti:

• Prima di pubblicare e distribuire il progetto, aggiungere il file web.config seguente alla radice del progetto:

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

  Quando il progetto viene pubblicato da .NET Core SDK (senza la <IsTransformWebConfigDisabled> proprietà impostata true su nel file di progetto), il file web.config pubblicato include la <location><system.webServer><security><authentication> sezione . Per altre informazioni sulla <IsTransformWebConfigDisabled> proprietà, vedere Host ASP.NET Core in Windows con IIS.

• Dopo la pubblicazione e la distribuzione del progetto, eseguire la configurazione lato server con Gestione IIS:

  1. In Gestione IIS selezionare il sito IIS nel nodo Siti della barra laterale Connessioni .
  2. Fare doppio clic su Autenticazione nell'area IIS .
  3. Selezionare Autenticazione anonima. Selezionare Disabilita nella barra laterale Azioni .
  4. Selezionare Autenticazione di Windows. Selezionare Abilita nella barra laterale Azioni .

  Quando vengono eseguite queste azioni, Gestione IIS modifica il file web.config dell'app. Viene aggiunto un <system.webServer><security><authentication> nodo con le impostazioni aggiornate per anonymousAuthentication e windowsAuthentication:

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

  La <system.webServer> sezione aggiunta al file web.config da Gestione IIS si trova all'esterno della sezione dell'app <location> aggiunta da .NET Core SDK quando l'app viene pubblicata. Poiché la sezione viene aggiunta all'esterno del <location> nodo, le impostazioni vengono ereditate da tutte le app secondarie all'app corrente. Per impedire l'ereditarietà, spostare la sezione aggiunta <security> all'interno della <location><system.webServer> sezione fornita da .NET Core SDK.

  Quando Si usa Gestione IIS per aggiungere la configurazione IIS, influisce solo sul file web.config dell'app nel server. Una successiva distribuzione dell'app può sovrascrivere le impostazioni nel server se la copia di web.config del server viene sostituita dal file web.config del progetto. Usare uno degli approcci seguenti per gestire le impostazioni:

  • Usare Gestione IIS per reimpostare le impostazioni nel file web.config dopo la sovrascrittura del file durante la distribuzione.
  • Aggiungere un file web.config all'app in locale con le impostazioni.

Kestrel

Il pacchetto NuGet Microsoft.AspNetCore.Authentication.Negotiate può essere usato con Kestrel per supportare l'autenticazione di Windows tramite Negotiate e Kerberos in Windows, Linux e macOS.

L'autenticazione è abilitata dal codice evidenziato seguente in 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();

Il codice precedente è stato generato dal modello ASP.NET Core Razor Pages con l'autenticazione di Windows specificata. Nel codice precedente vengono usate le API seguenti:

• AddAuthentication
• AddNegotiate
• UseAuthentication

Autenticazione Kerberos e controllo degli accessi in base al ruolo

L'autenticazione Kerberos in Linux o macOS non fornisce informazioni sul ruolo per un utente autenticato. Per aggiungere informazioni sui ruoli e sui gruppi a un utente Kerberos, è necessario configurare il gestore di autenticazione per recuperare i ruoli da un dominio LDAP. La configurazione più semplice specifica solo un dominio LDAP su cui eseguire una query e usa il contesto dell'utente autenticato per eseguire query sul dominio 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");
        }
    });

Alcune configurazioni possono richiedere credenziali specifiche per eseguire query sul dominio LDAP. Le credenziali possono essere specificate nelle opzioni evidenziate seguenti:

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();

Per impostazione predefinita, il gestore di autenticazione negotiate risolve i domini annidati. In un ambiente LDAP di grandi dimensioni o complicato, la risoluzione dei domini annidati può comportare una ricerca lenta o una quantità elevata di memoria usata per ogni utente. La risoluzione del dominio annidata può essere disabilitata usando l'opzione IgnoreNestedGroups .

Le richieste anonime sono consentite. Usare ASP.NET'autorizzazione di base per verificare le richieste anonime per l'autenticazione.

Configurazione dell'ambiente Windows

Il componente Microsoft.AspNetCore.Authentication.Negotiate esegue l'autenticazione in modalità utente. I nomi dell'entità servizio (SPN) devono essere aggiunti all'account utente che esegue il servizio, non all'account del computer. Eseguire setspn -S HTTP/myservername.mydomain.com myuser in una shell dei comandi amministrativa.

Kerberos e NTLM

Il pacchetto Negotiate on Kestrel per ASP.NET Core tenta di usare Kerberos, che è uno schema di autenticazione più sicuro e peformante rispetto a 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 specifica Kerberos perché è l'impostazione predefinita.

IIS, IISExpress e Kestrel supportano sia Kerberos che NTLM.

Esaminando l'intestazione WWW-Authenticate: tramite IIS o IISExpress con uno strumento come Fiddler viene visualizzato Negotiate o NTLM.

Kestrel mostra solo WWW-Authenticate: Negotiate

L'intestazione WWW-Authenticate: Negotiate indica che il server può usare NTLM o Kerberos. Kestrel richiede il Negotiate prefisso dell'intestazione, non supporta la specifica NTLM diretta nelle intestazioni di autenticazione della richiesta o della risposta. NTLM è supportato in Kestrel, ma deve essere inviato come Negotiate.

In Kestrelper verificare se viene usato NTLM o Kerberos, La codifica Base64 dell'intestazione e mostra NTLM o HTTP. HTTP indica che è stato usato Kerberos.

Configurazione dell'ambiente Linux e macOS

Le istruzioni per aggiungere un computer Linux o macOS a un dominio Windows sono disponibili nell'articolo Connettere Azure Data Studio a SQL Server usando autenticazione di Windows - Kerberos. Le istruzioni creano un account computer per il computer Linux nel dominio. I nomi SPN devono essere aggiunti all'account del computer.

Dopo aver aggiunto il computer Linux o macOS al dominio, sono necessari passaggi aggiuntivi per fornire un file keytab con i nomi SPN:

• Nel controller di dominio aggiungere nuovi nomi SPN del servizio Web all'account del computer:
  • setspn -S HTTP/mywebservice.mydomain.com mymachine
  • setspn -S HTTP/mywebservice@MYDOMAIN.COM mymachine
• Usare ktpass per generare un file 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
  • Alcuni campi devono essere specificati in lettere maiuscole come indicato.
• Copiare il file keytab nel computer Linux o macOS.
• Selezionare il file keytab tramite una variabile di ambiente: export KRB5_KTNAME=/tmp/mymachine.HTTP.keytab
• Richiamare klist per visualizzare i nomi SPN attualmente disponibili per l'uso.

HTTP.sys

HTTP.sys supporta l'autenticazione di Windows in modalità kernel tramite l'autenticazione Negotiate, NTLM o Basic.

Il codice seguente aggiunge l'autenticazione e configura l'host Web dell'app per l'uso di HTTP.sys con l'autenticazione di 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;
        });
}

Autorizzare gli utenti

Lo stato di configurazione dell'accesso anonimo determina il modo in cui [Authorize] gli attributi e [AllowAnonymous] vengono usati nell'app. Le due sezioni seguenti illustrano come gestire gli stati di configurazione non consentiti e consentiti dell'accesso anonimo.

Non consentire l'accesso anonimo

Quando l'autenticazione di Windows è abilitata e l'accesso anonimo è disabilitato, gli [Authorize] attributi e [AllowAnonymous] non hanno alcun effetto. Se un sito IIS è configurato per impedire l'accesso anonimo, la richiesta non raggiunge mai l'app. Per questo motivo, l'attributo [AllowAnonymous] non è applicabile.

Consenti accesso anonimo

Quando l'autenticazione di Windows e l'accesso anonimo sono abilitati, usare gli [Authorize] attributi e [AllowAnonymous] . L'attributo [Authorize] consente di proteggere gli endpoint dell'app che richiedono l'autenticazione. L'attributo [AllowAnonymous] esegue l'override dell'attributo nelle app che consentono l'accesso [Authorize] anonimo. Per informazioni dettagliate sull'utilizzo degli attributi, vedere Autorizzazione semplice in ASP.NET Core.

Rappresentazione

ASP.NET Core non implementa la rappresentazione. Le app vengono eseguite con l'app identity per tutte le richieste, usando il pool di app o il processo identity. Se l'app deve eseguire un'azione per conto di un utente, usare WindowsIdentity.RunImpersonated o RunImpersonatedAsync in un middleware inline del terminale in Program.cs. Eseguire una singola azione in questo contesto e quindi chiudere il contesto.

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());
    }
});

Mentre il pacchetto Microsoft.AspNetCore.Authentication.Negotiate abilita l'autenticazione in Windows, Linux e macOS, la rappresentazione è supportata solo in Windows.

Trasformazioni delle attestazioni

Quando si ospita con IIS, AuthenticateAsync non viene chiamato internamente per inizializzare un utente. Pertanto, un'implementazione di IClaimsTransformation usate per trasformare le attestazioni dopo ogni autenticazione non viene attivata per impostazione predefinita. Per altre informazioni e un esempio di codice che attiva le trasformazioni delle attestazioni, vedere Differenze tra hosting in-process e out-of-process.

Risorse aggiuntive

• dotnet publish
• Host ASP.NET Core in Windows con IIS
• Modulo ASP.NET Core (ANCM) per IIS
• Profili di pubblicazione di Visual Studio (.pubxml) per la distribuzione di app ASP.NET Core

L'autenticazione di Windows (nota anche come autenticazione Negotiate, Kerberos o NTLM) può essere configurata per ASP.NET app Core ospitate con IIS, Kestrelo HTTP.sys.

L'autenticazione di Windows si basa sul sistema operativo per autenticare gli utenti delle app ASP.NET Core. È possibile usare l'autenticazione di Windows quando il server viene eseguito in una rete aziendale usando identità di dominio Active Directory o account di Windows per identificare gli utenti. L'autenticazione di Windows è più adatta agli ambienti Intranet in cui gli utenti, le app client e i server Web appartengono allo stesso dominio di Windows.

Scenari di proxy e bilanciamento del carico

L'autenticazione di Windows è uno scenario con stato usato principalmente in una intranet, in cui un proxy o un servizio di bilanciamento del carico in genere non gestisce il traffico tra client e server. Se si usa un proxy o un servizio di bilanciamento del carico, l'autenticazione di Windows funziona solo se il proxy o il servizio di bilanciamento del carico:

• Gestisce l'autenticazione.
• Passa le informazioni di autenticazione utente all'app (ad esempio, in un'intestazione di richiesta), che agisce sulle informazioni di autenticazione.

Un'alternativa all'autenticazione di Windows negli ambienti in cui vengono usati proxy e servizi di bilanciamento del carico è Active Directory Federated Services (ADFS) con OpenID Connect (OIDC).

IIS/IIS Express

Aggiungere i servizi di autenticazione richiamando AddAuthentication (Microsoft.AspNetCore.Server.IISIntegration spazio dei nomi) in Startup.ConfigureServices:

services.AddAuthentication(IISDefaults.AuthenticationScheme);

Impostazioni di avvio (debugger)

La configurazione per le impostazioni di avvio influisce solo sul Properties/launchSettings.json file per IIS Express e non configura IIS per l'autenticazione di Windows. La configurazione del server è illustrata nella sezione IIS .

Il modello applicazione Web disponibile tramite Visual Studio o l'interfaccia della riga di comando di .NET può essere configurato per supportare l'autenticazione di Windows, che aggiorna automaticamente il Properties/launchSettings.json file.

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

Quando si modifica un progetto esistente, verificare che il file di progetto includa un riferimento al pacchetto per il metapacchetto Microsoft.AspNetCore.App o il pacchetto NuGet Microsoft.AspNetCore.Authentication .

IIS

IIS usa il modulo ASP.NET Core per ospitare ASP.NET app Core. L'autenticazione di Windows è configurata per IIS tramite il file web.config . Le sezioni seguenti mostrano come:

• Specificare un file web.config locale che attiva l'autenticazione di Windows nel server quando l'app viene distribuita.
• Usare Gestione IIS per configurare il file web.config di un'app ASP.NET Core già distribuita nel server.

Se non è già stato fatto, abilitare IIS per ospitare ASP.NET app Core. Per altre informazioni, vedere Host ASP.NET Core on Windows with IIS (Host ASP.NET Core in Windows con IIS).

Abilitare il servizio ruolo IIS per l'autenticazione di Windows. Per altre informazioni, vedere Abilitare l'autenticazione di Windows in Servizi ruolo IIS (vedere Passaggio 2).

Il middleware di integrazione IIS è configurato per autenticare automaticamente le richieste per impostazione predefinita. Per altre informazioni, vedere Host ASP.NET Core in Windows con IIS: opzioni IIS (AutomaticAuthentication).For more information, see Host ASP.NET Core on Windows with IIS: IIS options (AutomaticAuthentication).

Il modulo ASP.NET Core è configurato per inoltrare il token di autenticazione di Windows all'app per impostazione predefinita. Per altre informazioni, vedere ASP.NET Informazioni di riferimento sulla configurazione del modulo core: Attributi dell'elemento aspNetCore.

Usare uno degli approcci seguenti:

• Prima di pubblicare e distribuire il progetto, aggiungere il file web.config seguente alla radice del progetto:

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

  Quando il progetto viene pubblicato da .NET Core SDK (senza la <IsTransformWebConfigDisabled> proprietà impostata true su nel file di progetto), il file web.config pubblicato include la <location><system.webServer><security><authentication> sezione . Per altre informazioni sulla <IsTransformWebConfigDisabled> proprietà, vedere Host ASP.NET Core in Windows con IIS.

• Dopo la pubblicazione e la distribuzione del progetto, eseguire la configurazione lato server con Gestione IIS:

  1. In Gestione IIS selezionare il sito IIS nel nodo Siti della barra laterale Connessioni .
  2. Fare doppio clic su Autenticazione nell'area IIS .
  3. Selezionare Autenticazione anonima. Selezionare Disabilita nella barra laterale Azioni .
  4. Selezionare Autenticazione di Windows. Selezionare Abilita nella barra laterale Azioni .

  Quando vengono eseguite queste azioni, Gestione IIS modifica il file web.config dell'app. Viene aggiunto un <system.webServer><security><authentication> nodo con le impostazioni aggiornate per anonymousAuthentication e windowsAuthentication:

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

  La <system.webServer> sezione aggiunta al file web.config da Gestione IIS si trova all'esterno della sezione dell'app <location> aggiunta da .NET Core SDK quando l'app viene pubblicata. Poiché la sezione viene aggiunta all'esterno del <location> nodo, le impostazioni vengono ereditate da tutte le app secondarie all'app corrente. Per impedire l'ereditarietà, spostare la sezione aggiunta <security> all'interno della <location><system.webServer> sezione fornita da .NET Core SDK.

  Quando Si usa Gestione IIS per aggiungere la configurazione IIS, influisce solo sul file web.config dell'app nel server. Una successiva distribuzione dell'app può sovrascrivere le impostazioni nel server se la copia di web.config del server viene sostituita dal file web.config del progetto. Usare uno degli approcci seguenti per gestire le impostazioni:

  • Usare Gestione IIS per reimpostare le impostazioni nel file web.config dopo la sovrascrittura del file durante la distribuzione.
  • Aggiungere un file web.config all'app in locale con le impostazioni.

Kestrel

Il pacchetto NuGet Microsoft.AspNetCore.Authentication.Negotiate può essere usato con Kestrel per supportare l'autenticazione di Windows tramite Negotiate e Kerberos in Windows, Linux e macOS.

Aggiungere i servizi di autenticazione richiamando AddAuthentication e AddNegotiate in Startup.ConfigureServices:

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

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

Aggiungere il middleware di autenticazione chiamando UseAuthentication in Startup.Configure:

app.UseAuthentication();

Per altre informazioni sul middleware, vedere ASP.NET Middleware core.

Autenticazione Kerberos e controllo degli accessi in base al ruolo

L'autenticazione Kerberos in Linux o macOS non fornisce informazioni sul ruolo per un utente autenticato. Per aggiungere informazioni sui ruoli e sui gruppi a un utente Kerberos, è necessario configurare il gestore di autenticazione per recuperare i ruoli da un dominio LDAP. La configurazione più semplice specifica solo un dominio LDAP su cui eseguire query e userà il contesto dell'utente autenticato per eseguire query sul dominio LDAP:

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

Alcune configurazioni possono richiedere credenziali specifiche per eseguire query sul dominio LDAP. Le credenziali possono essere specificate nelle opzioni evidenziate seguenti:

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();
}

Per impostazione predefinita, il gestore di autenticazione negotiate risolve i domini annidati. In un ambiente LDAP di grandi dimensioni o complicato, la risoluzione dei domini annidati può comportare una ricerca lenta o una quantità elevata di memoria usata per ogni utente. La risoluzione del dominio annidata può essere disabilitata usando l'opzione IgnoreNestedGroups .

Le richieste anonime sono consentite. Usare ASP.NET'autorizzazione di base per verificare le richieste anonime per l'autenticazione.

AuthenticationScheme richiede il pacchetto NuGet Microsoft.AspNetCore.Authentication.Negotiate.

Configurazione dell'ambiente Windows

Il componente Microsoft.AspNetCore.Authentication.Negotiate esegue l'autenticazione in modalità utente. I nomi dell'entità servizio (SPN) devono essere aggiunti all'account utente che esegue il servizio, non all'account del computer. Eseguire setspn -S HTTP/myservername.mydomain.com myuser in una shell dei comandi amministrativa.

Configurazione dell'ambiente Linux e macOS

Le istruzioni per aggiungere un computer Linux o macOS a un dominio Windows sono disponibili nell'articolo Connettere Azure Data Studio a SQL Server usando autenticazione di Windows - Kerberos. Le istruzioni creano un account computer per il computer Linux nel dominio. I nomi SPN devono essere aggiunti all'account del computer.

Dopo aver aggiunto il computer Linux o macOS al dominio, sono necessari passaggi aggiuntivi per fornire un file keytab con i nomi SPN:

• Nel controller di dominio aggiungere nuovi nomi SPN del servizio Web all'account del computer:
  • setspn -S HTTP/mywebservice.mydomain.com mymachine
  • setspn -S HTTP/mywebservice@MYDOMAIN.COM mymachine
• Usare ktpass per generare un file 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
  • Alcuni campi devono essere specificati in lettere maiuscole come indicato.
• Copiare il file keytab nel computer Linux o macOS.
• Selezionare il file keytab tramite una variabile di ambiente: export KRB5_KTNAME=/tmp/mymachine.HTTP.keytab
• Richiamare klist per visualizzare i nomi SPN attualmente disponibili per l'uso.

HTTP.sys

HTTP.sys supporta l'autenticazione di Windows in modalità kernel tramite l'autenticazione Negotiate, NTLM o Basic.

Aggiungere i servizi di autenticazione richiamando AddAuthentication (Microsoft.AspNetCore.Server.HttpSys spazio dei nomi) in Startup.ConfigureServices:

services.AddAuthentication(HttpSysDefaults.AuthenticationScheme);

Configurare l'host Web dell'app per l'uso di HTTP.sys con l'autenticazione di Windows (Program.cs). UseHttpSys è nello spazio dei Microsoft.AspNetCore.Server.HttpSys nomi .

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

Autorizzare gli utenti

Lo stato di configurazione dell'accesso anonimo determina il modo in cui [Authorize] gli attributi e [AllowAnonymous] vengono usati nell'app. Le due sezioni seguenti illustrano come gestire gli stati di configurazione non consentiti e consentiti dell'accesso anonimo.

Non consentire l'accesso anonimo

Quando l'autenticazione di Windows è abilitata e l'accesso anonimo è disabilitato, gli [Authorize] attributi e [AllowAnonymous] non hanno alcun effetto. Se un sito IIS è configurato per impedire l'accesso anonimo, la richiesta non raggiunge mai l'app. Per questo motivo, l'attributo [AllowAnonymous] non è applicabile.

Consenti accesso anonimo

Quando l'autenticazione di Windows e l'accesso anonimo sono abilitati, usare gli [Authorize] attributi e [AllowAnonymous] . L'attributo [Authorize] consente di proteggere gli endpoint dell'app che richiedono l'autenticazione. L'attributo [AllowAnonymous] esegue l'override dell'attributo nelle app che consentono l'accesso [Authorize] anonimo. Per informazioni dettagliate sull'utilizzo degli attributi, vedere Autorizzazione semplice in ASP.NET Core.

Rappresentazione

ASP.NET Core non implementa la rappresentazione. Le app vengono eseguite con l'app identity per tutte le richieste, usando il pool di app o il processo identity. Se l'app deve eseguire un'azione per conto di un utente, usare WindowsIdentity.RunImpersonated o RunImpersonatedAsync in un middleware inline del terminale in Startup.Configure. Eseguire una singola azione in questo contesto e quindi chiudere il contesto.

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());
    }
});

Mentre il pacchetto Microsoft.AspNetCore.Authentication.Negotiate abilita l'autenticazione in Windows, Linux e macOS, la rappresentazione è supportata solo in Windows.

Trasformazioni delle attestazioni

Quando si ospita con IIS, AuthenticateAsync non viene chiamato internamente per inizializzare un utente. Pertanto, un'implementazione di IClaimsTransformation usate per trasformare le attestazioni dopo ogni autenticazione non viene attivata per impostazione predefinita. Per altre informazioni e un esempio di codice che attiva le trasformazioni delle attestazioni, vedere Differenze tra hosting in-process e out-of-process.

Risorse aggiuntive

• dotnet publish
• Host ASP.NET Core in Windows con IIS
• Modulo ASP.NET Core (ANCM) per IIS
• Profili di pubblicazione di Visual Studio (.pubxml) per la distribuzione di app ASP.NET Core