Condividi tramite

Panoramica dell'autenticazione in ASP.NET Core

  • Articolo

Di Mike Rousos

L'autenticazione è il processo di determinazione di un utente.identity L'autorizzazione è il processo con cui si determina se un utente ha accesso a una risorsa. In ASP.NET Core l'autenticazione viene gestita dal servizio di autenticazione, IAuthenticationService, che viene usato dal middleware di autenticazione. Il servizio di autenticazione usa i gestori di autenticazione registrati per completare le azioni correlate all'autenticazione. Le azioni correlate all'autenticazione includono ad esempio:

  • Autenticazione di un utente.
  • Risposta quando un utente non autenticato tenta di accedere a una risorsa con restrizioni.

I gestori di autenticazione registrati e le relative opzioni di configurazione si definiscono "schemi".

Gli schemi di autenticazione vengono specificati registrando i servizi di autenticazione in Program.cs:

  • Tramite una chiamata a un metodo di estensione specifico dello schema dopo una chiamata a AddAuthentication, ad esempio AddJwtBearer o AddCookie. Questi metodi di estensione usano AuthenticationBuilder.AddScheme per registrare gli schemi con le impostazioni appropriate.
  • Meno comunemente, tramite una chiamata diretta a AuthenticationBuilder.AddScheme.

Ad esempio, il codice seguente registra i servizi di autenticazione e i gestori per cookie e gli schemi di autenticazione del token di connessione JWT:

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme,
        options => builder.Configuration.Bind("JwtSettings", options))
    .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme,
        options => builder.Configuration.Bind("CookieSettings", options));

Il parametro AddAuthentication JwtBearerDefaults.AuthenticationScheme è il nome dello schema da usare per impostazione predefinita quando non è richiesto uno schema specifico.

Se vengono usati più schemi, i criteri di autorizzazione (o gli attributi di autorizzazione) possono specificare uno o più schemi di autenticazione da cui dipendono per autenticare l'utente. Nell'esempio precedente lo cookie schema di autenticazione può essere usato specificando il relativo nome (CookieAuthenticationDefaults.AuthenticationScheme per impostazione predefinita, anche se è possibile specificare un nome diverso quando si chiama AddCookie).

In alcuni casi, la chiamata a AddAuthentication viene eseguita automaticamente da altri metodi di estensione. Ad esempio, quando si usa ASP.NET Core Identity, AddAuthentication viene chiamato internamente.

Il middleware di autenticazione viene aggiunto in Program.cs chiamando UseAuthentication. La chiamata a UseAuthentication registra il middleware che usa gli schemi di autenticazione registrati in precedenza. Chiamare UseAuthentication prima di qualsiasi middleware che dipende dagli utenti da autenticare.

Concetti relativi all'autenticazione

Con l'autenticazione viene fornito l'oggetto ClaimsPrincipal rispetto a cui prendere decisioni sulle autorizzazioni. Per lo schema di autenticazione sono disponibili più approcci per selezionare il gestore di autenticazione responsabile della generazione del set corretto di attestazioni:

Quando è registrato un solo schema di autenticazione, diventa lo schema predefinito. Se vengono registrati più schemi e lo schema predefinito non viene specificato, è necessario specificare uno schema nell'attributo authorize; in caso contrario, viene generato l'errore seguente:

InvalidOperationException: Non è stato specificato alcun authenticationScheme e non è stato trovato alcun DefaultAuthenticateScheme. Gli schemi predefiniti possono essere impostati usando AddAuthentication(string defaultScheme) o AddAuthentication(Action<AuthenticationOptions> configureOptions).

DefaultScheme

Quando è registrato un solo schema di autenticazione, il singolo schema di autenticazione:

Per disabilitare automaticamente l'uso dello schema di autenticazione singolo come DefaultScheme, chiamare AppContext.SetSwitch("Microsoft.AspNetCore.Authentication.SuppressAutoDefaultScheme").

Schema di autenticazione

Lo schema di autenticazione può selezionare quale gestore di autenticazione è responsabile di generare il set corretto di attestazioni. Per altre informazioni, vedere Autorizzare con uno schema specifico.

