Autenticazione senza certificati con Microsoft. Identity.Web

L'autenticazione senza certificati consente all'applicazione di eseguire l'autenticazione con Microsoft Entra ID senza gestire certificati o segreti client. Invece, l'app utilizza un FIC (Federated Identity Credential - Credenziale di Identità Federata) supportato da un'identità gestita di Azure per ottenere i token. Questo approccio elimina la rotazione delle credenziali, riduce la proliferazione dei segreti e semplifica le distribuzioni su Azure.

Microsoft. Identity.Web supporta l'autenticazione senza certificato tramite il tipo di origine delle credenziali SignedAssertionFromManagedIdentity, disponibile nella versione 2.12.0 e successive.

Che cos'è l'autenticazione senza certificato?

In genere, le applicazioni client riservate dimostrano la propria identità per Microsoft Entra ID presentando un segreto client o un certificato. Entrambi gli approcci richiedono di gestire il ciclo di vita delle credenziali, ruotando i segreti prima della scadenza, rinnovando i certificati e archiviandoli in modo sicuro.

Le Federated Identity Credentials (FIC) cambiano questo modello. Con FIC si configura una relazione di trust tra la registrazione dell'app e un'identità gestita. Quando l'applicazione deve eseguire l'autenticazione:

1. Microsoft.Identity.Web richiede un token dall'endpoint Identità Gestita nell'host Azure.
2. La libreria usa il token di identità gestita come asserzione firmata per l'autenticazione con Microsoft Entra ID.
3. Microsoft Entra ID convalida l'asserzione firmata rispetto alla configurazione delle credenziali federate nella registrazione dell'app.
4. Microsoft Entra ID rilascia un token di accesso per la risorsa richiesta.

Il risultato è una distribuzione completamente senza credenziali in cui non esistono segreti o certificati nella configurazione, nel codice o nelle variabili di ambiente.

Quando usare l'autenticazione senza certificato

Prerequisiti

Prima di configurare l'autenticazione senza certificati, assicurarsi di disporre degli elementi seguenti:

• Sottoscrizione Azure. Se non ne hai uno, crea un account gratuito.
• Una registrazione di un'applicazione in Microsoft Entra ID con le autorizzazioni API necessarie per il tuo scenario.
• Un'Managed Identity in Azure, sia assegnata dal sistema alla tua risorsa di calcolo sia un'identità gestita assegnata dall'utente come entità autonoma.
• Microsoft. Identity.Web versione 2.12.0 o successiva installata nel progetto.
• Risorsa di calcolo Azure che supporta identità gestite, ad esempio Servizio app di Azure, Servizio Azure Kubernetes (AKS), App contenitore di Azure o Macchine virtuali di Azure.

Passaggio 1: Creare o identificare un'identità gestita

È possibile usare un'identità gestita assegnata dal sistema o assegnata dall'utente. Se non ne è ancora stato creato uno, seguire le istruzioni per lo scenario in uso.

Opzione A: Usare un'identità gestita assegnata dal sistema

Le identità gestite assegnate dal sistema sono associate al ciclo di vita di una risorsa Azure. Quando si abilita un'identità assegnata dal sistema in una risorsa come un servizio app, Azure crea automaticamente un'identità.

1. Nel portale Azure, passare alla risorsa di calcolo, ad esempio al servizio app.
2. Selezionare Identità dal menu di spostamento a sinistra.
3. All'interno della scheda Assegnata dal sistema, impostare lo stato su Attivato.
4. Selezionare Salva e confermare l'azione.
5. Dopo aver creato l'identità, copiare l'ID oggetto (principale). Questo valore è necessario quando si configurano le credenziali federate.

Opzione B: Creare un'identità gestita assegnata dall'utente

Le identità gestite assegnate dall'utente sono autonome Azure risorse che è possibile assegnare a una o più risorse di calcolo.

1. Nel portale Azure cercare Managed Identities e selezionarlo.
2. Fare clic su Crea.
3. Scegliere la sottoscrizione, il gruppo di risorse, l'area e immettere un nome per l'identità.
4. Selezionare Rivedi + crea, quindi Crea.
5. Al termine della distribuzione, aprire la nuova risorsa Identità Gestita.
6. Copiare l'ID client dalla pagina Panoramica. Questo valore è necessario per la configurazione dell'applicazione.

