Autenticazione e autorizzazione per ASP.NET Core Blazor

Se l'imposizione delle regole di autorizzazione deve essere garantita, non implementare i controlli di autorizzazione nel codice lato client. Compilare un oggetto Blazor Web App che si basa solo sul rendering lato server (SSR) per i controlli di autorizzazione e l'imposizione delle regole.

Se l'imposizione delle regole di autorizzazione e la sicurezza dei dati e del codice devono essere garantiti, non sviluppare un'app sul lato client. Creare un'app Blazor Server .

ASP.NET Core Identity è progettato per funzionare nel contesto della comunicazione di richiesta e risposta HTTP, che in genere non è il modello di comunicazione client-server dell'app Blazor . Le app ASP.NET Core che usano ASP.NET Core Identity per la gestione utenti devono usare Razor Pages anziché componenti Razor per l'interfaccia utente correlata a Identity, ad esempio registrazione utente, accesso, disconnessione e altre attività di gestione utenti. La compilazione di Razor componenti che gestiscono Identity direttamente le attività è possibile per diversi scenari, ma non è consigliata o supportata da Microsoft.

Le astrazioni ASP.NET Core, come SignInManager<TUser> e UserManager<TUser>, non sono supportate nei componenti Razor. Per altre informazioni sull'uso di ASP.NET Core Identity con , vedere Blazor lato Identity server.Blazor

Supporto antiforgerato

Il Blazor modello:

• Aggiunge automaticamente i servizi antiforgery quando AddRazorComponents viene chiamato nel Program file.
• Aggiunge il middleware antiforgery chiamando UseAntiforgery nella pipeline di elaborazione delle richieste nel Program file e richiede la protezione antiforgery degli endpoint per attenuare le minacce della richiesta cross-site forgery (CSRF/XSRF). UseAntiforgery viene chiamato dopo UseHttpsRedirection. Una chiamata a UseAntiforgery deve essere effettuata dopo le chiamate, se presenti, a UseAuthentication e UseAuthorization.

Il componente esegue il AntiforgeryToken rendering di un token antiforgery come campo nascosto e questo componente viene aggiunto automaticamente alle istanze del modulo (EditForm). Per altre informazioni, vedere Blazor dei moduli principali.

Il AntiforgeryStateProvider servizio fornisce l'accesso a un token antiforgery associato alla sessione corrente. Inserire il servizio e chiamare il GetAntiforgeryToken() relativo metodo per ottenere l'oggetto corrente AntiforgeryRequestToken. Per altre informazioni, vedere Blazor ASP.NET Core.

Blazor archivia i token di richiesta nello stato del componente, che garantisce che i token antiforgery siano disponibili per i componenti interattivi, anche quando non hanno accesso alla richiesta.

Per ulteriori informazioni, vedi le seguenti risorse:

• Evitare attacchi XSRF/CSRF (Cross-Site Request Forgery) in ASP.NET Core: questo articolo è l'articolo principale ASP.NET Core sull'argomento, che si applica a lato Blazor Serverserver, al progetto server di Blazor Web Apps e Blazor all'integrazione con MVC/Razor Pages.
• Blazor dei moduli di base: la sezione supporto antiforgery dell'articolo riguarda i Blazor moduli di supporto antiforgery.

In genere, IHttpContextAccessor dovrebbe essere evitato con il rendering interattivo perché un valido HttpContext non è sempre disponibile.

IHttpContextAccessor può essere usato per i componenti di cui viene eseguito il rendering statico nel server. Tuttavia, è consigliabile evitarlo, se possibile.

HttpContext può essere usato come parametro a catena solo nei componenti radice sottoposti a rendering statico per attività generali, ad esempio l'ispezione e la modifica di intestazioni o altre proprietà nel App componente (Components/App.razor). Il valore è sempre null per il rendering interattivo.

[CascadingParameter]
public HttpContext? HttpContext { get; set; }

Per gli scenari in cui HttpContext è necessario nei componenti interattivi, è consigliabile fluire i dati tramite lo stato del componente persistente dal server. Per altre informazioni, vedere ASP.NET core server-side e Blazor Web App altri scenari di sicurezza.

Non usare IHttpContextAccessor/HttpContext direttamente o indirettamente nei Razor componenti delle app lato Blazor server. Blazor le app vengono eseguite all'esterno del contesto della pipeline core ASP.NET. Non HttpContext è garantito che sia disponibile all'interno di IHttpContextAccessore HttpContext non sia garantito che contenga il contesto che ha avviato l'app Blazor .

