Eseguire la migrazione dell'autenticazione di ASP.NET Framework a ASP.NET Core

L'autenticazione è un componente fondamentale delle applicazioni Web, che gestisce la verifica dell'identità utente tra le richieste HTTP. Quando si esegue la migrazione da ASP.NET Framework a ASP.NET Core, l'autenticazione presenta problemi univoci perché i due framework gestiscono l'autenticazione in modo molto diverso.

Per informazioni generali sull'autenticazione in ASP.NET Core, vedere Panoramica dell'autenticazione principale di ASP.NET. Per informazioni sull'autorizzazione, vedere Introduzione all'autorizzazione in ASP.NET Core.

Perché la migrazione dell'autenticazione è complessa

ASP.NET Framework e ASP.NET Core hanno approcci fondamentali all'autenticazione:

ASP.NET Framework fornisce moduli di autenticazione predefiniti con configurazione automatica e stretta integrazione con System.Web
ASP.NET Core usa un approccio basato sul middleware con configurazione esplicita e inserimento di dipendenze

Queste differenze indicano che non è possibile spostare semplicemente il codice di autenticazione da Framework a Core senza modifiche.

Problemi di autenticazione e migrazione

Diversi tipi di autenticazione presentano diversi livelli di complessità della migrazione:

ASP.NET Framework: utilizza il middleware di autenticazione Microsoft.Owincookie
ASP.NET Core: usa CookieAuthentication il middleware con una configurazione diversa
Problema di migrazione: Cookie formato, chiavi di crittografia e differenze di configurazione

Token di connessione JWT

ASP.NET Framework: spesso gestito tramite moduli personalizzati o middleware OWIN
ASP.NET Core: supporto nativo tramite Microsoft.AspNetCore.Authentication.JwtBearer
Richiesta di migrazione: differenze dei parametri di convalida dei token e registrazione del middleware

Autenticazione di Windows

ASP.NET Framework: integrazione integrata di IIS
ASP.NET Core: richiede una configurazione esplicita e potrebbe richiedere modifiche al modello di hosting
Problema di migrazione: differenze tra la configurazione del server e il flusso di autenticazione

Autenticazione basata su form

framework ASP.NET: predefinito System.Web.Security.FormsAuthentication
ASP.NET Core: nessun equivalente diretto richiede la migrazione all'autenticazione cookie
Richiesta di migrazione: Completare la riscrittura del sistema di autenticazione necessaria

Autenticazione personalizzata

ASP.NET Framework: moduli personalizzati che implementano IHttpModule
ASP.NET Core: middleware personalizzato o gestori di autenticazione
Richiesta di migrazione: Completare la modifica dell'architettura dai moduli al middleware

Panoramica delle strategie di migrazione

Sono disponibili tre approcci principali per la gestione dell'autenticazione durante la migrazione:

Riscrittura completa : riscrivere tutto il codice di autenticazione per usare l'autenticazione nativa di ASP.NET Core
Autenticazione remota : usare gli adattatori System.Web per delegare l'autenticazione all'app ASP.NET Framework
Autenticazione condivisa cookie - Condividere i cookie di autenticazione tra applicazioni Framework e Core (per scenari basati su OWIN)

Per la maggior parte delle applicazioni, la migrazione all'autenticazione nativa ASP.NET Core offre prestazioni ottimali e gestibilità. Tuttavia, le applicazioni di dimensioni maggiori o quelle con requisiti di autenticazione complessi possono trarre vantaggio da un approccio incrementale tramite le schede System.Web.

Scegliere l'approccio alla migrazione

Sono disponibili tre opzioni principali per la migrazione dell'autenticazione da ASP.NET Framework a ASP.NET Core. La scelta dipende dal tipo di autenticazione, dalla sequenza temporale di migrazione, dal fatto che sia necessario eseguire entrambe le applicazioni contemporaneamente e dalla quantità di codice che si è disposti a riscrivere.

Guida rapida alle decisioni

Rispondere a queste domande per scegliere l'approccio:

Si sta eseguendo una riscrittura completa o una migrazione incrementale?
- Riscrittura completa → Riscrittura completa per l'autenticazione di ASP.NET Core
- Migrazione incrementale → Continuare con la domanda 2
Quale tipo di autenticazione viene usata dall'app ASP.NET Framework?
- Autenticazione OWIN cookie → Continuare con la domanda 3
- Autenticazione basata su form, token di connessione JWT, autenticazione di Windows o autenticazione personalizzata → autenticazione remota
Le app ASP.NET Framework e ASP.NET Core devono accedere allo stesso stato di autenticazione?
- Sì, l'autenticazione condivisa necessaria → Continuare con la domanda 4
- No, l'autenticazione separata è → Riscrittura completa per l'autenticazione di ASP.NET Core
È possibile configurare le impostazioni di protezione dei dati corrispondenti tra entrambe le app?
- Sì → l'autenticazione condivisa cookie (vedere la sezione Alternative, prestazioni ottimali)
- Nessuna o non sicura → 'autenticazione remota

Confronto degli approcci di migrazione

Avvicinarsi	Modifiche al codice	Prestazioni	Condivisione dell'autenticazione	Quando usare
Riscrittura completa	Alto - Riscrivere tutto il codice di autenticazione	Elevate	Nessuno	Riscritture complete, app con prestazioni critiche, autenticazione diversa da OWIN
Autenticazione remota	Basso - Mantenere i modelli esistenti	Discreto	Completo	Migrazioni incrementali, autenticazione complessa, autenticazione di Windows
Cookie condivisi	Medio - Configurazione dell'aggiornamento	Bene	Completo	Autenticazione OWIN cookie , autenticazione condivisa critica per le prestazioni (vedere Alternative)

Completamente riscrivere l'autenticazione in ASP.NET Core

Scegliere questo approccio quando si esegue una migrazione completa, si dispone di autenticazione non OWIN o si vuole ottenere prestazioni ottimali e gestibilità.

ASP.NET Core offre supporto completo per l'autenticazione con prestazioni elevate e opzioni di personalizzazione complete. Questo approccio richiede la riscrittura del codice di autenticazione, ma offre i vantaggi più vantaggiosi a lungo termine.

Riscrivere completamente: vantaggi e svantaggi

Vantaggi	Svantaggi
Prestazioni e sicurezza ottimali	Richiede la riscrittura di tutto il codice di autenticazione
Implementazione nativa ASP.NET Core	Nessun percorso di migrazione automatica
Controllo completo sul flusso di autenticazione	Curva di apprendimento per i nuovi modelli di autenticazione
Nessuna dipendenza aggiuntiva	Modifica di rottura dagli schemi del framework
Accesso alle funzionalità di autenticazione di base di ASP.NET più recenti	Potenziale tempo di inattività durante la migrazione

Considerazioni sulla migrazione

Quando si esegue la migrazione all'autenticazione nativa ASP.NET Core:

Scegliere in base al tipo di autenticazione framework:

Autenticazione basata su form → Eseguire la migrazione all'autenticazioneCookie
Token di connessione JWT → Eseguire la migrazione all'autenticazione bearer JWT
Autenticazione di Windows → Usare l'autenticazione di Windows
Provider OAuth OWIN → Usare i provider OAuth di ASP.NET Core corrispondenti
Autenticazione personalizzata → Implementare gestori di autenticazione personalizzati

Modifiche al codice necessarie:

Sostituizione dei schemi di accesso HttpContext.User (in gran parte compatibili)
Aggiornare la registrazione del middleware di autenticazione in Program.cs
Eseguire la migrazione della logica di autenticazione personalizzata a modelli di base ASP.NET
Aggiornare gli attributi e i criteri di autorizzazione

Quando scegliere questo approccio:

È possibile riscrivere il codice correlato all'autenticazione
Le prestazioni sono una priorità assoluta
Non si condivide lo stato di autenticazione con le applicazioni legacy
Vuoi eliminare completamente le dipendenze da System.Web.
L'app Framework utilizza l'autenticazione Forms, moduli personalizzati o token JWT

Autenticazione remota

Annotazioni

In questo modo si usano gli adapter System.Web per semplificare la migrazione.