Uno schema di autenticazione è un nome che corrisponde a:

  • Gestore di autenticazione.
  • Opzioni per la configurazione di un'istanza specifica del gestore.

Gli schemi sono utili come meccanismo per autenticare, richiedere la verifica e proibire i comportamenti del gestore associato. Ad esempio, un criterio di autorizzazione può usare nomi di schema per specificare uno o più schemi di autenticazione da usare per autenticare l'utente. Quando si configura l'autenticazione, in genere si specifica lo schema di autenticazione predefinito. Lo schema predefinito viene usato a meno che una risorsa non richieda uno schema specifico. È anche possibile:

  • Specificare schemi predefiniti diversi da usare per autenticare, richiedere la verifica e proibire azioni.
  • Combinare più schemi in uno usando schemi di criteri.

Gestore di autenticazione

Un gestore di autenticazione:

In base alla configurazione dello schema di autenticazione e al contesto della richiesta in ingresso, i gestori di autenticazione:

  • Costruire AuthenticationTicket oggetti che rappresentano l'utente se l'autenticazione identity ha esito positivo.
  • Restituiscono 'nessun risultato' o 'errore' se l'autenticazione non riesce.
  • Disporre di metodi per le azioni di verifica e di proibire quando gli utenti tentano di accedere alle risorse:
    • Non sono autorizzati ad accedere (proibizione).
    • Non sono autenticati (richiesta di verifica).

Confronto tra RemoteAuthenticationHandler<TOptions> e AuthenticationHandler<TOptions>

RemoteAuthenticationHandler<TOptions> è la classe per l'autenticazione che richiede un passaggio di autenticazione remota. Al termine del passaggio di autenticazione remota, il gestore richiama l'oggetto CallbackPath che ha impostato. Il gestore completa il passaggio di autenticazione usando le informazioni passate al percorso di callback HandleRemoteAuthenticateAsync. Sia OAuth 2.0 che OIDC usano questo schema. JWT e cookie non perché possono usare direttamente l'intestazione del bearer e cookie per l'autenticazione. In questo caso il provider ospitato in remoto:

  • È il provider di autenticazione.
  • Gli esempi includono Facebook, Twitter, Google, Microsoft e qualsiasi altro provider OIDC che gestisce l'autenticazione degli utenti usando il meccanismo dei gestori.

Autentica

L'azione di autenticazione di uno schema di autenticazione è responsabile della costruzione dell'utente in base al contesto della identity richiesta. Restituisce un valore AuthenticateResult che indica se l'autenticazione ha avuto esito positivo e, in tal caso, l'utente si trova identity in un ticket di autenticazione. Vedere AuthenticateAsync. Gli esempi di autenticazione includono:

  • Uno cookie schema di identity autenticazione che costruisce l'utente dai cookie.
  • Uno schema di connessione JWT che deserializza e convalida un token di connessione JWT per costruire l'oggetto dell'utente identity.

Proposta

Una richiesta di verifica dell'autenticazione viene richiamata dall'autorizzazione quando un utente non autenticato richiede un endpoint per cui è necessaria l'autenticazione. Viene generata, ad esempio, quando un utente anonimo richiede una risorsa con restrizioni o segue un collegamento di accesso. L'autorizzazione richiama una richiesta di verifica usando gli schemi di autenticazione specificati o quello predefinito se non ne è stato specificato nessuno. Vedere ChallengeAsync. Gli esempi di richiesta di verifica dell'autenticazione includono:

  • Uno schema di autenticazione cookie che reindirizza l'utente a una pagina di accesso.
  • Uno schema di token di connessione JTW che restituisce un risultato 401 con un'intestazione www-authenticate: bearer.

Un'azione di richiesta di verifica dovrà informare l'utente sul meccanismo di autenticazione da usare per accedere alla risorsa richiesta.

Proibizione

