Proteggere ASP.NET app sul lato Blazor server Core

Questo articolo illustra come proteggere le app lato Blazor server come applicazioni principali ASP.NET.

Le app lato Blazor server vengono configurate per la sicurezza nello stesso modo delle app core ASP.NET. Per altre informazioni, vedere gli articoli negli argomenti dedicati alla sicurezza di ASP.NET Core.

Il contesto di autenticazione viene stabilito solo all'avvio dell'app, ovvero quando l'app si connette per la prima volta al WebSocket. Il contesto di autenticazione viene mantenuto per la durata del circuito. Le app riconvalidano periodicamente lo stato di autenticazione dell'utente ogni 30 minuti.

Se l'app deve acquisire utenti per servizi personalizzati o reagire agli aggiornamenti all'utente, vedere Scenari di sicurezza aggiuntivi sul lato server ASP.NET CoreBlazor.

Blazor differisce da un'app Web con rendering server tradizionale che effettua nuove richieste HTTP con cookie in ogni spostamento di pagina. L'autenticazione viene verificata durante gli eventi di spostamento. Tuttavia, i cookie non sono coinvolti. I cookie vengono inviati solo quando si effettua una richiesta HTTP a un server, che non avviene quando l'utente si sposta in un'app Blazor . Durante la navigazione, lo stato di autenticazione dell'utente viene controllato all'interno del Blazor circuito, che è possibile aggiornare in qualsiasi momento nel server usando una riconvalida di AuthenticationStateProvider](#additional-authentication-state-providers).

Importante

L'implementazione di un personalizzato NavigationManager per ottenere la convalida dell'autenticazione durante la navigazione non è consigliata. Se l'app deve eseguire la logica dello stato di autenticazione personalizzata durante la navigazione, usare un oggetto personalizzato AuthenticationStateProvider.

Nota

Gli esempi di codice in questo articolo adottano tipi di riferimento nullable (NRT) e l'analisi statica dello stato null del compilatore .NET, supportati in ASP.NET Core in .NET 6 o versione successiva. Quando la destinazione è ASP.NET Core 5.0 o versioni precedenti, rimuovere la designazione di tipo Null (?) dagli esempi in questo articolo.

Sicurezza lato server di dati e credenziali sensibili

Negli ambienti di test/gestione temporanea e produzione, il codice lato Blazor server e le API Web devono usare flussi di autenticazione sicuri che evitano di mantenere le credenziali all'interno del codice del progetto o dei file di configurazione. Al di fuori dei test di sviluppo locali, è consigliabile evitare l'uso di variabili di ambiente per archiviare i dati sensibili, perché le variabili di ambiente non sono l'approccio più sicuro. Per i test di sviluppo locali, lo strumento Secret Manager è consigliato per proteggere i dati sensibili. Per ulteriori informazioni, vedi le seguenti risorse:

• Flussi di autenticazione sicura (documentazione di ASP.NET Core)
• Identità gestite per i servizi di Microsoft Azure (Blazor documentazione)

Per lo sviluppo e il test locali sul lato client e sul lato server, usare lo strumento Secret Manager per proteggere le credenziali sensibili.

Modello di progetto

Creare una nuova app lato Blazor server seguendo le indicazioni riportate in Strumenti per ASP.NET Core Blazor.

Visual Studio

Dopo aver scelto il modello di app sul lato server e aver configurato il progetto, selezionare l'autenticazione dell'app in Tipo di autenticazione:

• Nessuno (impostazione predefinita): nessuna autenticazione.
• Account singoli: gli account utente vengono archiviati all'interno dell'app usando ASP.NET Core Identity.

Visual Studio Code

Quando si esegue il comando dell'interfaccia della riga di comando di .NET per creare e configurare l'app sul lato Blazor server, indicare il meccanismo di autenticazione con l'opzione -au|--auth :

-au {AUTHENTICATION}

Nota

Per il comando completo, vedere Strumenti per ASP.NET Core Blazor.

I valori di autenticazione consentiti per il {AUTHENTICATION} segnaposto sono illustrati nella tabella seguente.

Meccanismo di autenticazione	Descrizione
None (predefinito)	Nessuna autenticazione
Individual	Utenti archiviati nell'app con ASP.NET Core Identity

Per altre informazioni, vedere il comando dotnet new nella guida per .NET Core.

CLI .NET

Quando si esegue il comando dell'interfaccia della riga di comando di .NET per creare e configurare l'app sul lato Blazor server, indicare il meccanismo di autenticazione con l'opzione -au|--auth :

-au {AUTHENTICATION}

Nota

Per il comando completo, vedere Strumenti per ASP.NET Core Blazor.

I valori di autenticazione consentiti per il {AUTHENTICATION} segnaposto sono illustrati nella tabella seguente.

Meccanismo di autenticazione	Descrizione
None (predefinito)	Nessuna autenticazione
Individual	Utenti archiviati nell'app con ASP.NET Core Identity

Per altre informazioni:

• Vedere il comando dotnet new nella guida per .NET Core.

• Eseguire il comando della Guida per il modello in una shell dei comandi:

  dotnet new {PROJECT TEMPLATE} --help
  

  Nel comando precedente il {PROJECT TEMPLATE} segnaposto è il modello di progetto.

BlazorIdentity Interfaccia utente (singoli account)

Blazor supporta la generazione di un'interfaccia utente completa Blazorbasata su Identity quando si sceglie l'opzione di autenticazione per singoli account.

Il Blazor Web App codice dello scaffolding del Identity modello per un database di SQL Server. La versione della riga di comando usa SQLite e include un database SQLite per Identity.

Il modello:

• Supporta scenari di rendering interattivo lato server (SSR interattivo) e di rendering lato client con utenti autenticati.
• Aggiunge IdentityRazor componenti e logica correlata per le attività di autenticazione di routine, ad esempio l'accesso e l'uscita degli utenti. I Identity componenti supportano anche funzionalità avanzate Identity , ad esempio la conferma dell'account e il ripristino delle password e l'autenticazione a più fattori usando un'app di terze parti. Si noti che i componenti stessi non supportano l'interattività Identity .
• Aggiunge i Identitypacchetti e le dipendenze correlati a .
• Fa riferimento ai Identity pacchetti in _Imports.razor.
• Crea una classe utente Identity personalizzata (ApplicationUser).
• Crea e registra un EF Core contesto di database (ApplicationDbContext).
• Configura il routing per gli endpoint predefiniti Identity .
• Include Identity la convalida e la logica di business.

Per esaminare i componenti del framework, accedervi nelle cartelle e della cartella nel modello di progetto (origine di riferimento).To inspect the framework's Identity components, access them in the Pages and Shared folders of the Account folder in the Blazor Web App project template (reference source).Blazor

Quando si scelgono le modalità di rendering Interattivo WebAssembly o Interactive Auto, il server gestisce tutte le richieste di autenticazione e autorizzazione e i Identity componenti vengono visualizzati in modo statico sul server nel Blazor Web Appprogetto principale.

Il framework fornisce un oggetto personalizzato AuthenticationStateProvider nei progetti server e client (.Client) per il flusso dello stato di autenticazione dell'utente nel browser. Il progetto server chiama AddAuthenticationStateSerialization, mentre il progetto client chiama AddAuthenticationStateDeserialization. L'autenticazione nel server anziché nel client consente all'app di accedere allo stato di autenticazione durante la pre-esecuzione e prima dell'inizializzazione del runtime WebAssembly .NET. Le implementazioni personalizzate AuthenticationStateProvider usano il servizio Stato componente persistente (PersistentComponentState) per serializzare lo stato di autenticazione nei commenti HTML e quindi leggerlo di nuovo da WebAssembly per creare una nuova AuthenticationState istanza. Per altre informazioni, vedere la sezione Gestire lo stato di autenticazione in Blazor Web Apps .

Solo per le soluzioni Interactive Server, IdentityRevalidatingAuthenticationStateProvider (origine di riferimento) è un lato AuthenticationStateProvider server che riconvalida il timbro di sicurezza per l'utente connesso ogni 30 minuti viene connesso un circuito interattivo.

BlazorIdentity dipende dalle DbContext istanze non create da una factory, che è intenzionale perché DbContext è sufficiente per il rendering statico dei componenti del modello di Identity progetto senza supportare l'interattività.

Per una descrizione del modo in cui le modalità di rendering interattive globali vengono applicate aIdentity componenti diversi dall'applicazione contemporaneamente di SSR statico per i Identity componenti, vedere ASP.NET modalità di rendering coreBlazor.

Per altre informazioni sulla persistenza dello stato prerenderato, vedere Prerender ASP.NET Componenti principaliRazor.

Nota

I collegamenti della documentazione all'origine del riferimento .NET in genere caricano il ramo predefinito del repository, che rappresenta lo sviluppo corrente per la versione successiva di .NET. Per selezionare un tag per una versione specifica, usare l'elenco a discesa Switch branches or tags. Per altre informazioni, vedere How to select a version tag of ASP.NET Core source code (dotnet/AspNetCore.Docs #26205) (Come selezionare un tag di versione del codice sorgente di ASP.NET - dotnet/AspNetCore.Docs #26205).

Gestire lo stato di autenticazione in Blazor Web Apps

Questa sezione si applica agli Blazor Web Appelementi che adottano:

• Singoli account
• Rendering lato client (CSR, interattività basata su WebAssembly).

Un provider di stato di autenticazione lato client viene usato solo all'interno Blazor di e non è integrato con il sistema di autenticazione ASP.NET Core. Durante la pre-esecuzione, Blazor rispetta i metadati definiti nella pagina e usa il sistema di autenticazione ASP.NET Core per determinare se l'utente è autenticato. Quando un utente passa da una pagina a un'altra, viene usato un provider di autenticazione lato client. Quando l'utente aggiorna la pagina (ricaricamento a pagina intera), il provider di stato di autenticazione lato client non è coinvolto nella decisione di autenticazione sul server. Poiché lo stato dell'utente non è persistente dal server, qualsiasi stato di autenticazione gestito sul lato client viene perso.

Per risolvere questo problema, l'approccio migliore consiste nell'eseguire l'autenticazione all'interno del sistema di autenticazione principale ASP.NET. Il provider di stato di autenticazione lato client si occupa solo di riflettere lo stato di autenticazione dell'utente. Gli esempi di come eseguire questa operazione con i provider di stato di autenticazione sono illustrati dal Blazor Web App modello di progetto e descritti di seguito.

Nel file del Program progetto server chiamare AddAuthenticationStateSerialization, che serializza l'oggetto AuthenticationState restituito dal lato AuthenticationStateProvider server usando il servizio Stato componente persistente (PersistentComponentState):

builder.Services.AddRazorComponents()
    .AddInteractiveWebAssemblyComponents()
    .AddAuthenticationStateSerialization();

L'API serializza solo il nome lato server e le attestazioni del ruolo per l'accesso nel browser. Per includere tutte le attestazioni, impostare su SerializeAllClaims true nella chiamata sul lato server a AddAuthenticationStateSerialization:

builder.Services.AddRazorComponents()
    .AddInteractiveWebAssemblyComponents()
    .AddAuthenticationStateSerialization(
        options => options.SerializeAllClaims = true);

Nel file del progetto client (.Client) chiamare AddAuthenticationStateDeserialization, che aggiunge un oggetto AuthenticationStateProvider in cui AuthenticationState viene deserializzato dal server tramite AuthenticationStateData e il servizio Stato componente persistente (PersistentComponentState).Program Deve essere presente una chiamata corrispondente a AddAuthenticationStateSerialization nel progetto server.

builder.Services.AddAuthorizationCore();
builder.Services.AddCascadingAuthenticationState();
builder.Services.AddAuthenticationStateDeserialization();

Attestazioni e token aggiuntivi da provider esterni

Per archiviare attestazioni aggiuntive da provider esterni, vedere Rendere persistenti attestazioni e token aggiuntivi da provider esterni in ASP.NET Core.

Servizio app di Azure in Linux con Identity Server

Specificare l'autorità emittente in modo esplicito durante la distribuzione in Servizio app di Azure in Linux con Identity Server. Per altre informazioni, vedere Usare Identity per proteggere un back-end dell'API Web per le applicazioni a pagina singola.

AuthenticationStateProvider Inserimento per i servizi con ambito a un componente

Non tentare di risolvere AuthenticationStateProvider all'interno di un servizio con ambito un componente perché OwningComponentBase comporta la creazione di una nuova istanza di AuthenticationStateProvider che non è inizializzata correttamente.

Per accedere all'oggetto AuthenticationStateProvider all'interno di un servizio con ambito a un componente, inserire AuthenticationStateProvider direttamente nel componente e passare l'istanza del servizio al servizio con ambito come parametro. Questo approccio garantisce che venga usata l'istanza corretta e inizializzata di per ogni istanza dell'app AuthenticationStateProvider utente.

ExampleService.cs:

public class ExampleService
{
    public async Task<string> ExampleMethod(AuthenticationStateProvider authStateProvider)
    {
        var authState = await authStateProvider.GetAuthenticationStateAsync();
        var user = authState.User;

        if (user.Identity is not null && user.Identity.IsAuthenticated)
        {
            return $"{user.Identity.Name} is authenticated.";
        }
        else
        {
            return "The user is NOT authenticated.";
        }
    }
}

Nel file l'oggetto Program ExampleService viene registrato come servizio con ambito. In questo esempio il servizio ha come ambito un componente con OwningComponentBase. Per indicazioni generali sulla durata dei servizi con ambito, vedere Inserimento delle dipendenze in ASP.NET Core.

.AddScoped<ExampleService>();

Nel componente InjectAuthStateProvider seguente:

• Il componente eredita OwningComponentBase.
• L'oggetto AuthenticationStateProvider viene inserito e passato a ExampleService.ExampleMethod.
• ExampleService viene risolto con OwningComponentBase.ScopedServices e GetRequiredService, che restituisce l'istanza inizializzata corretta di ExampleService che esiste per la durata del circuito dell'utente.

InjectAuthStateProvider.razor:

@page "/inject-auth-state-provider"
@inherits OwningComponentBase
@inject AuthenticationStateProvider AuthenticationStateProvider

<h1>Inject <code>AuthenticationStateProvider</code> Example</h1>

<p>@message</p>

@code {
    private string? message;
    private ExampleService? ExampleService { get; set; }

    protected override async Task OnInitializedAsync()
    {
        ExampleService = ScopedServices.GetRequiredService<ExampleService>();

        message = await ExampleService.ExampleMethod(AuthenticationStateProvider);
    }
}

Per altre informazioni, vedere le indicazioni su OwningComponentBase in ASP.NET Blazor core dependency injection.

Visualizzazione di contenuto non autorizzato durante la pre-gestione con un oggetto personalizzato AuthenticationStateProvider

Per evitare di visualizzare contenuto non autorizzato, ad esempio contenuto in un componente, durante la pre-gestione con un oggetto personalizzatoAuthenticationStateProvider, adottare uno degli approcci seguenti:AuthorizeView

• Implementare IHostEnvironmentAuthenticationStateProvider per l'oggetto personalizzato AuthenticationStateProvider per supportare la prerendering: per un'implementazione di esempio di IHostEnvironmentAuthenticationStateProvider, vedere l'implementazione Blazor del ServerAuthenticationStateProvider framework in ServerAuthenticationStateProvider.cs (origine di riferimento).

  Nota

  I collegamenti della documentazione all'origine del riferimento .NET in genere caricano il ramo predefinito del repository, che rappresenta lo sviluppo corrente per la versione successiva di .NET. Per selezionare un tag per una versione specifica, usare l'elenco a discesa Switch branches or tags. Per altre informazioni, vedere How to select a version tag of ASP.NET Core source code (dotnet/AspNetCore.Docs #26205) (Come selezionare un tag di versione del codice sorgente di ASP.NET - dotnet/AspNetCore.Docs #26205).

• Disabilita prerendering: indicare la modalità di rendering con il prerender parametro impostato su false al componente di livello più alto nella gerarchia dei componenti dell'app che non è un componente radice.

  Nota

  Rendere interattivo un componente radice, ad esempio il App componente, non è supportato. Di conseguenza, il prerendering non può essere disabilitato direttamente dal App componente.

  Per le app basate sul modello di Blazor Web App progetto, il prerendering viene in genere disabilitato in cui il Routes componente viene usato nel App componente (Components/App.razor) :

  <Routes @rendermode="new InteractiveServerRenderMode(prerender: false)" />
  

  Disabilitare anche la prerendering per il HeadOutlet componente:

  <HeadOutlet @rendermode="new InteractiveServerRenderMode(prerender: false)" />
  

  È anche possibile controllare in modo selettivo la modalità di rendering applicata all'istanza del Routes componente. Ad esempio, vedere ASP.NET modalità di rendering coreBlazor.

• Autenticare l'utente nel server prima dell'avvio dell'app: per adottare questo approccio, l'app deve rispondere alla richiesta iniziale di un utente con la pagina o la Identityvisualizzazione di accesso basata su e impedire le richieste agli endpoint fino a Blazor quando non vengono autenticate. Per altre informazioni, vedere Creare un'app ASP.NET Core con i dati utente protetti dall'autorizzazione. Dopo l'autenticazione, il contenuto non autorizzato nei componenti prerenderati Razor viene visualizzato solo quando l'utente non è realmente autorizzato a visualizzare il contenuto.

Gestione dello stato utente

Nonostante la parola "state" nel nome, AuthenticationStateProvider non è per l'archiviazione dello stato utente generale. AuthenticationStateProvider indica solo lo stato di autenticazione dell'utente all'app, se hanno eseguito l'accesso all'app e chi ha eseguito l'accesso.

L'autenticazione usa la stessa autenticazione ASP.NET Core Identity delle Razor app Pages e MVC. Lo stato utente archiviato per i flussi ASP.NET Core Identity a Blazor senza aggiungere codice aggiuntivo all'app. Seguire le indicazioni riportate negli articoli e nelle esercitazioni di base di ASP.NET Identity per rendere effettive le Identity funzionalità nelle Blazor parti dell'app.

Per indicazioni sulla gestione generale dello stato all'esterno di ASP.NET CoreIdentity, vedere ASP.NET Gestione dello stato coreBlazor.

Provider di stato di autenticazione aggiuntivi

Due classi aggiuntive derivate dalla AuthenticationStateProvider Guida per la gestione dello stato di autenticazione nel server:

• ServerAuthenticationStateProvider (origine di riferimento): impostazione predefinita AuthenticationStateProvider usata dal Blazor framework per gestire lo stato di autenticazione nel server quando un provider più specifico non è registrato.

• RevalidatingServerAuthenticationStateProvider (origine di riferimento): classe di base per AuthenticationStateProvider i servizi che ricevono uno stato di autenticazione dall'ambiente host e riconvalidano a intervalli regolari. Vedere il modello di Blazor Web App progetto per un'implementazione di esempio. Eseguire l'override RevalidationInterval per modificare l'intervallo di riconvalida di 30 minuti predefinito.

Nota

I collegamenti della documentazione all'origine del riferimento .NET in genere caricano il ramo predefinito del repository, che rappresenta lo sviluppo corrente per la versione successiva di .NET. Per selezionare un tag per una versione specifica, usare l'elenco a discesa Switch branches or tags. Per altre informazioni, vedere How to select a version tag of ASP.NET Core source code (dotnet/AspNetCore.Docs #26205) (Come selezionare un tag di versione del codice sorgente di ASP.NET - dotnet/AspNetCore.Docs #26205).

Gestione dello stato di autenticazione alla disconnessa

Il lato Blazor server mantiene lo stato di autenticazione utente per la durata del circuito, incluse le schede del browser. Per disconnettere in modo proattivo un utente tra le schede del browser quando l'utente si disconnette in una scheda, è necessario implementare un'origine RevalidatingServerAuthenticationStateProviderdi riferimento con un breve RevalidationInterval.

Nota

I collegamenti della documentazione all'origine del riferimento .NET in genere caricano il ramo predefinito del repository, che rappresenta lo sviluppo corrente per la versione successiva di .NET. Per selezionare un tag per una versione specifica, usare l'elenco a discesa Switch branches or tags. Per altre informazioni, vedere How to select a version tag of ASP.NET Core source code (dotnet/AspNetCore.Docs #26205) (Come selezionare un tag di versione del codice sorgente di ASP.NET - dotnet/AspNetCore.Docs #26205).

Durata della validità dell'URL di reindirizzamento temporaneo

Questa sezione si applica a Blazor Web Apps.

Usare l'opzione RazorComponentsServiceOptions.TemporaryRedirectionUrlValidityDuration per ottenere o impostare la durata di ASP.NET validità di Core Data Protection per gli URL di reindirizzamento temporanei generati dal Blazor rendering lato server. Questi vengono usati solo temporaneamente, quindi la durata deve essere sufficiente per consentire a un client di ricevere l'URL e iniziare a spostarsi. Tuttavia, dovrebbe anche essere abbastanza lungo per consentire l'asimmetria dell'orologio tra i server. Il valore predefinito è cinque minuti.

Nell'esempio seguente il valore viene esteso a sette minuti:

builder.Services.AddRazorComponents(options => 
    options.TemporaryRedirectionUrlValidityDuration = 
        TimeSpan.FromMinutes(7));

Risorse aggiuntive

• Avvio rapido: aggiungere l'accesso con Microsoft a un'app Web ASP.NET Core
• Guida introduttiva: Proteggere un'API Web ASP.NET Core con la piattaforma Microsoft identity
• Configurare ASP.NET Core per l'uso con server proxy e servizi di bilanciamento del carico: include indicazioni su:
  • Uso del middleware delle intestazioni inoltrate per mantenere le informazioni sullo schema HTTPS tra server proxy e reti interne.
  • Altri scenari e casi d'uso, tra cui la configurazione manuale dello schema, le modifiche del percorso della richiesta per il routing corretto delle richieste e l'inoltro dello schema delle richieste per i proxy inversi Linux e non IIS.