Scegliere questo approccio quando è necessario condividere l'autenticazione tra il framework di ASP.NET e le applicazioni core ASP.NET durante la migrazione incrementale o quando è difficile eseguire la migrazione di un'autenticazione complessa.

La funzionalità di autenticazione remota degli adapter System.Web consente a un'app ASP.NET Core di determinare l'identità di un utente rinviando a un'app ASP.NET. Ciò consente la migrazione graduale mantenendo un singolo sistema di autenticazione.

Funzionamento dell'autenticazione remota

Quando le richieste vengono elaborate dall'app ASP.NET Core, se l'autenticazione remota dell'app è lo schema predefinito o specificato dall'endpoint della richiesta, tenterà RemoteAuthenticationAuthHandler di autenticare l'utente.
Il gestore invia una richiesta HTTP all'endpoint di autenticazione dell'applicazione ASP.NET, inoltrando le intestazioni configurate della richiesta attuale (per impostazione predefinita, le intestazioni Authorization e Cookie).
L'app ASP.NET elabora l'autenticazione e restituisce un codice di stato HTTP serializzato ClaimsPrincipal o http che indica un errore.
L'app ASP.NET Core usa il risultato per stabilire l'identità dell'utente o gestire i problemi di autenticazione.

Vantaggi e svantaggi dell'autenticazione remota

Vantaggi	Svantaggi
Modifiche minime al codice necessarie	Sovraccarico aggiuntivo della richiesta HTTP
Funziona con qualsiasi tipo di autenticazione framework	Dipendenza di rete tra app
Funzionalità di migrazione graduale	Debug più complesso
Mantiene la logica di autenticazione esistente	Richiede l'esecuzione di entrambe le app
Gestisce scenari di autenticazione complessi	Supporto limitato per l'autenticazione di Windows

Quando scegliere l'autenticazione remota

Scegliere Autenticazione remota quando:

L'app ASP.NET non usa Microsoft.Owincookie l'autenticazione
Si vuole una soluzione flessibile che funziona con vari meccanismi di autenticazione
È necessario eseguire gradualmente la migrazione della logica di autenticazione a ASP.NET Core
Si dispone di un'autenticazione personalizzata complessa difficile da riscrivere
Si sta eseguendo una migrazione incrementale ed è necessario lo stato di autenticazione condivisa

Configurazione dell'autenticazione remota

Esistono solo alcune piccole modifiche al codice necessarie per abilitare l'autenticazione remota in una soluzione già configurata in base alle attività iniziali.

Prima di tutto, seguire le istruzioni di configurazione dell'app remota per connettere le app ASP.NET Core e ASP.NET. Esistono quindi solo un paio di metodi di estensione aggiuntivi da chiamare per abilitare l'autenticazione remota dell'app.

configurazione dell'app ASP.NET

L'app ASP.NET deve essere configurata per aggiungere l'endpoint di autenticazione. L'aggiunta dell'endpoint di autenticazione viene eseguita chiamando il AddAuthenticationServer metodo di estensione per configurare il modulo HTTP che controlla le richieste all'endpoint di autenticazione. Si noti che gli scenari di autenticazione remota in genere vogliono aggiungere anche il supporto proxy, in modo che qualsiasi autenticazione correlata reindirizzi correttamente all'app ASP.NET Core anziché al ASP.NET uno.

HttpApplicationHost.RegisterHost(builder =>
{
    builder.AddSystemWebAdapters()
        .AddProxySupport(options => options.UseForwardedHeaders = true)
        .AddRemoteAppServer(options =>
        {
            options.ApiKey = ConfigurationManager.AppSettings["RemoteAppApiKey"];
        })
        .AddAuthenticationServer();
});

configurazione dell'app core ASP.NET

Successivamente, l'app ASP.NET Core deve essere configurata per abilitare il gestore di autenticazione che autentica gli utenti effettuando una richiesta HTTP all'app ASP.NET. Anche in questo caso, questa operazione viene eseguita chiamando AddAuthenticationClient quando si registrano i servizi di adapter System.Web:

builder.Services.AddSystemWebAdapters()
    .AddRemoteAppClient(options =>
    {
        options.RemoteAppUrl = new Uri(builder.Configuration
            ["ReverseProxy:Clusters:fallbackCluster:Destinations:fallbackApp:Address"]);
        options.ApiKey = builder.Configuration["RemoteAppApiKey"];
    })
    .AddAuthenticationClient(true);

Il valore booleano passato alla AddAuthenticationClient chiamata specifica se l'autenticazione remota dell'app deve essere lo schema di autenticazione predefinito. true Il passaggio causerà l'autenticazione dell'utente tramite l'autenticazione remota dell'app per tutte le richieste, mentre il passaggio false significa che l'utente verrà autenticato solo con l'autenticazione remota dell'app se lo schema dell'app remota viene richiesto specificamente (con [Authorize(AuthenticationSchemes = RemoteAppAuthenticationDefaults.AuthenticationScheme)] su un controller o un metodo di azione, ad esempio). Il passaggio di false per questo parametro ha il vantaggio di effettuare solo richieste HTTP all'app di ASP.NET originale per l'autenticazione per gli endpoint che richiedono l'autenticazione remota dell'app, ma ha lo svantaggio di richiedere annotazioni a tutti questi endpoint per indicare che useranno l'autenticazione remota dell'app.

Quando si usa Aspire, la configurazione verrà eseguita tramite le variabili di ambiente e viene impostata da AppHost. Per abilitare la sessione remota, è necessario abilitare l'opzione :

...

var coreApp = builder.AddProject<Projects.AuthRemoteIdentityCore>("core")
    .WithHttpHealthCheck()
    .WaitFor(frameworkApp)
    .WithIncrementalMigrationFallback(frameworkApp, options => options.RemoteAuthentication = RemoteAuthentication.DefaultScheme);

...

Al termine, verrà automaticamente collegato sia nel framework che nelle applicazioni principali.

Uso dell'autenticazione remota con endpoint specifici

Quando si imposta lo schema predefinito su false, è possibile specificare l'autenticazione remota per controller o azioni specifici:

[Authorize(AuthenticationSchemes = RemoteAppAuthenticationDefaults.AuthenticationScheme)]
public class SecureController : Controller
{
    // This controller uses remote authentication
    public IActionResult Index()
    {
        return View();
    }
}

// Or on specific actions
public class HomeController : Controller
{
    [Authorize(AuthenticationSchemes = RemoteAppAuthenticationDefaults.AuthenticationScheme)]
    public IActionResult SecureAction()
    {
        return View();
    }
}

Implementazione di processori di risultati di autenticazione personalizzati

È possibile implementare processori personalizzati per modificare i risultati dell'autenticazione prima di utilizzarli:

public class CustomAuthResultProcessor : IRemoteAuthenticationResultProcessor
{
    public Task ProcessAsync(RemoteAuthenticationResult result, HttpContext context)
    {
        // Custom logic to process authentication results
        if (result.Headers.ContainsKey("Location"))
        {
            // Modify redirect URLs or other logic
        }
        
        return Task.CompletedTask;
    }
}

// Register the custom processor
builder.Services.AddScoped<IRemoteAuthenticationResultProcessor, CustomAuthResultProcessor>();

Infine, se l'app ASP.NET Core non includeva in precedenza il middleware di autenticazione, che dovrà essere abilitato (dopo il middleware di routing, ma prima del middleware di autorizzazione). Per altre informazioni sull'ordinamento del middleware, vedere ASP.NET Middleware core:

app.UseAuthentication();

Considerazioni sulla sicurezza

Quando si implementa l'autenticazione remota, considerare gli aspetti di sicurezza seguenti:

Sicurezza della chiave API: la chiave API usata per la comunicazione tra le app ASP.NET Core e ASP.NET deve essere archiviata con sicurezza usando provider di configurazione e non codificata.
Sicurezza di rete: le comunicazioni tra le app devono essere eseguite tramite canali sicuri (HTTPS) negli ambienti di produzione.
Inoltro delle intestazioni: prestare attenzione a quali intestazioni vengono inoltrate per evitare di esporre informazioni riservate. Inoltra solo le intestazioni necessarie per l'autenticazione.
Endpoint Protection: l'endpoint di autenticazione nell'app ASP.NET deve essere accessibile solo all'app ASP.NET Core, non ai client esterni.

