Autorizzazione basata sui ruoli in ASP.NET Core

Quando l'identità di un utente viene creata dopo l'autenticazione, l'utente può appartenere a uno o più ruoli, riflettendo varie autorizzazioni che l'utente deve accedere ai dati ed eseguire operazioni. Ad esempio, Tracy può appartenere ai ruoli "Amministratore" e "Utente" con accesso alle pagine Web amministrative nell'app, mentre Scott può appartenere solo al ruolo "Utente" e non avere accesso a dati o operazioni amministrative. La modalità di creazione e gestione di questi ruoli dipende dall'archivio di backup del processo di autorizzazione. I ruoli vengono esposti allo sviluppatore tramite ClaimsPrincipal.IsInRole. AddRoles deve essere chiamato per aggiungere servizi di ruolo durante la configurazione del sistema di identità dell'app.

Mentre i ruoli sono attestazioni, non tutte le attestazioni sono ruoli. A seconda dell'identità emittente, un ruolo può essere una raccolta di utenti che possono avere dichiarazioni per i membri del gruppo, nonché una dichiarazione effettiva sull'identità. Tuttavia, le attestazioni devono essere informazioni su un singolo utente. L'uso dei ruoli per aggiungere attestazioni a un utente può confondere il limite tra l'utente e le singole attestazioni. Questa confusione è il motivo per cui i modelli di applicazione a pagina singola non sono progettati per i ruoli. Inoltre, per le organizzazioni che eseguono la migrazione da un sistema legacy locale, la proliferazione dei ruoli negli anni può significare che un'attestazione di ruolo può essere troppo grande per essere contenuta all'interno di un token utilizzabile da una SPA (Single Page Application). Per proteggere le applicazioni a pagina singola, vedere Usare Identity per proteggere un back-end dell'API Web per le applicazioni a pagina singola.

Questo articolo usa BlazorRazor esempi di componenti e si concentra sugli Blazor scenari di autorizzazione. Per altre Blazor indicazioni, vedere le risorse seguenti:

• Autenticazione e autorizzazione per ASP.NET Core Blazor
• ASP.NET Core Blazor WebAssembly con gruppi e ruoli di Microsoft Entra ID

Per Razor le linee guida su Pages e MVC, che si applica a tutte le versioni di rilascio di ASP.NET Core, vedere le risorse seguenti:

• Autorizzazione basata sui ruoli in ASP.NET pagine principali Razor
• Autorizzazione basata sui ruoli in ASP.NET Core MVC

Esempio di app

L'esempio Blazor Web App per questo articolo è l'appBlazorWebAppRolesWithIdentity di esempio (dotnet/AspNetCore.Docs.Samples repository GitHub) (come scaricare). L'app di esempio utilizza account predefiniti con ruoli preconfigurati per dimostrare la maggior parte degli esempi in questo articolo. Per altre informazioni, vedere il file README dell'esempio (README.md).

Attenzione

Questa app di esempio usa un database in memoria per archiviare le informazioni utente, che non sono adatte per gli scenari di produzione. L'app di esempio è destinata solo a scopi dimostrativi e non deve essere usata come punto di partenza per le app di produzione.

Aggiungere servizi di ruolo a Identity

Registrare i servizi di autorizzazione basati sui ruoli nel file Program passando il tipo di ruolo a AddRoles nella configurazione Identity dell'app. Il tipo di ruolo nell'esempio seguente è IdentityRole:

builder.Services.AddDefaultIdentity<IdentityUser>( ... )
    .AddRoles<IdentityRole>()
    ...

Il codice precedente richiede il Microsoft.AspNetCore.Identity.UI pacchetto NuGet e una using direttiva per Microsoft.AspNetCore.Identity.

Nei casi in cui l'app acquisisce un controllo granulare per costruire Identity manualmente, chiamare AddRoles su AddIdentityCore:

builder.Services.AddIdentityCore<IdentityUser>()
    .AddRoles<IdentityRole>()
    ...

Controlli di autorizzazione basati sui ruoli

Controlli di autorizzazione basati sui ruoli:

• Sono dichiarativi e specificano i ruoli di cui l'utente corrente deve essere membro per accedere alla risorsa richiesta.
• Vengono applicati ai Razor componenti (esempi in questo articolo), Razor pagine o controller o azioni MVC all'interno di un controller.

Il componente AuthorizeView supporta l'autorizzazione basata sui ruoli. Questa sezione illustra i concetti di base. Per una copertura completa, vedere ASP.NET Autenticazione e autorizzazione di baseBlazor.

Per l'autorizzazione basata sui ruoli del contenuto nei componenti Razor, usare il parametro AuthorizeView.Roles.

Nell'esempio seguente :

• L'utente deve avere un'attestazione del ruolo per il ruolo Admin o SuperUser per visualizzare il contenuto del primo componente AuthorizeView.
• Per richiedere le attestazioni di ruolo sia di Admin che di SuperUser, il secondo esempio annida i componenti AuthorizeView.

Pages/RoleChecksWithAuthorizeView.razor:

@page "/role-checks-with-authorizeview"

<h3>Role Checks with AuthorizeView</h3>

<AuthorizeView Roles="Admin, SuperUser">
    <p>User: @context.User.Identity?.Name</p>
    <p>You have an 'Admin' or 'SuperUser' role claim.</p>
</AuthorizeView>

<AuthorizeView Roles="Admin">
    <p>User: @context.User.Identity?.Name</p>
    <p>You have the 'Admin' role claim.</p>
    <AuthorizeView Roles="SuperUser" Context="innerContext">
        <p>User: @innerContext.User.Identity?.Name</p>
        <p>You have both 'Admin' and 'SuperUser' role claims.</p>
    </AuthorizeView>
</AuthorizeView>

Il codice precedente stabilisce un oggetto Context per il componente interno AuthorizeView per evitare un AuthenticationState conflitto di contesto. Il contesto AuthenticationState viene acceduto all'esterno AuthorizeView con l'approccio standard per accedere al contesto (@context.User). Il contesto viene acceduto nel AuthorizeView interno con il contesto denominato innerContext (@innerContext.User).

L'attributo supporta l'autorizzazione [Authorize] basata su ruoli per l'intero Razor componente. Usare il parametro AuthorizeAttribute.Roles. Il codice seguente limita l'accesso dei componenti agli utenti membri del Admin ruolo.

Pages/RequireAdminRoleWithAuthorizeAttribute.razor:

@page "/require-admin-role-with-authorize-attribute"
@using Microsoft.AspNetCore.Authorization
@attribute [Authorize(Roles = "Admin")]

<h1>Require 'Admin' role with [Authorize] attribute</h1>

<p>You can only see this if you're in the 'Admin' role.</p>

È possibile specificare più ruoli come elenco delimitato da virgole. Nell'esempio seguente l'accesso è limitato agli utenti membri del Admin ruolo o del SuperUser ruolo.

Pages/RequireAdminOrSuperUserRoleWithAuthorizeAttribute.razor:

@page "/require-admin-or-superuser-role-with-authorize-attribute"
@using Microsoft.AspNetCore.Authorization
@attribute [Authorize(Roles = "Admin, SuperUser")]

<h1>Require 'Admin' or 'SuperUser' role with [Authorize] attribute</h1>

<p>
    You can only see this if you're in the 'Admin' role or the 'SuperUser' role.
</p>

Quando vengono applicati più attributi, l'utente deve essere membro di tutti i ruoli specificati. L'esempio seguente richiede entrambi iAdmin ruolieSuperUser .

Pages/RequireAdminAndSuperUserRolesWithAuthorizeAttributes.razor:

@page "/require-admin-and-superuser-roles-with-authorize-attributes"
@using Microsoft.AspNetCore.Authorization
@attribute [Authorize(Roles = "Admin")]
@attribute [Authorize(Roles = "SuperUser")]

<h1>Require 'Admin' and 'SuperUser' roles with [Authorize] attributes</h1>

<p>
    You can only see this if you're in both the 'Admin' role 
    and the 'SuperUser' role.
</p>

La corrispondenza dei ruoli è in genere sensibile alle maiuscole e minuscole perché i nomi dei ruoli vengono archiviati e confrontati utilizzando i confronti di stringhe di .NET. Ad esempio, Admin (maiuscolo A) non viene considerato come lo stesso ruolo di admin (minuscolo a). Per altre informazioni, vedere Autorizzazione basata sulle attestazioni in ASP.NET Core.

Controlli di autorizzazione basati su criteri

I requisiti dei ruoli possono essere espressi usando la sintassi dei criteri, in cui l'app registra un criterio all'avvio come parte della configurazione del servizio di autorizzazione.

Nell'esempio seguente :

• La RequireAdminRole politica specifica che gli utenti devono essere nel ruolo Admin.
• La RequireSuperUserRole politica specifica che gli utenti devono essere nel ruolo di SuperUser.

builder.Services.AddAuthorizationBuilder()
    .AddPolicy("RequireAdminRole",
         policy => policy.RequireRole("Admin"))
    .AddPolicy("RequireSuperUserRole",
         policy => policy.RequireRole("SuperUser"));

Per l'autorizzazione basata su criteri usando un AuthorizeView componente, usare il AuthorizeView.Policy parametro con un singolo nome di criteri.

Pages/PassRequireAdminRolePolicy.razor:

@page "/pass-requireadminrole-policy-with-authorizeview"

<h1>Pass 'RequireAdminRole' policy with AuthorizeView</h1>

<AuthorizeView Policy="RequireAdminRole">
    <p>You satisfy the 'RequireAdminRole' policy.</p>
</AuthorizeView>

Per gestire il caso in cui l'utente deve soddisfare uno dei diversi criteri, creare un criterio che conferma che l'utente soddisfi altri criteri.

Per gestire il caso in cui l'utente deve soddisfare contemporaneamente diversi criteri, adottare uno degli approcci seguenti:

• Creare un criterio per AuthorizeView che conferma che l'utente soddisfi diversi altri criteri.

• Annidare i criteri in più AuthorizeView componenti.

  Pages/PassRequireAdminRoleAndRequireSuperUserRolePoliciesWithAuthorizeViews.razor:

  @page "/pass-requireadminrole-and-requiresuperuserrole-policies-with-authorizeviews"
  
  <h1>
      Pass 'RequireAdminRole' and 'RequireSuperUserRole' policies with AuthorizeViews
  </h1>
  
  <AuthorizeView Policy="RequireAdminRole">
      <AuthorizeView Policy="RequireSuperUserRole" Context="innerContext">
          <p>
              You satisfy the 'RequireAdminRole' and 
              'RequireSuperUserRole' policies.
          </p>
      </AuthorizeView>
  </AuthorizeView>
  

Se Roles e Policy sono impostati, l'autorizzazione ha esito positivo solo quando entrambe le condizioni vengono soddisfatte. Ovvero, l'utente deve appartenere ad almeno uno dei ruoli specificati e soddisfare i requisiti definiti dai criteri.

Se non viene specificato né Roles né Policy , AuthorizeView usa i criteri predefiniti:

• Gli utenti autenticati (connessi) sono autorizzati.
• Gli utenti non autenticati (non collegati) non sono autorizzati.

A differenza della corrispondenza dei ruoli, che in genere fa distinzione tra maiuscole e minuscole, la ricerca del nome dei criteri di ASP.NET Core non fa distinzione tra maiuscole e minuscole, e RequireAdminRole e requireadminrole si riferiscono allo stesso criterio.

