Configurare l'autenticazione di Windows in ASP.NET Core

Di Rick Anderson e Kirk Larkin

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.

Quando usare l'autenticazione di Windows

L'autenticazione di Windows è adatta alle applicazioni Web che operano all'interno della rete interna privata di un'organizzazione, accessibili solo ai dipendenti (e ad altri utenti autorizzati) all'interno della stessa rete. La gestione degli utenti viene eseguita all'interno di Active Directory (AD) e gli utenti usano l'account di dominio di Windows esistente per l'autenticazione.

L'autenticazione di Windows offre diversi vantaggi per le applicazioni Intranet:

• Esperienza utente facile : gli utenti vengono autenticati automaticamente in base alla sessione di Windows attiva o vengono richiesti di immettere le credenziali di Windows tramite una finestra di dialogo standard del browser.
• Integrazione con Active Directory : sfrutta i criteri di sicurezza e l'infrastruttura di Windows esistenti, inclusi i gruppi di utenti, i blocchi degli account e l'autenticazione a più fattori (MFA).
• Gestione sicura delle credenziali : l'autenticazione viene gestita tramite protocolli sicuri come Kerberos, senza dover gestire credenziali utente separate.
• Autorizzazione basata sui ruoli: le applicazioni possono accedere alle informazioni di utenti e gruppi da Active Directory, abilitando il controllo degli accessi in base al ruolo all'interno dell'applicazione.
• Riduzione del sovraccarico amministrativo : non è necessario gestire un database utente separato o un sistema di gestione delle credenziali.

In questo modo, l'autenticazione di Windows è ideale per le organizzazioni che vogliono usare l'infrastruttura di Windows esistente, ad esempio i portali Intranet.

Note

L'autenticazione di Windows non è supportata con HTTP/2. Sebbene i problemi di autenticazione possano essere inviati tramite risposte HTTP/2, il client deve effettuare il downgrade a HTTP/1.1 per completare il processo di autenticazione. Si tratta di una limitazione del protocollo, non di una deprecazione dell'autenticazione di Windows. Dopo l'autenticazione, la normale comunicazione HTTP/2 può riprendere per le richieste successive.

Per le applicazioni pubbliche, l'autenticazione di Windows non è consigliata a causa di problemi di sicurezza e usabilità. Questi motivi includono:

• L'autenticazione di Windows viene mantenuta interna per proteggere Active Directory, esponendola all'esterno di una rete interna comporta rischi per la sicurezza.
• Gli utenti esterni non hanno account di dominio di Windows.
• È complesso configurare l'infrastruttura di rete necessaria in modo sicuro e firewall o proxy possono interferire con il processo di autenticazione.
• Non è multipiattaforma e non offre opzioni di personalizzazione per progetti ed esperienze utente.

Alternative per scenari diversi

A seconda dei requisiti dell'applicazione, prendere in considerazione queste alternative:

Per le applicazioni pubbliche:

• OpenID Connect con provider di identità esterni
• ASP.NET Core Identity con account utente locali (Introduzione su Identity in ASP.NET Core)
• Azure Active Directory (AAD) per ambienti Microsoft 365

Per gli ambienti misti con utenti intranet ed esterni:

• Active Directory Federation Services (ADFS) con OpenID Connect
• Azure Active Directory con configurazione ibrida

Per gli ambienti aziendali che usano l'autenticazione moderna:

• Azure Active Directory con Single Sign-On
• Soluzioni basate su SAML con provider di identità di terze parti

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 NuGetMicrosoft.AspNetCore.Authentication.Negotiate e i servizi di autenticazione chiamando in AddAuthentication:

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.

Visual Studio

Nuovo progetto

Creare una nuova Razor app Pages o MVC. Nella finestra di dialogo Informazioni aggiuntive impostare Il tipo di autenticazione su Windows.

Eseguire l'app. Il nome utente viene visualizzato nell'interfaccia utente dell'app sottoposta a rendering.

Progetto esistente

Le proprietà del progetto abilitano l'autenticazione di Windows e disabilitano l'autenticazione anonima. Aprire la finestra di dialogo profili di avvio:

1. In Esplora soluzioni fare clic con il pulsante destro del mouse sul progetto e selezionare Proprietà.
2. Selezionare la scheda Debug > Generale e selezionare Aprire interfaccia utente profili di avvio debug.
3. Deselezionare la casella di controllo Abilita autenticazione anonima.
4. Selezionare la casella di controllo Abilita autenticazione di Windows.