L'approccio consigliato per passare lo stato della richiesta all'app consiste nell'usare Blazor i parametri del componente radice durante il rendering iniziale dell'app. In alternativa, l'app può copiare i dati in un servizio con ambito nell'evento del ciclo di vita di inizializzazione del componente radice da usare nell'app. Per altre informazioni, vedere ASP.NET core server-side e Blazor Web App altri scenari di sicurezza.

Un aspetto critico della sicurezza lato Blazor server è che l'utente collegato a un determinato circuito potrebbe essere aggiornato a un certo punto dopo che il Blazor circuito è stato stabilito, ma IHttpContextAccessornon viene aggiornato. Per altre informazioni sulla gestione di questa situazione con i servizi personalizzati, vedere Blazor Web App e lato server core.

Blazor Identity 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 Blazor components, access them in the Identity and Pages folders of the Shared.Account

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.

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 modello di progetto include una PersistentAuthenticationStateProvider classe (origine di riferimento) nel .Client progetto per sincronizzare lo stato di autenticazione dell'utente tra il server e il browser. La classe è un'implementazione personalizzata di AuthenticationStateProvider. Il provider usa il servizio Stato componente persistente (PersistentComponentState) per prerendere lo stato di autenticazione e salvarlo in modo permanente nella pagina.

Nel progetto principale di un , Blazor Web Appil provider di stato di autenticazione è denominato IdentityRevalidatingAuthenticationStateProvider (origine di riferimento) (solo soluzioni di interattività server) o PersistingRevalidatingAuthenticationStateProvider (origine riferimento) (WebAssembly o soluzioni di interattività automatica).

Blazor Identity 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 Blazor di rendering core.

Per altre informazioni sulla persistenza dello stato prerenderato, vedere Razor principali.

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 SerializeAllClaimstrue nella chiamata sul lato server a AddAuthenticationStateSerialization:

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

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

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

• PersistingRevalidatingAuthenticationStateProvider (origine di riferimento): per Blazor Web Apps che adottano il rendering interattivo lato server (SSR interattivo) e il rendering lato client (CSR). Si tratta di un lato AuthenticationStateProvider server che riconvalida il timbro di sicurezza per l'utente connesso ogni 30 minuti che un circuito interattivo è connesso. Usa anche il servizio Stato componente persistente per eseguire il flusso dello stato di autenticazione al client, che viene quindi corretto per la durata della richiesta di firma del certificato.

• PersistingServerAuthenticationStateProvider (origine di riferimento): per Blazor Web Apps che adotta solo CSR. Si tratta di un lato AuthenticationStateProvider server che usa il servizio Stato componente persistente per trasferire lo stato di autenticazione al client, che viene quindi risolto per la durata della richiesta di firma del certificato.

• PersistentAuthenticationStateProvider (origine di riferimento): per Blazor Web Appl'adozione di CSR. Si tratta di un lato AuthenticationStateProvider client che determina lo stato di autenticazione dell'utente cercando i dati salvati in modo permanente nella pagina quando è stato eseguito il rendering nel server. Questo stato di autenticazione è fisso per la durata della richiesta di firma del certificato. Se l'utente deve accedere o disconnettersi, è necessario ricaricare a pagina intera. Questo fornisce solo un nome utente e un messaggio di posta elettronica a scopo di visualizzazione. Non include token che eseguono l'autenticazione al server quando effettuano richieste successive, che vengono gestite separatamente usando un cookie oggetto incluso nelle HttpClient richieste al server.

Eseguire lo scaffolding di Identity

Per altre informazioni sullo scaffolding Identity in un'app lato Blazor server, vedere Scaffolding Identity nei progetti ASP.NET Core.

Eseguire lo scaffolding Identity in un'app lato Blazor server:

• Senza autorizzazione esistente.
• Con autorizzazione.

Nel file Program:

builder.Services.AddScoped<ExampleService>();

In Startup.ConfigureServices di Startup.cs:

services.AddScoped<ExampleService>();

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

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

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

• 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 Blazor di rendering core.

• Disabilita prerendering: aprire il _Host.cshtml file e modificare l'attributo dell'helperrender-modetag del componente in :Server

  <component type="typeof(App)" render-mode="Server" />
  

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

AuthenticationStateProvider è il servizio sottostante usato dal AuthorizeView componente e dai servizi di autenticazione a catena per ottenere lo stato di autenticazione per un utente.

AuthenticationStateProviderè il servizio sottostante usato dal componente e AuthorizeView dal CascadingAuthenticationState componente per ottenere lo stato di autenticazione per un utente.

@page "/claims-principal-data"
@using System.Security.Claims
@inject AuthenticationStateProvider AuthenticationStateProvider