Passaggio 2: Configurare una credenziale di identità federata nel portale di Azure

Una credenziale identità federata stabilisce una relazione di trust tra la registrazione dell'app e l'identità gestita. Seguire questa procedura per crearne uno:

1. Nel portale Azure passare a Microsoft Entra ID>Registrazioni app.

2. Selezionare la registrazione dell'app usata dall'applicazione.

3. Nel menu di spostamento a sinistra selezionare Certificati e segreti.

4. Seleziona la scheda Credenziali federate.

5. Seleziona Aggiungi credenziali.

6. In Scenario di credenziali federate selezionare Chiavi gestite dal cliente o Altro emittente (le opzioni disponibili dipendono dalla versione del portale).

7. Configurare i campi seguenti:

   Campo	Valore
   Emittente	https://login.microsoftonline.com/{tenant-id}/v2.0 : sostituire {tenant-id} con l'ID tenant Microsoft Entra.
   Identificatore del soggetto	ID oggetto (principale) dell'identità gestita. Per trovare l'assegnazione del sistema, consultare la pagina Identità della risorsa. Per "assegnato all'utente", trovare questa opzione nella pagina Panoramica dell'identità gestita sotto Principal ID.
   Nome	Nome descrittivo, ad esempio fic-managed-identity-prod.
   Destinatari	api://AzureADTokenExchange (valore predefinito).

8. Seleziona Aggiungi.

Configurare una credenziale di identità federata con interfaccia della riga di comando di Azure

È anche possibile creare le credenziali federate usando il interfaccia della riga di comando di Azure:

az ad app federated-credential create \
    --id <app-object-id> \
    --parameters '{
        "name": "fic-managed-identity-prod",
        "issuer": "https://login.microsoftonline.com/<tenant-id>/v2.0",
        "subject": "<managed-identity-principal-id>",
        "audiences": ["api://AzureADTokenExchange"],
        "description": "FIC for production managed identity"
    }'

URL emittente per servizio Azure

L'URL dell'autorità di certificazione nella credenziale federata dipende dal servizio Azure che ospita l'applicazione:

Formato identificatore soggetto

Il formato dell'identificatore del soggetto dipende dal tipo di identità gestita:

Identità gestita assegnata dal sistema : usare l'ID oggetto (entità) dalla pagina Identità della risorsa. Si tratta di un valore GUID, ad esempio a1b2c3d4-e5f6-7890-abcd-ef1234567890.

Identità gestita assegnata dall'utente - usare l'ID principale (detto anche ID oggetto) nella pagina Panoramica della risorsa identità gestita. Si tratta anche di un valore GUID.

Passaggio 3: Configurare l'applicazione

Aggiornare appsettings.json

Aggiungi la sezione ClientCredentials alla configurazione AzureAd. Impostare il SourceType su SignedAssertionFromManagedIdentity:

Per l'identità gestita assegnata dall'utente

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "TenantId": "YOUR_TENANT_ID",
    "ClientId": "YOUR_CLIENT_ID",
    "ClientCredentials": [
      {
        "SourceType": "SignedAssertionFromManagedIdentity",
        "ManagedIdentityClientId": "USER_ASSIGNED_MSI_CLIENT_ID"
      }
    ]
  }
}

Sostituire i segnaposto seguenti:

Per l'identità gestita assegnata dal sistema

Quando si usa un'identità gestita assegnata dal sistema, omettere la ManagedIdentityClientId proprietà . Microsoft. Identity.Web usa automaticamente l'identità assegnata dal sistema dell'host:

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "TenantId": "YOUR_TENANT_ID",
    "ClientId": "YOUR_CLIENT_ID",
    "ClientCredentials": [
      {
        "SourceType": "SignedAssertionFromManagedIdentity"
      }
    ]
  }
}

Registrare i servizi in Program.cs

Non sono necessarie modifiche speciali al codice nella configurazione di avvio. I metodi di registrazione standard di Microsoft.Identity.Web leggono automaticamente la sezione ClientCredentials:

// For a web app that signs in users and calls downstream APIs
builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApp(builder.Configuration.GetSection("AzureAd"))
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddInMemoryTokenCaches();

// For a web API that calls downstream APIs
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAd"))
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddInMemoryTokenCaches();