L'azione di proibizione di uno schema di autenticazione viene chiamata dall'autorizzazione quando un utente autenticato tenta di accedere a una risorsa per cui non è autorizzato. Vedere ForbidAsync. Gli esempi di proibizione dell'autenticazione includono:

  • Uno schema di autenticazione cookie che reindirizza l'utente a una pagina che indica che l'accesso è proibito.
  • Uno schema di token di connessione JTW che restituisce un risultato 403.
  • Uno schema di autenticazione personalizzato che reindirizza a una pagina in cui l'utente può richiedere l'accesso alla risorsa.

Un'azione di proibizione può informare l'utente che:

  • È autenticato.
  • Non è autorizzato ad accedere alla risorsa richiesta.

Per informazioni sulle differenze tra la richiesta di verifica e la proibizione, vedere i collegamenti seguenti:

Provider di autenticazione per tenant

ASP.NET Core non include una soluzione predefinita per l'autenticazione multi-tenant. Anche se è possibile che i clienti ne scrivono una usando le funzionalità predefinite, è consigliabile che i clienti considerino Orchard Core, ABP Framework o Finbuckle.MultiTenant per l'autenticazione multi-tenant.

Orchard Core è:

  • Un framework di app open source, modulare e multi-tenant compilato con ASP.NET Core.
  • Un sistema di gestione dei contenuti (CMS) basato su tale framework di app.

Per un esempio di provider di autenticazione per tenant, vedere l'origine di Orchard Core.

ABP Framework supporta vari schemi architetturali, tra cui modularità, microservizi, progettazione basata su dominio e multi-tenancy. Vedere Origine del framework ABP in GitHub.

Finbuckle.MultiTenant:

  • Open source
  • Fornisce la risoluzione del tenant
  • Leggerezza
  • Fornisce l'isolamento dei dati
  • Configurare il comportamento dell'app in modo univoco per ogni tenant

Risorse aggiuntive

Di Mike Rousos

L'autenticazione è il processo di determinazione di un utente.identity L'autorizzazione è il processo con cui si determina se un utente ha accesso a una risorsa. In ASP.NET Core l'autenticazione viene gestita dal servizio di autenticazione, IAuthenticationService, che viene usato dal middleware di autenticazione. Il servizio di autenticazione usa i gestori di autenticazione registrati per completare le azioni correlate all'autenticazione. Le azioni correlate all'autenticazione includono ad esempio:

  • Autenticazione di un utente.
  • Risposta quando un utente non autenticato tenta di accedere a una risorsa con restrizioni.

I gestori di autenticazione registrati e le relative opzioni di configurazione si definiscono "schemi".

Gli schemi di autenticazione vengono specificati registrando i servizi di autenticazione in Program.cs:

  • Tramite una chiamata a un metodo di estensione specifico dello schema dopo una chiamata a AddAuthentication, ad esempio AddJwtBearer o AddCookie. Questi metodi di estensione usano AuthenticationBuilder.AddScheme per registrare gli schemi con le impostazioni appropriate.
  • Meno comunemente, tramite una chiamata diretta a AuthenticationBuilder.AddScheme.

Ad esempio, il codice seguente registra i servizi di autenticazione e i gestori per cookie e gli schemi di autenticazione del token di connessione JWT:

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme,
        options => builder.Configuration.Bind("JwtSettings", options))
    .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme,
        options => builder.Configuration.Bind("CookieSettings", options));

Il parametro AddAuthentication JwtBearerDefaults.AuthenticationScheme è il nome dello schema da usare per impostazione predefinita quando non è richiesto uno schema specifico.

Se vengono usati più schemi, i criteri di autorizzazione (o gli attributi di autorizzazione) possono specificare uno o più schemi di autenticazione da cui dipendono per autenticare l'utente. Nell'esempio precedente lo cookie schema di autenticazione può essere usato specificando il relativo nome (CookieAuthenticationDefaults.AuthenticationScheme per impostazione predefinita, anche se è possibile specificare un nome diverso quando si chiama AddCookie).

In alcuni casi, la chiamata a AddAuthentication viene eseguita automaticamente da altri metodi di estensione. Ad esempio, quando si usa ASP.NET Core Identity, AddAuthentication viene chiamato internamente.