In alternativa, le proprietà possono essere configurate nel iisSettings nodo del launchSettings.json file:

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

Interfaccia della riga di comando di .NET (CLI)

Nuovo progetto

Eseguire il comando dotnet new con l'argomento webapp e l'opzione --auth Windows (ASP.NET Core Web App):

dotnet new webapp --auth Windows

Progetto esistente

Aggiornare il iisSettings nodo del launchSettings.json file:

"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 SDK (senza la <IsTransformWebConfigDisabled> proprietà impostata su true nel file di progetto), il file diweb.config pubblicato include la <location><system.webServer><security><authentication> sezione . Per altre informazioni sulla <IsTransformWebConfigDisabled> proprietà, vedere web.config file.

• 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 sezione <system.webServer> aggiunta al file web.config tramite Gestione di IIS si trova al di fuori della sezione dell'app <location> aggiunta dall'SDK .NET 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 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 Microsoft.AspNetCore.Authentication.Negotiate pacchetto NuGet può essere usato con Kestrel per abilitare l'autenticazione di Windows tramite Negotiate e Kerberos in Windows, Linux e macOS.

Warning

Le credenziali possono essere mantenute tra le richieste in una connessione. L'autenticazione negoziata non deve essere usata con proxy, a meno che il proxy non mantenga un'affinità di connessione 1:1 (una connessione permanente) con Kestrel.

Note

Il gestore Negotiate rileva se il server sottostante supporta l'autenticazione di Windows in modo nativo e se è abilitato. Se il server supporta l'autenticazione di Windows ma è disabilitato, viene generato un errore che chiede di abilitare l'implementazione del server. Quando l'autenticazione di Windows è abilitata nel server, il gestore Negotiate inoltra in modo trasparente le richieste di autenticazione.

L'autenticazione e i criteri di autorizzazione di fallback sono abilitati 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.

Righe evidenziate:

• 5-6: AddAuthentication registrare e AddNegotiate configurare il gestore di autenticazione Negotiate.
• 8-11: AddAuthorization con una politica di fallback impone gli utenti autenticati per impostazione predefinita.
• 26: UseAuthentication esegue i gestori di autenticazione per ogni richiesta e popola HttpContext.User.
• 27: UseAuthorization valuta i criteri di autorizzazione, inclusi i criteri di fallback.

Note

Chiamando AddAuthentication e AddNegotiate registra e configura il gestore Negotiate; non esegue l'autenticazione per ogni richiesta. Il middleware di autenticazione (UseAuthentication) richiama il gestore e popola HttpContext.Usere deve essere visualizzato prima UseAuthorization per il funzionamento della valutazione dei criteri.

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

L'APIMicrosoft.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.

Note

Quando si seguono le indicazioni riportate nell'articolo Connettere Azure Data Studio a SQL Server usando autenticazione di Windows - Kerberos, sostituire python-software-properties conpython3-software-properties, se necessario.

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.

Note

Un file keytab contiene le credenziali di accesso al dominio e deve essere protetto di conseguenza.

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

Note

HTTP.sys delegati all'autenticazione in modalità kernel con il protocollo di autenticazione Kerberos. L'autenticazione in modalità utente non è supportata con Kerberos e HTTP.sys. È necessario usare l'account del computer per decrittografare il token/ticket Kerberos ottenuto da Active Directory e inoltrato dal client al server per autenticare l'utente. Registrare il nome dell'entità servizio per l'host, non l'utente dell'app.

Note

HTTP.sys non è supportato in Nano Server versione 1709 o successiva. Per usare l'autenticazione di Windows e HTTP.sys con Nano Server, usare un contenitore Server Core (microsoft/windowsservercore) (vedere https://hub.docker.com/_/microsoft-windows-servercore). Per altre informazioni su Server Core, vedere Che cos'è l'opzione di installazione Server Core in Windows Server?.

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.

Note

Per impostazione predefinita, gli utenti che non dispongono dell'autorizzazione per accedere a una pagina vengono presentati con una risposta HTTP 403 vuota. Il middleware StatusCodePages può essere configurato per offrire agli utenti una migliore esperienza di accesso negato.

Impersonation

ASP.NET Core non implementa la rappresentazione. Le app vengono eseguite con l'identità dell'app per tutte le richieste, utilizzando il pool di applicazioni o l'identità del processo. 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 Microsoft.AspNetCore.Authentication.Negotiate pacchetto abilita l'autenticazione su Windows, Linux e macOS, l'impersonazione è supportata solo su 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

• di pubblicazione dotnet
• 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