<h1>ClaimsPrincipal Data</h1>

<button @onclick="GetClaimsPrincipalData">Get ClaimsPrincipal Data</button>

<p>@authMessage</p>

@if (claims.Any())
{
    <ul>
        @foreach (var claim in claims)
        {
            <li>@claim.Type: @claim.Value</li>
        }
    </ul>
}

<p>@surname</p>

@code {
    private string? authMessage;
    private string? surname;
    private IEnumerable<Claim> claims = Enumerable.Empty<Claim>();

    private async Task GetClaimsPrincipalData()
    {
        var authState = await AuthenticationStateProvider
            .GetAuthenticationStateAsync();
        var user = authState.User;

        if (user.Identity is not null && user.Identity.IsAuthenticated)
        {
            authMessage = $"{user.Identity.Name} is authenticated.";
            claims = user.Claims;
            surname = user.FindFirst(c => c.Type == ClaimTypes.Surname)?.Value;
        }
        else
        {
            authMessage = "The user is NOT authenticated.";
        }
    }
}

Nell'esempio precedente:

• ClaimsPrincipal.Claims restituisce le attestazioni dell'utente (claims) per la visualizzazione nell'interfaccia utente.
• Riga che ottiene il cognome dell'utente (surname) con ClaimsPrincipal.FindAll un predicato per filtrare le attestazioni dell'utente.

@page "/claims-principal-data"
@using System.Security.Claims
@inject AuthenticationStateProvider AuthenticationStateProvider

<h1>ClaimsPrincipal Data</h1>

<button @onclick="GetClaimsPrincipalData">Get ClaimsPrincipal Data</button>

<p>@authMessage</p>

@if (claims.Any())
{
    <ul>
        @foreach (var claim in claims)
        {
            <li>@claim.Type: @claim.Value</li>
        }
    </ul>
}

<p>@surname</p>

@code {
    private string? authMessage;
    private string? surname;
    private IEnumerable<Claim> claims = Enumerable.Empty<Claim>();

    private async Task GetClaimsPrincipalData()
    {
        var authState = await AuthenticationStateProvider
            .GetAuthenticationStateAsync();
        var user = authState.User;

        if (user.Identity is not null && user.Identity.IsAuthenticated)
        {
            authMessage = $"{user.Identity.Name} is authenticated.";
            claims = user.Claims;
            surname = user.FindFirst(c => c.Type == ClaimTypes.Surname)?.Value;
        }
        else
        {
            authMessage = "The user is NOT authenticated.";
        }
    }
}

@page "/cascade-auth-state"

<h1>Cascade Auth State</h1>

<p>@authMessage</p>

@code {
    private string authMessage = "The user is NOT authenticated.";

    [CascadingParameter]
    private Task<AuthenticationState>? authenticationState { get; set; }

    protected override async Task OnInitializedAsync()
    {
        if (authenticationState is not null)
        {
            var authState = await authenticationState;
            var user = authState?.User;

            if (user?.Identity is not null && user.Identity.IsAuthenticated)
            {
                authMessage = $"{user.Identity.Name} is authenticated.";
            }
        }
    }
}

@page "/cascade-auth-state"

<h1>Cascade Auth State</h1>

<p>@authMessage</p>

@code {
    private string authMessage = "The user is NOT authenticated.";

    [CascadingParameter]
    private Task<AuthenticationState>? authenticationState { get; set; }

    protected override async Task OnInitializedAsync()
    {
        if (authenticationState is not null)
        {
            var authState = await authenticationState;
            var user = authState?.User;

            if (user?.Identity is not null && user.Identity.IsAuthenticated)
            {
                authMessage = $"{user.Identity.Name} is authenticated.";
            }
        }
    }
}

Configurare il Task<AuthenticationState> parametro a catena usando i AuthorizeRouteView servizi di stato di autenticazione a catena e .

Quando si crea un'app Blazor da uno dei Blazor modelli di progetto con autenticazione abilitata, l'app include AuthorizeRouteView e la chiamata a AddCascadingAuthenticationState illustrata nell'esempio seguente. Un'app lato Blazor client include anche le registrazioni del servizio necessarie. Altre informazioni vengono visualizzate nella sezione Personalizzare il contenuto non autorizzato con il Router componente .

<Router ...>
    <Found ...>
        <AuthorizeRouteView RouteData="routeData" 
            DefaultLayout="typeof(Layout.MainLayout)" />
        ...
    </Found>
</Router>

Program Nel file registrare i servizi di stato di autenticazione a catena:

builder.Services.AddCascadingAuthenticationState();

Configurare il Task<AuthenticationState>parametro a catena usando i AuthorizeRouteView componenti e .CascadingAuthenticationState

Quando si crea un'app Blazor da uno dei Blazor modelli di progetto con autenticazione abilitata, l'app include i AuthorizeRouteView componenti e CascadingAuthenticationState illustrati nell'esempio seguente. Un'app lato Blazor client include anche le registrazioni del servizio necessarie. Altre informazioni vengono visualizzate nella sezione Personalizzare il contenuto non autorizzato con il Router componente .

<CascadingAuthenticationState>
    <Router ...>
        <Found ...>
            <AuthorizeRouteView RouteData="routeData" 
                DefaultLayout="typeof(MainLayout)" />
            ...
        </Found>
    </Router>
</CascadingAuthenticationState>

In un'app sul lato Blazor client aggiungere i servizi di autorizzazione al Program file:

builder.Services.AddAuthorizationCore();

In un'app sul lato Blazor client aggiungere opzioni e servizi di autorizzazione al Program file:

builder.Services.AddOptions();
builder.Services.AddAuthorizationCore();

Razor i componenti di Blazor Web Apps non visualizzano <NotAuthorized> mai il contenuto quando l'autorizzazione non riesce sul lato server durante il rendering statico lato server (SSR statico). Il lato server ASP.NET core pipeline elabora l'autorizzazione nel server. Usare tecniche lato server per gestire le richieste non autorizzate. Per altre informazioni, vedere Blazor di rendering core.

Autorizzazione delle risorse

Per autorizzare gli utenti per le risorse, passare i dati di route della richiesta al parametro Resource di AuthorizeRouteView.

Router.Found Nel contenuto di una route richiesta:

<AuthorizeRouteView Resource="routeData" RouteData="routeData" 
    DefaultLayout="typeof(MainLayout)" />

Per altre informazioni sul modo in cui i dati sullo stato di autorizzazione vengono passati e usati nella logica procedurale, vedere la sezione Esporre lo stato di autenticazione come parametro a catena.

Quando AuthorizeRouteView riceve i dati di route per la risorsa, i criteri di autorizzazione hanno accesso a RouteData.PageType e RouteData.RouteValues che consentono alla logica personalizzata di prendere decisioni per l'autorizzazione.

Nell'esempio seguente viene creato un criterio EditUser in AuthorizationOptions per la configurazione del servizio di autorizzazione dell'app (AddAuthorizationCore) con la logica seguente:

• Determinare se esiste un valore di route con una chiave id. Se la chiave esiste, il valore della route viene archiviato in value.
• In una variabile denominata id, archiviare value come stringa o impostare un valore stringa vuoto (string.Empty).
• Se id non è una stringa vuota, confermare che il criterio è soddisfatto (restituire true) se il valore della stringa inizia con EMP. In caso contrario, confermare che il criterio non è stato soddisfatto (restituire false).

Nel file Program:

• Aggiungere gli spazi dei nomi per Microsoft.AspNetCore.Components e System.Linq:

  using Microsoft.AspNetCore.Components;
  using System.Linq;
  

• Aggiungere il criterio:

  options.AddPolicy("EditUser", policy =>
      policy.RequireAssertion(context =>
      {
          if (context.Resource is RouteData rd)
          {
              var routeValue = rd.RouteValues.TryGetValue("id", out var value);
              var id = Convert.ToString(value, 
                  System.Globalization.CultureInfo.InvariantCulture) ?? string.Empty;
  
              if (!string.IsNullOrEmpty(id))
              {
                  return id.StartsWith("EMP", StringComparison.InvariantCulture);
              }
          }
  
          return false;
      })
  );
  

L'esempio precedente è un criterio di autorizzazione molto semplificato, usato semplicemente per una dimostrazione del concetto con un esempio funzionante. Per altre informazioni sulla creazione e la configurazione dei criteri di autorizzazione, vedere Autorizzazione basata su criteri in ASP.NET Core.

Nel componente EditUser seguente la risorsa in /users/{id}/edit ha un parametro di route per l'identificatore dell'utente ({id}). Il componente usa il criterio di autorizzazione EditUser precedente per determinare se il valore della route per id inizia con EMP. Se inizia id con EMP, il criterio è soddisfatto e l'accesso al componente viene autorizzato. Se id inizia con un valore diverso da EMP o se id è una stringa vuota, il criterio non è soddisfatto e il componente non viene caricato.

EditUser.razor:

@page "/users/{id}/edit"
@using Microsoft.AspNetCore.Authorization
@attribute [Authorize(Policy = "EditUser")]