Il middleware di autenticazione viene aggiunto in Program.cs chiamando UseAuthentication. La chiamata a UseAuthentication registra il middleware che usa gli schemi di autenticazione registrati in precedenza. Chiamare UseAuthentication prima di qualsiasi middleware che dipende dagli utenti da autenticare.

Concetti relativi all'autenticazione

Con l'autenticazione viene fornito l'oggetto ClaimsPrincipal rispetto a cui prendere decisioni sulle autorizzazioni. Per lo schema di autenticazione sono disponibili più approcci per selezionare il gestore di autenticazione responsabile della generazione del set corretto di attestazioni:

Non esiste un sondaggio automatico di schemi. Se non viene specificato lo schema predefinito, è necessario specificarlo nell'attributo authorize, altrimenti viene generato l'errore seguente:

InvalidOperationException: Non è stato specificato alcun authenticationScheme e non è stato trovato alcun DefaultAuthenticateScheme. Gli schemi predefiniti possono essere impostati usando AddAuthentication(string defaultScheme) o AddAuthentication(Action<AuthenticationOptions> configureOptions).

Schema di autenticazione

Lo schema di autenticazione può selezionare quale gestore di autenticazione è responsabile di generare il set corretto di attestazioni. Per altre informazioni, vedere Autorizzare con uno schema specifico.

Uno schema di autenticazione è un nome che corrisponde a:

  • Gestore di autenticazione.
  • Opzioni per la configurazione di un'istanza specifica del gestore.

Gli schemi sono utili come meccanismo per autenticare, richiedere la verifica e proibire i comportamenti del gestore associato. Ad esempio, un criterio di autorizzazione può usare nomi di schema per specificare uno o più schemi di autenticazione da usare per autenticare l'utente. Quando si configura l'autenticazione, in genere si specifica lo schema di autenticazione predefinito. Lo schema predefinito viene usato a meno che una risorsa non richieda uno schema specifico. È anche possibile:

  • Specificare schemi predefiniti diversi da usare per autenticare, richiedere la verifica e proibire azioni.
  • Combinare più schemi in uno usando schemi di criteri.

Gestore di autenticazione

Un gestore di autenticazione:

In base alla configurazione dello schema di autenticazione e al contesto della richiesta in ingresso, i gestori di autenticazione:

  • Costruire AuthenticationTicket oggetti che rappresentano l'utente se l'autenticazione identity ha esito positivo.
  • Restituiscono 'nessun risultato' o 'errore' se l'autenticazione non riesce.
  • Disporre di metodi per le azioni di verifica e di proibire quando gli utenti tentano di accedere alle risorse:
    • Non sono autorizzati ad accedere (proibizione).
    • Non sono autenticati (richiesta di verifica).

Confronto tra RemoteAuthenticationHandler<TOptions> e AuthenticationHandler<TOptions>

RemoteAuthenticationHandler<TOptions> è la classe per l'autenticazione che richiede un passaggio di autenticazione remota. Al termine del passaggio di autenticazione remota, il gestore richiama l'oggetto CallbackPath che ha impostato. Il gestore completa il passaggio di autenticazione usando le informazioni passate al percorso di callback HandleRemoteAuthenticateAsync. Sia OAuth 2.0 che OIDC usano questo schema. JWT e cookie non perché possono usare direttamente l'intestazione del bearer e cookie per l'autenticazione. In questo caso il provider ospitato in remoto:

  • È il provider di autenticazione.
  • Gli esempi includono Facebook, Twitter, Google, Microsoft e qualsiasi altro provider OIDC che gestisce l'autenticazione degli utenti usando il meccanismo dei gestori.

Autentica

L'azione di autenticazione di uno schema di autenticazione è responsabile della costruzione dell'utente in base al contesto della identity richiesta. Restituisce un valore AuthenticateResult che indica se l'autenticazione ha avuto esito positivo e, in tal caso, l'utente si trova identity in un ticket di autenticazione. Vedere AuthenticateAsync. Gli esempi di autenticazione includono:

  • Uno cookie schema di identity autenticazione che costruisce l'utente dai cookie.
  • Uno schema di connessione JWT che deserializza e convalida un token di connessione JWT per costruire l'oggetto dell'utente identity.