Risoluzione dei problemi

Problemi comuni durante la configurazione dell'autenticazione remota:

Errori di autenticazione: verificare che le chiavi API corrispondano tra le applicazioni e che il percorso dell'endpoint di autenticazione sia configurato correttamente.
Cicli di reindirizzamento: assicurarsi che il RedirectUrlProcessor sia configurato correttamente per reindirizzare all'applicazione ASP.NET Core anziché all'applicazione ASP.NET.
Attestazioni mancanti: verificare che l'app ASP.NET serializzi ClaimsPrincipal correttamente e che siano incluse tutte le attestazioni necessarie.

Progettazione

Quando le richieste vengono elaborate dall'app ASP.NET Core, se l'autenticazione remota dell'app è lo schema predefinito o specificato dall'endpoint della richiesta, tenterà RemoteAuthenticationAuthHandler di autenticare l'utente.
1. Il gestore effettuerà una richiesta HTTP all'endpoint di autenticazione dell'app ASP.NET. Copierà le intestazioni configurate dalla richiesta corrente in questa nuova per inoltrare i dati rilevanti per l'autenticazione. Come accennato in precedenza, il comportamento predefinito consiste nel copiare le Authorization intestazioni e Cookie . L'intestazione della chiave API viene aggiunta anche a scopo di sicurezza.
L'app ASP.NET gestisce le richieste inviate all'endpoint di autenticazione. Se le chiavi API corrispondono, l'app ASP.NET restituirà la serializzazione dell'utente corrente nel corpo della ClaimsPrincipal risposta oppure restituirà un codice di stato HTTP (ad esempio 401 o 302) e intestazioni di risposta che indicano un errore.
Quando l'app RemoteAuthenticationAuthHandler ASP.NET Core riceve la risposta dall'app ASP.NET:
1. Se è stato restituito correttamente un ClaimsPrincipal, il gestore dell'autenticazione lo deserializzerà e lo userà come identità dell'utente corrente.
2. Se un claimsPrincipal non è stato restituito correttamente, il gestore archivierà il risultato e se l'autenticazione viene richiesta (perché l'utente accede a una risorsa protetta, ad esempio), la risposta della richiesta verrà aggiornata con il codice di stato e le intestazioni di risposta selezionate dalla risposta dall'endpoint di autenticazione. Ciò consente la propagazione delle risposte di verifica (ad esempio i reindirizzamenti a una pagina di accesso) agli utenti finali.
  1. Poiché i risultati dell'endpoint di autenticazione dell'app ASP.NET possono includere dati specifici per tale endpoint, gli utenti possono registrare IRemoteAuthenticationResultProcessor implementazioni con l'app ASP.NET Core che verrà eseguita su tutti i risultati dell'autenticazione prima che vengano usati. Ad esempio, quello predefinito IRemoteAuthenticationResultProcessor è RedirectUrlProcessor che cerca Location le intestazioni di risposta restituite dall'endpoint di autenticazione e garantisce che vengano reindirizzate all'host dell'app ASP.NET Core e non direttamente all'app ASP.NET.

Limitazioni note

Questo approccio di autenticazione remota presenta due limitazioni note:

Autenticazione di Windows: poiché l'autenticazione di Windows dipende da un handle per un'identità di Windows, l'autenticazione di Windows non è supportata da questa funzionalità. Il lavoro futuro è pianificato per esplorare il funzionamento delle autenticazione di Windows condivise. Per altre informazioni, vedere dotnet/systemweb-adapters#246 . Per gli scenari di autenticazione di Windows, considera di usare Configurazione dell'autenticazione di Windows in ASP.NET Core nella tua applicazione ASP.NET Core.
Azioni di gestione utenti: questa funzionalità consente all'app ASP.NET Core di usare un'identità autenticata dall'app ASP.NET, ma tutte le azioni correlate agli utenti (accesso, disconnessione e così via) devono comunque essere instradate tramite l'app ASP.NET.
Considerazioni sulle prestazioni: ogni richiesta di autenticazione richiede una chiamata HTTP all'app ASP.NET, che può influire sulle prestazioni. Valutare la possibilità di usare l'autenticazione condivisa cookie (descritta nella sezione Alternative) se le prestazioni sono critiche.