// For a daemon application (no user interaction)
builder.Services.AddAuthentication()
    .AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAd"));

builder.Services.AddTokenAcquisition()
    .AddInMemoryTokenCaches();

Microsoft. Identity.Web rileva il tipo di origine SignedAssertionFromManagedIdentity e gestisce lo scambio di token in modo trasparente.

Identità gestita assegnata dal sistema vs identità gestita assegnata dall'utente

Scegliere il tipo di identità gestita più adatto all'architettura.

Identità gestita assegnata dal sistema

Un'identità assegnata dal sistema viene creata ed eliminata automaticamente con la risorsa Azure a cui appartiene.

Vantaggi:

• Nessuna risorsa separata da gestire: il ciclo di vita delle identità corrisponde alla risorsa di calcolo.
• Configurazione più semplice per le distribuzioni a singola risorsa.
• Nessuna ManagedIdentityClientId richiesta nella configurazione.

Considerations:

• Non è possibile condividere l'identità tra più risorse.
• Se si elimina e si ricrea la risorsa, l'identità cambia, è necessario aggiornare le credenziali dell'identità federata.

Ideale per: Distribuzioni a istanza singola in cui una risorsa di calcolo è mappata a una registrazione dell'app.

Identità gestita assegnata dall'utente

Un'identità assegnata dall'utente è una risorsa Azure autonoma con il proprio ciclo di vita.

Vantaggi:

• Condividere una singola identità tra più risorse di calcolo, ad esempio più istanze del servizio app in aree diverse.
• L'identità persiste indipendentemente dal ciclo di vita delle risorse di calcolo.
• Pre-creare e preconfigurare prima di distribuire la risorsa di calcolo.

Considerations:

• Risorsa Azure aggiuntiva da gestire.
• È necessario specificare il ManagedIdentityClientId nella configurazione.

Ideale per: Distribuzioni a più istanze o in più aree, modelli di distribuzione blu-verde e scenari in cui le risorse di calcolo vengono spesso ricreate.

Eseguire la distribuzione in servizi di calcolo Azure

Servizio app di Azure

1. Abilitare l'identità gestita nel servizio app (vedere passaggio 1).

2. Distribuire l'applicazione nel servizio app usando il metodo preferito (Visual Studio, interfaccia della riga di comando di Azure GitHub Actions).

3. Verificare che la AzureAd sezione nella configurazione distribuita corrisponda alle impostazioni del passaggio 3.

4. Se si usa un'identità gestita assegnata dall'utente, assegnarla al servizio app:

   az webapp identity assign \
     --resource-group <resource-group> \
     --name <app-service-name> \
     --identities <managed-identity-resource-id>
   

5. Riavviare l'App Service per recepire l'assegnazione di identità.

Azure Kubernetes Service (AKS)

Per AKS, utilizzare l'identità del carico di lavoro per associare un account del servizio Kubernetes all'identità gestita.

1. Abilitare la funzionalità di identità del carico di lavoro nel cluster del servizio Azure Kubernetes:

   az aks update \
     --resource-group <resource-group> \
     --name <aks-cluster-name> \
     --enable-oidc-issuer \
     --enable-workload-identity
   

2. Creare un account del servizio Kubernetes contrassegnato con l'ID client di Identità Gestita.

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: my-app-sa
     namespace: default
     annotations:
       azure.workload.identity/client-id: "<USER_ASSIGNED_MSI_CLIENT_ID>"
   

3. Creare una credenziale federata che collega l'emittente OIDC di AKS all'identità gestita.

4. Configura il tuo pod per utilizzare l'account di servizio.

   apiVersion: v1
   kind: Pod
   metadata:
     name: my-app
     namespace: default
     labels:
       azure.workload.identity/use: "true"
   spec:
     serviceAccountName: my-app-sa
     containers:
       - name: my-app
         image: <your-container-image>
   

5. Distribuire il pod. Il webhook di identità del carico di lavoro inserisce le variabili di ambiente necessarie per l'endpoint del token di identità gestita.

App contenitore di Azure

1. Creare o aggiornare la tua app contenitore con un'identità gestita:

   az containerapp identity assign \
     --resource-group <resource-group> \
     --name <container-app-name> \
     --user-assigned <managed-identity-resource-id>
   