Proposta

Una richiesta di verifica dell'autenticazione viene richiamata dall'autorizzazione quando un utente non autenticato richiede un endpoint per cui è necessaria l'autenticazione. Viene generata, ad esempio, quando un utente anonimo richiede una risorsa con restrizioni o segue un collegamento di accesso. L'autorizzazione richiama una richiesta di verifica usando gli schemi di autenticazione specificati o quello predefinito se non ne è stato specificato nessuno. Vedere ChallengeAsync. Gli esempi di richiesta di verifica dell'autenticazione includono:

  • Uno schema di autenticazione cookie che reindirizza l'utente a una pagina di accesso.
  • Uno schema di token di connessione JTW che restituisce un risultato 401 con un'intestazione www-authenticate: bearer.

Un'azione di richiesta di verifica dovrà informare l'utente sul meccanismo di autenticazione da usare per accedere alla risorsa richiesta.

Proibizione

L'azione di proibizione di uno schema di autenticazione viene chiamata dall'autorizzazione quando un utente autenticato tenta di accedere a una risorsa per cui non è autorizzato. Vedere ForbidAsync. Gli esempi di proibizione dell'autenticazione includono:

  • Uno schema di autenticazione cookie che reindirizza l'utente a una pagina che indica che l'accesso è proibito.
  • Uno schema di token di connessione JTW che restituisce un risultato 403.
  • Uno schema di autenticazione personalizzato che reindirizza a una pagina in cui l'utente può richiedere l'accesso alla risorsa.

Un'azione di proibizione può informare l'utente che:

  • È autenticato.
  • Non è autorizzato ad accedere alla risorsa richiesta.

Per informazioni sulle differenze tra la richiesta di verifica e la proibizione, vedere i collegamenti seguenti:

Provider di autenticazione per tenant

ASP.NET Core non include una soluzione predefinita per l'autenticazione multi-tenant. Anche se i clienti possono scriverne una usando le funzionalità predefinite, è consigliabile usare Orchard Core o ABP Framework per l'autenticazione multi-tenant.

Orchard Core è:

  • Un framework di app open source, modulare e multi-tenant compilato con ASP.NET Core.
  • Un sistema di gestione dei contenuti (CMS) basato su tale framework di app.

Per un esempio di provider di autenticazione per tenant, vedere l'origine di Orchard Core.

ABP Framework supporta vari schemi architetturali, tra cui modularità, microservizi, progettazione basata su dominio e multi-tenancy. Vedere Origine del framework ABP in GitHub.

Risorse aggiuntive

Di Mike Rousos

L'autenticazione è il processo di determinazione di un utente.identity L'autorizzazione è il processo con cui si determina se un utente ha accesso a una risorsa. In ASP.NET Core l'autenticazione viene gestita dal servizio di autenticazione, IAuthenticationService, che viene usato dal middleware di autenticazione. Il servizio di autenticazione usa i gestori di autenticazione registrati per completare le azioni correlate all'autenticazione. Le azioni correlate all'autenticazione includono ad esempio:

  • Autenticazione di un utente.
  • Risposta quando un utente non autenticato tenta di accedere a una risorsa con restrizioni.

I gestori di autenticazione registrati e le relative opzioni di configurazione si definiscono "schemi".

Gli schemi di autenticazione vengono specificati registrando i servizi di autenticazione in Startup.ConfigureServices:

  • Tramite una chiamata a un metodo di estensione specifico dello schema dopo una chiamata a AddAuthentication, ad esempio AddJwtBearer o AddCookie. Questi metodi di estensione usano AuthenticationBuilder.AddScheme per registrare gli schemi con le impostazioni appropriate.
  • Meno comunemente, tramite una chiamata diretta a AuthenticationBuilder.AddScheme.

