Condividi tramite

Informazioni sull'autorizzazione nei microservizi .NET e nelle applicazioni Web

Suggerimento

Questo contenuto è un estratto dell'eBook, Architettura di microservizi .NET per applicazioni .NET containerizzati, disponibile in documentazione .NET o come PDF scaricabile gratuitamente leggibile offline.

Scaricare il PDF

Architettura di Microservizi .NET per Applicazioni .NET Containerizzate miniatura della copertina dell'eBook.

Dopo l'autenticazione, ASP.NET API Web core devono autorizzare l'accesso. Questo processo, ad esempio, consente a un servizio di rendere le API disponibili per alcuni utenti autenticati, ma non per tutti. L'autorizzazione può essere eseguita in base ai ruoli degli utenti o in base a criteri personalizzati, che possono includere l'ispezione di attestazioni o altre euristiche.

La limitazione dell'accesso a una route MVC core ASP.NET è semplice quanto l'applicazione di un attributo Authorize al metodo di azione (o alla classe del controller se tutte le azioni del controller richiedono l'autorizzazione), come illustrato nell'esempio seguente:

public class AccountController : Controller
{
    public ActionResult Login()
    {
    }

    [Authorize]
    public ActionResult Logout()
    {
    }
}

Per impostazione predefinita, l'aggiunta di un attributo Authorize senza parametri limita l'accesso agli utenti autenticati per tale controller o azione. Per limitare ulteriormente la disponibilità di un'API solo per utenti specifici, è possibile espandere l'attributo per specificare i ruoli o i criteri necessari che gli utenti devono soddisfare.

Implementare l'autorizzazione basata sui ruoli

ASP.NET Core Identity ha un concetto predefinito di ruoli. Oltre agli utenti, ASP.NET Core Identity archivia informazioni sui diversi ruoli usati dall'applicazione e tiene traccia degli utenti assegnati ai ruoli. Queste assegnazioni possono essere modificate a livello di codice con il RoleManager tipo che aggiorna i ruoli nell'archiviazione persistente e il UserManager tipo che può concedere o revocare ruoli agli utenti.

Se si esegue l'autenticazione con token bearer JWT, il middleware di autenticazione JWT bearer di ASP.NET Core assegna i ruoli di un utente in base alle attestazioni di ruolo trovate nel token. Per limitare l'accesso a un'azione MVC o a un controller agli utenti in ruoli specifici, è possibile includere un parametro Roles nell'annotazione Authorize (attributo), come illustrato nel frammento di codice seguente:

[Authorize(Roles = "Administrator, PowerUser")]
public class ControlPanelController : Controller
{
    public ActionResult SetTime()
    {
    }

    [Authorize(Roles = "Administrator")]
    public ActionResult ShutDown()
    {
    }
}

In questo esempio, solo gli utenti nei ruoli Administrator o PowerUser possono accedere alle API nel controller ControlPanel , ad esempio l'esecuzione dell'azione SetTime. L'API ShutDown è ulteriormente limitata per consentire l'accesso solo agli utenti nel ruolo Amministratore.

Per richiedere che un utente sia in più ruoli, usare più attributi Authorize, come illustrato nell'esempio seguente:

[Authorize(Roles = "Administrator, PowerUser")]
[Authorize(Roles = "RemoteEmployee ")]
[Authorize(Policy = "CustomPolicy")]
public ActionResult API1 ()
{
}

In questo esempio, per chiamare API1, un utente deve:

  • Trovarsi nel ruolo di Amministratore o PowerUser e

  • Essere nel ruolo di RemoteEmployee e

  • Soddisfare un gestore personalizzato per l'autorizzazione CustomPolicy.

Implementare l'autorizzazione basata su criteri

È anche possibile scrivere regole di autorizzazione personalizzate usando i criteri di autorizzazione. Questa sezione offre una panoramica. Per altre informazioni, vedere il workshop di autorizzazione ASP.NET.

I criteri di autorizzazione personalizzati vengono registrati nel metodo Startup.ConfigureServices usando il metodo AddAuthorization. Questo metodo accetta un delegato che configura un parametro AuthorizationOptions.

services.AddAuthorization(options =>
{
    options.AddPolicy("AdministratorsOnly", policy =>
        policy.RequireRole("Administrator"));

    options.AddPolicy("EmployeesOnly", policy =>
        policy.RequireClaim("EmployeeNumber"));

    options.AddPolicy("Over21", policy =>
        policy.Requirements.Add(new MinimumAgeRequirement(21)));
});

Come illustrato nell'esempio, i criteri possono essere associati a diversi tipi di requisiti. Dopo aver registrato i criteri, possono essere applicati a un'azione o a un controller passando il nome del criterio come argomento Criteri dell'attributo Authorize (ad esempio) [Authorize(Policy="EmployeesOnly")]I criteri possono avere più requisiti, non solo uno (come illustrato in questi esempi).

Nell'esempio precedente la prima chiamata AddPolicy è semplicemente un modo alternativo di autorizzare in base al ruolo. Se [Authorize(Policy="AdministratorsOnly")] viene applicato a un'API, solo gli utenti nel ruolo Amministratore potranno accedervi.

La seconda AddPolicy chiamata dimostra un modo semplice per richiedere che una determinata dichiarazione debba essere presente per l'utente. Il RequireClaim metodo accetta facoltativamente anche i valori previsti per l'attestazione. Se vengono specificati valori, il requisito viene soddisfatto solo se l'utente dispone di un'attestazione del tipo corretto e di uno dei valori specificati. Se si usa il middleware di autenticazione del bearer JWT, tutte le proprietà JWT saranno disponibili come attestazioni utente.

Il criterio più interessante illustrato di seguito è nel terzo AddPolicy metodo, perché usa un requisito di autorizzazione personalizzato. Usando i requisiti di autorizzazione personalizzati, è possibile avere un notevole controllo sulla modalità di esecuzione dell'autorizzazione. Per il corretto funzionamento, è necessario implementare questi tipi:

Se l'utente soddisfa il requisito, una chiamata a context.Succeed indicherà che l'utente è autorizzato. Se esistono diversi modi in cui un utente potrebbe soddisfare un requisito di autorizzazione, è possibile creare più gestori.

Oltre a registrare i requisiti dei criteri personalizzati con chiamate AddPolicy, è necessario registrare i gestori dei requisiti personalizzati tramite iniezione delle dipendenze (services.AddTransient<IAuthorizationHandler, MinimumAgeHandler>()).

Un esempio di requisito di autorizzazione personalizzato e gestore per il controllo dell'età di un utente (in base a un'attestazione DateOfBirth ) è disponibile nella documentazione relativa all'autorizzazione ASP.NET Core.

Autorizzazione e API minime

ASP.NET supporta API minime come alternativa alle API basate su controller. I criteri di autorizzazione sono il modo consigliato per configurare l'autorizzazione per le API minime, come illustrato in questo esempio:

// Program.cs
builder.Services.AddAuthorizationBuilder()
  .AddPolicy("admin_greetings", policy =>
        policy
            .RequireRole("admin")
            .RequireScope("greetings_api"));

// build the app

app.MapGet("/hello", () => "Hello world!")
  .RequireAuthorization("admin_greetings");

Risorse aggiuntive

PrecedenteAvanti