2. Distribuire l'immagine del container con la configurazione AzureAd appropriata.

3. L'endpoint del token di identità gestita è disponibile automaticamente all'interno del contenitore.

Eseguire la migrazione dai certificati all'autenticazione senza certificati

Se l'applicazione usa attualmente l'autenticazione basata su certificati, è possibile eseguire la migrazione all'autenticazione senza certificati con modifiche minime.

Passaggi per la migrazione

1. Creare un'identità gestita per la risorsa di calcolo Azure (vedere P 1).

2. Aggiungere una credenziale di identità federata alla registrazione dell'app (vedere passaggio 2).

3. Aggiornare la configurazione per aggiungere le SignedAssertionFromManagedIdentity credenziali. È possibile mantenere le credenziali del certificato esistenti come fallback durante la migrazione:

   {
     "AzureAd": {
       "Instance": "https://login.microsoftonline.com/",
       "TenantId": "YOUR_TENANT_ID",
       "ClientId": "YOUR_CLIENT_ID",
       "ClientCredentials": [
         {
           "SourceType": "SignedAssertionFromManagedIdentity",
           "ManagedIdentityClientId": "USER_ASSIGNED_MSI_CLIENT_ID"
         },
         {
           "SourceType": "KeyVault",
           "KeyVaultUrl": "https://your-keyvault.vault.azure.net",
           "KeyVaultCertificateName": "your-cert-name"
         }
       ]
     }
   }
   

   Microsoft Identity.Web cerca le fonti delle credenziali in ordine sequenziale. In caso di esecuzione in Azure, la prima credenziale (SignedAssertionFromManagedIdentity) ha esito positivo. Se si verifica un errore, ad esempio durante lo sviluppo locale, la libreria torna al certificato.

4. Distribuire e convalidare in un ambiente di staging prima di applicare all'ambiente di produzione.

5. Rimuovere le credenziali del certificato dalla configurazione dopo aver verificato che l'autenticazione senza certificato funzioni nell'ambiente di produzione.

6. Elimina il certificato da Azure Key Vault e la registrazione dell'app quando non sono più necessari.

Prima e dopo il confronto

Autenticazione basata su certificato (prima):

{
  "AzureAd": {
    "ClientCredentials": [
      {
        "SourceType": "KeyVault",
        "KeyVaultUrl": "https://your-keyvault.vault.azure.net",
        "KeyVaultCertificateName": "your-cert-name"
      }
    ]
  }
}

Dopo (senza certificato):

{
  "AzureAd": {
    "ClientCredentials": [
      {
        "SourceType": "SignedAssertionFromManagedIdentity",
        "ManagedIdentityClientId": "USER_ASSIGNED_MSI_CLIENT_ID"
      }
    ]
  }
}

Risoluzione dei problemi

AADSTS70021: nessun record di identità federato corrispondente trovato

Causa: L'identificatore del soggetto nella credenziale dell'identità federata non corrisponde all'ID oggetto (entità) dell'identità gestita.

Risoluzione:

1. Nel portale di Azure passare alla risorsa Identità gestita e copiare il IDprincipal (detto anche ID oggetto) dalla pagina Overview.
2. Passare alla registrazione > dell'app Certificati e segreti>Credenziali federate.
3. Verificare che il campo Identificatore del soggetto corrisponda esattamente all'ID principale.
4. Se i valori non corrispondono, eliminare le credenziali e ricrearle con l'identificatore del soggetto corretto.

AADSTS700024: l'asserzione client non rientra nell'intervallo di tempo valido

Causa: Il token di identità gestita usato come asserzione firmata è scaduto o l'orologio di sistema è asimmetrico.

Risoluzione:

• Verificare che l'orologio di sistema nella risorsa Azure sia accurato.
• Riavviare l'applicazione per forzare una nuova richiesta di token di identità gestita.
• Se si esegue un'applicazione in un contenitore, assicurarsi che l'orologio del contenitore sia sincronizzato con l'host.

ManagedIdentityException: Endpoint identità gestita non disponibile

Cause: L'applicazione non riesce a raggiungere il servizio metadati dell'istanza di Azure o l'endpoint del token di identità gestita.

Risoluzione:

• Verificare che l'applicazione sia in esecuzione in una risorsa di calcolo Azure che supporta l'identità gestita.
• Verificare che l'identità gestita sia abilitata e assegnata alla risorsa di calcolo.
• Per il servizio Azure Kubernetes, verificare che il webhook di identità del carico di lavoro sia in esecuzione e che il pod abbia l'annotazione corretta dell'account del servizio.
• Per lo sviluppo locale, questo errore è previsto. Utilizzare una fonte di credenziali di riserva (consultare Passaggi per la migrazione).

AADSTS700016: applicazione non trovata nella directory

Causa: La ClientId configurazione non corrisponde a una registrazione valida dell'app nel tenant specificato.

Risoluzione:

• Verificare che ClientId corrisponda all'ID applicazione (client) della registrazione dell'app.
• Verificare che TenantId corrisponda al tenant in cui è registrata l'app.

L'acquisizione del token ha esito negativo in modo invisibile all'utente nell'ambiente di produzione

Causa: L'ordine di origine delle credenziali o la mancata corrispondenza della configurazione potrebbero far sì che la libreria ignori le credenziali FIC.

Risoluzione:

1. Abilitare la registrazione in Microsoft. Identity.Web per visualizzare i passaggi dettagliati di acquisizione dei token:

   builder.Services.AddLogging(logging =>
   {
       logging.AddConsole();
       logging.SetMinimumLevel(LogLevel.Debug);
       logging.AddFilter("Microsoft.Identity", LogLevel.Debug);
   });
   

2. Esaminare i log per i messaggi relativi alla fonte delle credenziali che la libreria ha tentato e gli eventuali errori restituiti.

Identità gestita assegnata dall'utente non rilevata

Causa: Quando più identità gestite assegnate dall'utente vengono assegnate a una risorsa di calcolo, la libreria potrebbe usare quella errata se ManagedIdentityClientId non è specificata.

Risoluzione:

• Specificare sempre la ManagedIdentityClientId proprietà quando si usa un'identità gestita assegnata dall'utente.
• Verificare che l'ID client corrisponda all'identità configurata per le credenziali dell'identità federata.

Vantaggi di sicurezza

L'autenticazione senza certificati con FIC offre vantaggi significativi per la sicurezza rispetto a approcci tradizionali basati sulle credenziali:

Nessun segreto da perdere

Poiché non esistono file di certificato, password PFX o segreti client nella configurazione o negli artefatti di distribuzione, non esiste nulla per un utente malintenzionato da estrarre. Anche se un utente malintenzionato ottiene l'accesso in lettura ai file di configurazione, non può fingersi la tua applicazione dall'esterno di Azure.

Nessuna rotazione delle credenziali

I token di identità gestita sono di breve durata e aggiornati automaticamente dalla piattaforma Azure. Non è necessario implementare pianificazioni di rotazione, monitorare le date di scadenza o coordinare gli aggiornamenti delle credenziali tra le distribuzioni.

Superficie di attacco ridotta

L'endpoint del token di identità gestita è accessibile solo dalla risorsa Azure specifica a cui viene assegnata l'identità. Un utente malintenzionato non può usare le credenziali da un host, una rete o un ambiente cloud diverso.

Semplificazione della conformità

Senza credenziali di lunga durata, si eliminano diverse categorie di problemi di conformità:

• Nessun segreto archiviato nel controllo del codice sorgente, nelle variabili di ambiente o nei file di configurazione.
• Nessun materiale chiave da controllare, ruotare o revocare.
• Nessuna infrastruttura di certificati (CA, processi di rinnovo) da gestire.

Difesa avanzata

Combinare l'autenticazione senza certificato con altre funzionalità di sicurezza Azure per la protezione a più livelli:

• Azure controllo degli accessi in base al ruolo: controllare quali identità possono accedere alle risorse.
• Accesso condizionale: applicare criteri in base al rischio di identità, alla posizione e allo stato del dispositivo.
• Endpoint privati: Limitano l'accesso di rete alle risorse Azure.
• Microsoft Defender per il cloud: monitorare i modelli di autenticazione sospetti.

Contenuti correlati

• Panoramica delle credenziali
• Attestati
• Segreti del client
• Documentazione di Azure sulle Identità Gestite
• Documentazione delle credenziali di identità federate
• Microsoft.Identity.Web repository di GitHub