Scegliere una soluzione di gestione delle identità

  • Articolo

La maggior parte delle app Web supporta l'autenticazione per assicurarsi che gli utenti siano quelli che sostengono di essere. Un utente potrebbe essere una persona o un'altra app. La gestione dell'accesso garantisce che gli utenti siano in grado di visualizzare e modificare solo le informazioni che sono autorizzate a visualizzare e modificare. Ad esempio, un utente finale non deve avere accesso alla sezione amministrativa di un sito Web. Identity le soluzioni di gestione sono create per gestire i requisiti delle attività correlate all'autenticazione e all'autorizzazione. Per altre informazioni sulla gestione delle identità, vedere Informazioni sulla gestione delle identità e degli accessi. Sono disponibili molte soluzioni di gestione delle identità per le app Web .NET, ognuna con funzionalità e requisiti diversi da usare o installare. Questo articolo fornisce indicazioni su come scegliere la soluzione corretta.

Gestione delle identità di base con ASP.NET Core Identity

ASP.NET Core viene fornito con un provider di autenticazione predefinito: ASP.NET Core Identity. Il provider include le API, l'interfaccia utente e la configurazione del database back-end per supportare la gestione delle identità utente, l'archiviazione delle credenziali utente e la concessione o la revoca delle autorizzazioni. Altre funzionalità supportate includono:

Per la maggior parte degli scenari, questo potrebbe essere l'unico provider necessario.

Per altre informazioni, vedere:

In altri scenari, un server o un servizio che gestisce l'autenticazione e l'identità possono essere utili.

Determinare se è necessario un server OIDC

Le app Web richiedono un modo per ricordare le azioni passate perché il Web, per impostazione predefinita, è senza stato. In caso contrario, gli utenti sarebbero costretti a immettere le credenziali ogni volta che passavano a una nuova pagina. La soluzione comune per ricordare lo stato è cookies, un meccanismo basato su browser per l'archiviazione dei dati. Il server Web invia l'oggetto iniziale cookie, quindi il browser lo archivia e lo invia nuovamente con ogni richiesta. Questa operazione viene eseguita automaticamente senza la necessità per lo sviluppatore di scrivere codice. Cookies è facile da usare e integrato nel browser, ma sono progettati per l'uso all'interno di un singolo sito Web o dominio Web. La soluzione predefinita integrata in ASP.NET Core usa cookiel'autenticazione basata su .

I token sono contenitori con metadati passati in modo esplicito tramite le intestazioni o il corpo delle richieste HTTP. Il vantaggio principale dei token rispetto cookiea s è che non sono associati a un'app o a un dominio specifico. I token vengono in genere firmati con crittografia asimmetrica. Ad esempio, i server OIDC rilasciano token con informazioni sull'identità usando il formato ON Web Token (JWT) che include la JSfirma. La crittografia asimmetrica usa una combinazione di una chiave privata nota solo al firmatario e una chiave pubblica che tutti possono conoscere. I token possono anche essere crittografati.

Il token firmato non può essere manomesso a causa della chiave privata. Chiave pubblica:

  • Consente di convalidare il token per assicurarsi che non sia stato modificato.
  • Garantisce che sia stato generato dall'entità che contiene la chiave privata.

Lo svantaggio principale dell'uso dei token è che richiedono un servizio (in genere un server OIDC) per entrambi i problemi e fornire la convalida per i token. Il servizio deve essere installato, configurato e gestito.

Un motivo comune per cui è necessario un server OIDC è per le applicazioni che espongono API basate sul Web utilizzate da altre app. Per le API basate sul Web esposte, le interfacce utente client, ad esempio applicazioni a pagina singola, client per dispositivi mobili e client desktop, sono considerate parte della stessa app. Gli esempi spa includono Angular, React e Blazor WebAssembly. Se le app diverse dall'app Web o da qualsiasi utente client devono effettuare una chiamata API sicura all'app, è probabile che si vogliano usare i token. Se si dispone solo di interfacce utente client, ASP.NET Core Identity offre la possibilità di acquisire un token durante l'autenticazione. Token di autenticazione rilasciato da ASP.NET Core Identity:

  • Può essere usato dai client per dispositivi mobili e desktop. Cookies sono preferiti rispetto ai token sia per sicurezza che per semplicità.
  • Non è adatto per la gestione dell'accesso da app di terze parti.

Un altro motivo per cui è necessario un server OIDC è la condivisione degli accessi con altre app. Nota comunemente come Single Sign-On, questa funzionalità consente agli utenti di:

  • Accedere una volta con il modulo di un'app Web.
  • Usare le credenziali risultanti per eseguire l'autenticazione con altre app senza dover eseguire di nuovo l'accesso o scegliere una password diversa.

Un server OIDC è in genere preferibile per fornire una soluzione sicura e scalabile per l'accesso Single Sign-On.