I criteri vengono applicati a un intero Razor componente utilizzando la proprietà Policy sull'attributo [Authorize].

Pages/PassRequireAdminRolePolicyWithAuthorizeAttribute.razor:

@page "/pass-requireadminrole-policy-with-authorize-attribute"
@using Microsoft.AspNetCore.Authorization
@attribute [Authorize(Policy = "RequireAdminRole")]

<h1>Pass RequireAdminRole policy with [Authorize] attribute</h1>

<p>You can only see this if the 'RequireAdminRole' policy is satisfied.</p>

Per specificare più ruoli consentiti in un requisito, specificare i ruoli come parametri per il RequireRole metodo . Nell'esempio seguente gli utenti sono autorizzati se appartengono a uno dei ruoli AdminoSuperUser:

builder.Services.AddAuthorizationBuilder()
    .AddPolicy("ElevatedRights", policy =>
        policy.RequireRole("Admin", "SuperUser"));

Se si vuole che i criteri richiedano tutti i ruoli precedenti, concatenare i ruoli al generatore di criteri o specificarli singolarmente nel generatore di criteri in un'istruzione lambda.

Concatenato al generatore di criteri:

builder.Services.AddAuthorizationBuilder()
    .AddPolicy("ElevatedRights", policy => 
        policy
            .RequireRole("Admin")
            .RequireRole("SuperUser"));

In alternativa, usare un'istruzione lambda:

builder.Services.AddAuthorizationBuilder()
    .AddPolicy("ElevatedRights",
        policy =>
        {
            policy.RequireRole("Admin");
            policy.RequireRole("SuperUser");
        });

Gruppi di sicurezza dell'Autenticazione di Windows come ruoli applicativi

Dopo aver configurato l'app per l'autenticazione di Windows (Blazorlinee guida specifiche) con i computer client e server appartenenti allo stesso dominio di Windows, i gruppi di sicurezza utente vengono automaticamente inclusi come claim nell'oggetto dell'utente ClaimsPrincipal.

Il User.Identity è tipicamente un WindowsIdentity quando si usa l'autenticazione di Windows ed è possibile recuperare i reclami del gruppo SID o verificare se un utente appartiene a un ruolo con il codice seguente, dove il {DOMAIN} segnaposto è il dominio e {SID GROUP NAME} il nome del gruppo SID:

if (User.Identity is WindowsIdentity windowsIdentity)
{
    var groups = windowsIdentity.Groups;

    // If needed, obtain a list of the SID groups
    var securityGroups = 
        groups.Select(g => g.Translate(typeof(NTAccount)).ToString()).ToList();

    // If needed, obtain the user's Windows identity name
    var windowsIdentityName = windowsIdentity.Name;

    // Check if the user is in a specific SID group
    if (User.IsInRole(@"{DOMAIN}\{SID GROUP NAME}"))
    {
        // User is in the specified group
    }
    else
    {
        // User isn't in the specified group
    }
}
else
{
    // The user isn't authenticated with Windows Authentication
}

Per una dimostrazione del codice correlato che converte le richieste di gruppo SID in valori leggibili da esseri umani in un'app Blazor, vedere il componente UserClaims in Proteggere un ASP.NET Core Blazor Web App con l'autenticazione di Windows. Questo approccio nel recupero delle attestazioni di gruppo SID può essere combinato con l'aggiunta di attestazioni con un IClaimsTransformation per creare attestazioni di ruolo personalizzate quando un utente viene autenticato.

Risorse aggiuntive

• Autenticazione e autorizzazione per ASP.NET Core Blazor
• ASP.NET Core Blazor WebAssembly con gruppi e ruoli di Microsoft Entra ID
• Autorizzazione basata sui ruoli in ASP.NET Core PagesRazor
• Autorizzazione basata sui ruoli in ASP.NET Core MVC
• Estendere o aggiungere attestazioni personalizzate, incluse le attestazioni di ruolo, usando IClaimsTransformation