Condividi tramite

Scegliere una identity soluzione di gestione

  • 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 identity gestione, vedere Che cos'è identity e gestione degli accessi? Sono disponibili molte identity soluzioni di gestione 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 di base identity 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 identity può essere utile.

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 è rappresentata dai cookie, 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. I cookie sono facili da usare e incorporati 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 ai cookie è 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'uso identity del formato JWT (JSON Web Token) che include la firma. 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. I cookie 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 di terze parti identity . 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 identity.

Alcune soluzioni sono gratuite e open source, mentre altre sono con licenza commerciale. Per un elenco delle opzioni disponibili, vedere identity Soluzioni di gestione. È possibile che l'organizzazione usi già un identity provider. 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 identity. 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 privacy normative.

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 flusso decisionale di gestione

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

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