Per le app che non condividono account di accesso con altre app, il modo più semplice per proteggere rapidamente un'app consiste nell'usare il provider ASP.NET Core Identity predefinito. In caso contrario, è necessario un server OIDC fornito da una soluzione di gestione delle identità di terze parti. I server OIDC sono disponibili come:

  • Prodotti installati nel server, denominati self-host.
  • I contenitori vengono eseguiti in un host come Docker.
  • Servizi basati sul Web integrati con per gestire l'identità.

Alcune soluzioni sono gratuite e open source, mentre altre sono con licenza commerciale. Per un elenco delle opzioni disponibili, vedere Soluzioni di gestione delle identità. È possibile che l'organizzazione usi già un provider di identità. In tal caso, può essere opportuno usare il provider esistente invece di passare con una soluzione diversa. Tutte le principali soluzioni forniscono documentazione per la configurazione di ASP.NET Core per l'uso del prodotto o del servizio.

Scenari disconnessi

Molte soluzioni, ad esempio Microsoft Entra ID, sono basate sul cloud e richiedono una connessione Internet per funzionare. Se l'ambiente non consente la connettività Internet, non sarà possibile usare il servizio.

ASP.NET Core Identity funziona perfettamente in scenari disconnessi, ad esempio:

  • L'app non può accedere a Internet.
  • L'app deve comunque funzionare nella rete locale anche se Internet è disconnesso.

Se è necessario un server OIDC completo per uno scenario disconnesso, scegliere una delle opzioni seguenti:

  • Soluzione che consente di installare ed eseguire il servizio nei propri computer.
  • Eseguire il servizio di autenticazione in locale come contenitore.

Decidere dove vengono archiviati i dati utente, ad esempio gli accessi

Un altro fattore importante da considerare è la posizione in cui vengono archiviati i dati di accesso utente. Molti sviluppatori scelgono servizi esterni basati sul cloud come Microsoft Entra ID per gestire l'identità. Un provider di servizi basato sul cloud:

  • Assume le responsabilità di archiviare i dati in modo sicuro.
  • mantiene aggiornato il software con le patch e le versioni di sicurezza più recenti.
  • Conforme alle normative sulla privacy.

Altri preferiscono archiviare i dati nei propri server a causa di normative, conformità, criteri o altri motivi.

Se i dati vengono archiviati nei server, è molto probabile che sia necessario scegliere una soluzione installabile o basata su contenitori.

Identity Vs OIDC server

Usare il diagramma seguente per decidere se usare il sistema ASP.NET Core Identity o un server OIDC per l'autenticazione e l'autorizzazione:

Identity management decision flow

La tabella seguente elenca alcuni aspetti da considerare quando si sceglie la soluzione di gestione delle identità.

Funzionalità Self-host (infrastruttura o contenitore) Cloud
Integrazione di app Le soluzioni locali implementate come librerie o framework possono spesso essere integrate direttamente nella propria app. Le soluzioni basate su contenitori richiedono una distribuzione tra l'app Web e il servizio basato su contenitori. Le soluzioni basate sul cloud in genere si integrano in punti specifici nel flusso di accesso e forniscono la configurazione per aggiornare l'interfaccia utente in modo che corrisponda al tema, ma il livello di personalizzazione disponibile è limitato.
Configurazione Le soluzioni self-host richiedono la configurazione del software per l'ambiente oltre a configurare la modalità di gestione delle identità. Le soluzioni basate su contenitori in genere forniscono un'interfaccia utente basata sul Web per la configurazione. Le soluzioni basate sul cloud in genere forniscono un'interfaccia utente basata sul Web per la configurazione.
Personalizzazione Le soluzioni self-host sono in genere altamente personalizzabili, incluse le modifiche basate sul codice. Sebbene le soluzioni in contenitori forniscano opzioni di estendibilità, sono spesso più limitate. I servizi basati sul cloud consentono la personalizzazione, ma in genere sono limitati alle modifiche basate sulla configurazione.
Gestione I prodotti installati richiedono una risorsa dedicata per garantire che tutte le patch di sicurezza vengano applicate in modo tempestivo e per gestire gli aggiornamenti. Il processo di aggiornamento e patch per i contenitori è in genere più basso e comporta semplicemente l'installazione dell'immagine del contenitore fornita. Il provider di servizi gestisce la soluzione basata sul cloud, inclusa l'applicazione delle patch necessarie e la gestione degli aggiornamenti.
Archiviazione delle credenziali utente L'utente è responsabile della governance dei dati e della gestione delle violazioni. Gestione dei rischi associati alla gestione delle credenziali utente e conformità alle normative. viene delegato al provider di servizi.

Per altre informazioni sulle opzioni disponibili, vedere Identity Soluzioni di gestione per ASP.NET Core.

Passaggi successivi