Se l'autenticazione nell'app ASP.NET viene eseguita usando Microsoft.OwinCookie il middleware di autenticazione, un'alternativa all'autenticazione remota consiste nel configurare le app ASP.NET e ASP.NET Core in modo che possano condividere un'autenticazione cookie.

Funzionamento dei cookie condivisi

La condivisione di un'autenticazione cookie abilita:

Entrambe le app sono utilizzate per determinare l'identità dell'utente dalla stessa cookie.
L'accesso o l'uscita da un'app consente all'utente di accedere o uscire dall'altra app.

Entrambe le applicazioni sono configurate per:

Usare lo stesso nome e le stesse cookie impostazioni di dominio
Condividere le chiavi di protezione dei dati per cookie la crittografia/decrittografia
Usare il middleware di autenticazione compatibile cookie

Ciò consente agli utenti autenticati in un'app di essere autenticati automaticamente nell'altra app quando effettuano richieste.

Vantaggi	Svantaggi
Prestazioni ottimali per l'autenticazione condivisa	Funziona solo con l'autenticazione OWIN cookie
Nessuna richiesta HTTP aggiuntiva	Richiede la configurazione di protezione dei dati corrispondente
Entrambe le app possono gestire l'accesso/disconnesso	Configurazione iniziale più complessa
Esperienza utente senza problemi	Limitata a un'autenticazione basata su cookie
Riduzione del sovraccarico di rete	Richiede il coordinamento delle distribuzioni

Limitazioni di autenticazione con i cookie condivisi

Si noti che poiché l'accesso dipende in genere da un database specifico, non tutte le funzionalità di autenticazione funzioneranno in entrambe le app:

Gli utenti devono eseguire l'accesso solo tramite una delle app, ovvero l'app ASP.NET o ASP.NET Core, indipendentemente dal fatto che il database sia configurato per funzionare.
Entrambe le app sono in grado di visualizzare l'identità e le attestazioni degli utenti.
Entrambe le app sono in grado di disconnettere l'utente.

Informazioni dettagliate su come configurare la condivisione dei cookie di autenticazione tra ASP.NET e ASP.NET App Core sono disponibili nella cookie documentazione sulla condivisione. Per altre informazioni sull'autenticazione cookie in ASP.NET Core, vedere Usare cookie l'autenticazione senza ASP.NET Core Identity.

Gli esempi seguenti nel repository GitHub System.Web adapters illustrano l'autenticazione remota delle app con configurazione condivisa cookie che consente a entrambe le app di accedere e disconnettere gli utenti:

dell'app ASP.NET
ASP.NET'app Core

Scegliere Autenticazione condivisa Cookie quando:

L'app ASP.NET usa già l'autenticazione Microsoft.Owincookie
È possibile configurare le impostazioni di protezione dei dati corrispondenti tra entrambe le app
Le prestazioni sono fondamentali e si vuole ridurre al minimo le richieste HTTP
Si desidera che entrambe le app gestiscano le operazioni di accesso/disconnessione utente
Si ha familiarità con la gestione delle chiavi di crittografia condivise

L'autenticazione di condivisione è un'opzione valida se sono soddisfatte entrambe le condizioni seguenti:

L'app ASP.NET usa Microsoft.Owincookie già l'autenticazione.
È possibile aggiornare l'app ASP.NET e le app core ASP.NET per usare le impostazioni di protezione dei dati corrispondenti. Le impostazioni di protezione dei dati condivise corrispondenti includono un percorso di file condiviso, una cache Redis o un Archiviazione BLOB di Azure per l'archiviazione delle chiavi di protezione dei dati. Per altre informazioni, vedere Panoramica della protezione dei dati di ASP.NET Core.

Per altri scenari, l'approccio di autenticazione remota descritto in precedenza in questo documento è più flessibile ed è probabilmente più adatto.

Vedere anche

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2025-09-24