Ad esempio, il codice seguente registra i servizi di autenticazione e i gestori per cookie e gli schemi di autenticazione del token di connessione JWT:

services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme,
        options => Configuration.Bind("JwtSettings", options))
    .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme,
        options => Configuration.Bind("CookieSettings", options));

Il parametro AddAuthentication JwtBearerDefaults.AuthenticationScheme è il nome dello schema da usare per impostazione predefinita quando non è richiesto uno schema specifico.

Se vengono usati più schemi, i criteri di autorizzazione (o gli attributi di autorizzazione) possono specificare uno o più schemi di autenticazione da cui dipendono per autenticare l'utente. Nell'esempio precedente lo cookie schema di autenticazione può essere usato specificando il relativo nome (CookieAuthenticationDefaults.AuthenticationScheme per impostazione predefinita, anche se è possibile specificare un nome diverso quando si chiama AddCookie).

In alcuni casi, la chiamata a AddAuthentication viene eseguita automaticamente da altri metodi di estensione. Ad esempio, quando si usa ASP.NET Core Identity, AddAuthentication viene chiamato internamente.

Il middleware di autenticazione viene aggiunto in Startup.Configure chiamando UseAuthentication. La chiamata a UseAuthentication registra il middleware che usa gli schemi di autenticazione registrati in precedenza. Chiamare UseAuthentication prima di qualsiasi middleware che dipende dagli utenti da autenticare. Quando si usa il routing degli endpoint, la chiamata a UseAuthentication deve essere effettuata:

  • Dopo UseRouting, in modo che le informazioni sulla route siano disponibili per le decisioni sull'autenticazione.
  • Prima di UseEndpoints, in modo che gli utenti vengano autenticati prima di accedere agli endpoint.

Concetti relativi all'autenticazione

Con l'autenticazione viene fornito l'oggetto ClaimsPrincipal rispetto a cui prendere decisioni sulle autorizzazioni. Per lo schema di autenticazione sono disponibili più approcci per selezionare il gestore di autenticazione responsabile della generazione del set corretto di attestazioni:

Non esiste un sondaggio automatico di schemi. Se non viene specificato lo schema predefinito, è necessario specificarlo nell'attributo authorize, altrimenti viene generato l'errore seguente:

InvalidOperationException: Non è stato specificato alcun authenticationScheme e non è stato trovato alcun DefaultAuthenticateScheme. Gli schemi predefiniti possono essere impostati usando AddAuthentication(string defaultScheme) o AddAuthentication(Action<AuthenticationOptions> configureOptions).

Schema di autenticazione

Lo schema di autenticazione può selezionare quale gestore di autenticazione è responsabile di generare il set corretto di attestazioni. Per altre informazioni, vedere Autorizzare con uno schema specifico.

Uno schema di autenticazione è un nome che corrisponde a:

  • Gestore di autenticazione.
  • Opzioni per la configurazione di un'istanza specifica del gestore.

Gli schemi sono utili come meccanismo per autenticare, richiedere la verifica e proibire i comportamenti del gestore associato. Ad esempio, un criterio di autorizzazione può usare nomi di schema per specificare uno o più schemi di autenticazione da usare per autenticare l'utente. Quando si configura l'autenticazione, in genere si specifica lo schema di autenticazione predefinito. Lo schema predefinito viene usato a meno che una risorsa non richieda uno schema specifico. È anche possibile:

  • Specificare schemi predefiniti diversi da usare per autenticare, richiedere la verifica e proibire azioni.
  • Combinare più schemi in uno usando schemi di criteri.

Gestore di autenticazione

Un gestore di autenticazione:

In base alla configurazione dello schema di autenticazione e al contesto della richiesta in ingresso, i gestori di autenticazione:

  • Costruire AuthenticationTicket oggetti che rappresentano l'utente se l'autenticazione identity ha esito positivo.
  • Restituiscono 'nessun risultato' o 'errore' se l'autenticazione non riesce.
  • Disporre di metodi per le azioni di verifica e di proibire quando gli utenti tentano di accedere alle risorse:
    • Non sono autorizzati ad accedere (proibizione).
    • Non sono autenticati (richiesta di verifica).