<h1>Edit User</h1>

<p>The "EditUser" policy is satisfied! <code>Id</code> starts with 'EMP'.</p>

@code {
    [Parameter]
    public string? Id { get; set; }
}

@page "/users/{id}/edit"
@using Microsoft.AspNetCore.Authorization
@attribute [Authorize(Policy = "EditUser")]

<h1>Edit User</h1>

<p>The "EditUser" policy is satisfied! <code>Id</code> starts with 'EMP'.</p>

@code {
    [Parameter]
    public string? Id { get; set; }
}

<Router ...>
    <Found ...>
        <AuthorizeRouteView ...>
            <NotAuthorized>
                ...
            </NotAuthorized>
            <Authorizing>
                ...
            </Authorizing>
        </AuthorizeRouteView>
    </Found>
</Router>

Il contenuto di Authorized e NotAuthorized può includere elementi arbitrari, ad esempio altri componenti interattivi.

builder.Services.AddCascadingAuthenticationState();

<CascadingAuthenticationState>
    <Router ...>
        <Found ...>
            <AuthorizeRouteView ...>
                <NotAuthorized>
                    ...
                </NotAuthorized>
                <Authorizing>
                    ...
                </Authorizing>
            </AuthorizeRouteView>
        </Found>
    </Router>
</CascadingAuthenticationState>

Il contenuto di NotFound, Authorized e NotAuthorized può includere elementi arbitrari, ad esempio altri componenti interattivi.

@page "/procedural-logic"
@inject IAuthorizationService AuthorizationService

<h1>Procedural Logic Example</h1>

<button @onclick="@DoSomething">Do something important</button>

@code {
    [CascadingParameter]
    private Task<AuthenticationState>? authenticationState { get; set; }

    private async Task DoSomething()
    {
        if (authenticationState is not null)
        {
            var authState = await authenticationState;
            var user = authState?.User;

            if (user is not null)
            {
                if (user.Identity is not null && user.Identity.IsAuthenticated)
                {
                    // ...
                }

                if (user.IsInRole("Admin"))
                {
                    // ...
                }

                if ((await AuthorizationService.AuthorizeAsync(user, "content-editor"))
                    .Succeeded)
                {
                    // ...
                }
            }
        }
    }
}

@page "/procedural-logic"
@inject IAuthorizationService AuthorizationService

<h1>Procedural Logic Example</h1>

<button @onclick="@DoSomething">Do something important</button>

@code {
    [CascadingParameter]
    private Task<AuthenticationState>? authenticationState { get; set; }

    private async Task DoSomething()
    {
        if (authenticationState is not null)
        {
            var authState = await authenticationState;
            var user = authState?.User;

            if (user is not null)
            {
                if (user.Identity is not null && user.Identity.IsAuthenticated)
                {
                    // ...
                }

                if (user.IsInRole("Admin"))
                {
                    // ...
                }

                if ((await AuthorizationService.AuthorizeAsync(user, "content-editor"))
                    .Succeeded)
                {
                    // ...
                }
            }
        }
    }
}

• Risorse e Blazor Web App lato server
  • 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.
• Documentazione della piattaforma Microsoft identity
  • Sintesi
  • Protocolli OAuth 2.0 e OpenID Connect sulla piattaforma Microsoft identity
  • Flusso del codice di autorizzazione OAuth 2.0 e piattaforma Microsoft identity
  • Token ID piattaforma Microsoft identity
  • Token di accesso alla piattaforma Microsoft identity
• Argomenti sulla sicurezza di ASP.NET Core
• Configurare l'autenticazione di Windows in ASP.NET Core
• Creare una versione personalizzata della libreria JavaScript Authentication.MSAL
• Collegamenti a esempi della community Awesome Blazor: Authentication
• Autenticazione e autorizzazione per ASP.NET Core Blazor Hybrid

• Risorse lato Blazor server
  • 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.
• Documentazione della piattaforma Microsoft identity
  • Sintesi
  • Protocolli OAuth 2.0 e OpenID Connect sulla piattaforma Microsoft identity
  • Flusso del codice di autorizzazione OAuth 2.0 e piattaforma Microsoft identity
  • Token ID piattaforma Microsoft identity
  • Token di accesso alla piattaforma Microsoft identity
• Argomenti sulla sicurezza di ASP.NET Core
• Configurare l'autenticazione di Windows in ASP.NET Core
• Creare una versione personalizzata della libreria JavaScript Authentication.MSAL
• Collegamenti a esempi della community Awesome Blazor: Authentication