Confronto tra RemoteAuthenticationHandler<TOptions> e AuthenticationHandler<TOptions>

RemoteAuthenticationHandler<TOptions> è la classe per l'autenticazione che richiede un passaggio di autenticazione remota. Al termine del passaggio di autenticazione remota, il gestore richiama l'oggetto CallbackPath che ha impostato. Il gestore completa il passaggio di autenticazione usando le informazioni passate al percorso di callback HandleRemoteAuthenticateAsync. Sia OAuth 2.0 che OIDC usano questo schema. JWT e cookie non perché possono usare direttamente l'intestazione del bearer e cookie per l'autenticazione. In questo caso il provider ospitato in remoto:

  • È il provider di autenticazione.
  • Gli esempi includono Facebook, Twitter, Google, Microsoft e qualsiasi altro provider OIDC che gestisce l'autenticazione degli utenti usando il meccanismo dei gestori.

Autentica

L'azione di autenticazione di uno schema di autenticazione è responsabile della costruzione dell'utente in base al contesto della identity richiesta. Restituisce un valore AuthenticateResult che indica se l'autenticazione ha avuto esito positivo e, in tal caso, l'utente si trova identity in un ticket di autenticazione. Vedere AuthenticateAsync. Gli esempi di autenticazione includono:

  • Uno cookie schema di identity autenticazione che costruisce l'utente dai cookie.
  • Uno schema di connessione JWT che deserializza e convalida un token di connessione JWT per costruire l'oggetto dell'utente identity.

Proposta

Una richiesta di verifica dell'autenticazione viene richiamata dall'autorizzazione quando un utente non autenticato richiede un endpoint per cui è necessaria l'autenticazione. Viene generata, ad esempio, quando un utente anonimo richiede una risorsa con restrizioni o segue un collegamento di accesso. L'autorizzazione richiama una richiesta di verifica usando gli schemi di autenticazione specificati o quello predefinito se non ne è stato specificato nessuno. Vedere ChallengeAsync. Gli esempi di richiesta di verifica dell'autenticazione includono:

  • Uno schema di autenticazione cookie che reindirizza l'utente a una pagina di accesso.
  • Uno schema di token di connessione JTW che restituisce un risultato 401 con un'intestazione www-authenticate: bearer.

Un'azione di richiesta di verifica dovrà informare l'utente sul meccanismo di autenticazione da usare per accedere alla risorsa richiesta.

Proibizione

L'azione di proibizione di uno schema di autenticazione viene chiamata dall'autorizzazione quando un utente autenticato tenta di accedere a una risorsa per cui non è autorizzato. Vedere ForbidAsync. Gli esempi di proibizione dell'autenticazione includono:

  • Uno schema di autenticazione cookie che reindirizza l'utente a una pagina che indica che l'accesso è proibito.
  • Uno schema di token di connessione JTW che restituisce un risultato 403.
  • Uno schema di autenticazione personalizzato che reindirizza a una pagina in cui l'utente può richiedere l'accesso alla risorsa.

Un'azione di proibizione può informare l'utente che:

  • È autenticato.
  • Non è autorizzato ad accedere alla risorsa richiesta.

Per informazioni sulle differenze tra la richiesta di verifica e la proibizione, vedere i collegamenti seguenti:

Provider di autenticazione per tenant

Il framework ASP.NET Core non include una soluzione predefinita per l'autenticazione multi-tenant. Anche se i clienti possono scrivere un'app con l'autenticazione multi-tenant, è consigliabile usare uno dei framework applicativi asp.net seguenti che la supportano:

Orchard Core

Orchard Core. Per un esempio di provider di autenticazione per tenant, vedere l'origine di Orchard Core.

ABP Framework

ABP Framework supporta vari schemi architetturali, tra cui modularità, microservizi, progettazione basata su dominio e multi-tenancy. Vedere Origine del framework ABP in GitHub.

Risorse aggiuntive