Informazioni di riferimento sul provider di metodi esterni per l'autenticazione a più fattori Di Microsoft Entra (anteprima)

Questo argomento descrive come un provider di autenticazione esterno si connette all'autenticazione a più fattori (MFA) di Microsoft Entra. Un provider di autenticazione esterno può integrarsi con i tenant di Microsoft Entra ID come metodo di autenticazione esterno (EAM). Un EAM può soddisfare il secondo fattore di un requisito di autenticazione a più fattori per l'accesso a una risorsa o a un'applicazione. Gli EAM richiedono almeno una licenza Microsoft Entra ID P1.

Quando un utente accede, i criteri del tenant vengono valutati. I requisiti di autenticazione vengono determinati in base alla risorsa a cui l'utente tenta di accedere.

È possibile applicare più criteri all'accesso, a seconda dei relativi parametri. Questi parametri includono utenti e gruppi, applicazioni, piattaforma, livello di rischio di accesso e altro ancora.

In base ai requisiti di autenticazione, l'utente potrebbe dover accedere con un altro fattore per soddisfare i requisiti di autenticazione a più fattori. Il secondo fattore deve integrare il tipo di primo fattore.

Gli EAM vengono aggiunti all'ID Microsoft Entra dall'amministratore del tenant. Se un tenant richiede un EAM per L'autenticazione a più fattori, l'accesso viene considerato conforme al requisito MFA dopo che Microsoft Entra ID convalida entrambi:

• Il primo fattore completato con Microsoft Entra ID
• Il secondo fattore completato con l'EAM

Tale convalida soddisfa il requisito MFA per due o più tipi di metodi da:

• Qualcosa che sai (conoscenza)
• Qualcosa che hai (possesso)
• Qualcosa che sei (inherence)

Gli EAM vengono implementati sopra Open ID Connect (OIDC). Questa implementazione richiede almeno tre endpoint rivolti pubblicamente:

• Un endpoint di individuazione OIDC, come descritto in Individuazione dei metadati del provider
• Endpoint di autenticazione OIDC valido
• URL in cui vengono pubblicati i certificati pubblici del provider

Si esaminerà ora più in dettaglio il funzionamento dell'accesso con un EAM:

1. Un utente tenta di accedere con un primo fattore, ad esempio una password, a un'applicazione protetta da Microsoft Entra ID.
2. Microsoft Entra ID determina che deve essere soddisfatto un altro fattore. Ad esempio, un criterio di accesso condizionale richiede l'autenticazione a più fattori.
3. L'utente sceglie L'EAM come secondo fattore.
4. Microsoft Entra ID reindirizza la sessione del browser dell'utente all'URL EAM:
   1. Questo URL viene individuato dall'URL di individuazione di cui è stato effettuato il provisioning da un amministratore al momento della creazione dell'EAM.
   2. L'applicazione fornisce un token scaduto o quasi scaduto che contiene informazioni per identificare l'utente e il tenant.
5. Il provider di autenticazione esterno convalida che il token proviene da Microsoft Entra ID e controlla il contenuto del token.
6. Il provider di autenticazione esterno potrebbe facoltativamente effettuare una chiamata a Microsoft Graph per recuperare informazioni aggiuntive sull'utente.
7. Il provider di autenticazione esterno esegue tutte le azioni che ritiene necessarie, ad esempio l'autenticazione dell'utente con alcune credenziali.
8. Il provider di autenticazione esterno reindirizza l'utente all'ID Microsoft Entra con un token valido, incluse tutte le attestazioni necessarie.
9. Microsoft Entra ID convalida che la firma del token proviene dal provider di autenticazione esterno configurato e quindi controlla il contenuto del token.
10. Microsoft Entra ID convalida il token in base ai requisiti.
11. L'utente ha soddisfatto il requisito MFA se la convalida ha esito positivo. L'utente potrebbe anche dover soddisfare altri requisiti dei criteri.

Configurare un nuovo provider di autenticazione esterno con Microsoft Entra ID

Un'applicazione che rappresenta l'integrazione è necessaria affinché gli EAM esemettono il id_token_hint. L'applicazione può essere creata in due modi:

• Creato in ogni tenant che usa il provider esterno.
• Creato come un'applicazione multi-tenant. Gli amministratori dei ruoli con privilegi devono concedere il consenso per abilitare l'integrazione per il tenant.

Un'applicazione multi-tenant riduce la probabilità di errori di configurazione in ogni tenant. Consente anche ai provider di apportare modifiche ai metadati, ad esempio gli URL di risposta in un'unica posizione, anziché richiedere a ogni tenant di apportare le modifiche.

Per configurare un'applicazione multi-tenant, l'amministratore del provider deve prima di tutto:

1. Creare un tenant di Microsoft Entra ID se non ne ha ancora uno.

2. Registrare un'applicazione nel tenant.

3. Impostare i tipi di account supportati dell'applicazione su: Account in qualsiasi directory organizzativa (qualsiasi tenant di Microsoft Entra ID - Multi-tenant).

4. Aggiungere l'autorizzazione openid delegata e profile di Microsoft Graph all'applicazione.

5. Non pubblicare ambiti in questa applicazione.

6. Aggiungere gli URL di authorization_endpoint validi del provider di identità esterno a tale applicazione come URL di risposta.

   Nota

   Il authorization_endpoint fornito nel documento di individuazione del provider deve essere aggiunto come URL di reindirizzamento nella registrazione dell'applicazione. In caso contrario, viene visualizzato l'errore seguente: ENTRA IDSTS50161: Impossibile convalidare l'URL di autorizzazione del provider di attestazioni esterne.

Il processo di registrazione dell'applicazione crea un'applicazione con diverse proprietà. Queste proprietà sono necessarie per lo scenario.

Un'applicazione per ogni tenant è anche un modello valido per supportare l'integrazione. Se si usa una registrazione a tenant singolo, l'amministratore del tenant deve creare una registrazione dell'applicazione con le proprietà nella tabella precedente per un'applicazione a tenant singolo.

Configurare le attestazioni facoltative

Un provider può configurare più attestazioni usando attestazioni facoltative per id_token.

Aggiungere un EAM a Microsoft Entra ID

Le informazioni sul provider di identità esterne vengono archiviate nei criteri dei metodi di autenticazione di ogni tenant. Le informazioni sul provider vengono archiviate come metodo di autenticazione di tipo externalAuthenticationMethodConfiguration.

Ogni provider ha una voce nell'oggetto elenco dei criteri. Ogni voce deve essere in stato:

• Se il metodo è abilitato
• Gruppi inclusi che possono usare il metodo
• I gruppi esclusi che non possono usare il metodo

Gli amministratori dell'accesso condizionale possono creare un criterio con la richiesta di concessione MFA per impostare il requisito di autenticazione a più fattori per l'accesso utente. I metodi di autenticazione esterni non sono attualmente supportati con i punti di forza di autenticazione.

Per altre informazioni su come aggiungere un metodo di autenticazione esterno nell'interfaccia di amministrazione di Microsoft Entra, vedere Gestire un metodo di autenticazione esterno in Microsoft Entra ID (anteprima).

Interazione di Microsoft Entra ID con il provider

Le sezioni successive illustrano i requisiti del provider e includono esempi per l'interazione di Microsoft Entra ID con un provider.

Individuazione dei metadati del provider

Un provider di identità esterno deve fornire un endpoint di individuazione OIDC. Questo endpoint viene usato per ottenere più dati di configurazione. URL completo, incluso .la configurazione oidc-nota/deve essere inclusa nell'URL di individuazione configurato al momento della creazione dell'EAM.

L'endpoint restituisce un documento JSON dei metadati del provider ospitato in questa posizione. L'endpoint deve restituire anche l'intestazione content-length valida.

Nella tabella seguente sono elencati i dati che devono essere presenti nei metadati del provider. Questi valori sono necessari per questo scenario di estendibilità. Il documento di metadati JSON può contenere altre informazioni.

Per il documento OIDC con i valori per i metadati del provider, vedere Metadati del provider.

http://customcaserver.azurewebsites.net/v2.0/.well-known/openid-configuration
{
  "authorization_endpoint": "https://customcaserver.azurewebsites.net/api/Authorize",
  "claims_supported": [
    "email"
  ],
  "grant_types_supported": [
    "implicit"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ],
  "issuer": "https://customcaserver.azurewebsites.net",
  "jwks_uri": "http://customcaserver.azurewebsites.net/.well-known/jwks",
  "response_modes_supported": [
    "form_post"
  ],
  "response_types_supported": [
    "id_token"
  ],
  "scopes_supported": [
    "openid"
  ],
  "SigningKeys": [],
  "subject_types_supported": [
    "public"
  ]
}

http://customcaserver.azurewebsites.net/.well-known/jwks
{
  "keys": [
    {
      "kty": "RSA",
      "use": "sig",
      "kid": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
      "x5t": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
      "n": "jq277LRoE6WKM0awT3b...vt8J6MZvmgboVB9S5CMQ",
      "e": "AQAB",
      "x5c": [
        "cZa3jz...Wo0rzA="
      ]
    }
  ]
}

Memorizzazione nella cache dei metadati del provider

Per migliorare le prestazioni, Microsoft Entra ID memorizza nella cache i metadati restituiti dal provider, incluse le chiavi. La memorizzazione nella cache dei metadati del provider impedisce una chiamata di individuazione ogni volta che Microsoft Entra ID comunica con un provider di identità esterno.

Questa cache viene aggiornata ogni 24 ore (un giorno). Ecco come si consiglia a un provider di eseguire il rollover delle chiavi:

1. Pubblicare il certificato esistente e il nuovo certificato nella "jwks_uri".
2. Continuare a firmare con il certificato esistente fino a quando non viene aggiornata, scaduta o aggiornata la cache di Microsoft Entra ID (ogni 2 giorni).
3. Passare alla firma con il nuovo certificato.

Non vengono pubblicate pianificazioni per i rollover delle chiavi. Il servizio dipendente deve essere preparato per gestire sia rollover immediati che periodici. È consigliabile usare una libreria dedicata creata a questo scopo, ad esempio azure-activedirectory-identitymodel-extensions-for-dotnet. Per altre informazioni, vedere Rollover della chiave di firma in Microsoft Entra ID.

Individuazione dei metadati di Microsoft Entra ID

I provider devono anche recuperare le chiavi pubbliche di Microsoft Entra ID per convalidare i token rilasciati da Microsoft Entra ID.

Endpoint di individuazione dei metadati di Microsoft Entra ID:

• Azure globale: https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration
• Azure per il governo degli Stati Uniti: https://login.microsoftonline.us/common/v2.0/.well-known/openid-configuration
• Microsoft Azure gestito da 21Vianet: https://login.partner.microsoftonline.cn/common/v2.0/.well-known/openid-configuration

Usando l'identificatore di chiave pubblica del token (il "kid" da JSON Web Signature (JWS)), è possibile determinare quale delle chiavi recuperate dalla proprietà jwks_uri deve essere usata per convalidare la firma del token ID di Microsoft Entra.

Convalida dei token rilasciati da Microsoft Entra ID

Per informazioni su come convalidare i token emessi da Microsoft Entra ID, vedere Convalida e token ID. Non sono previsti passaggi speciali per i consumer dei metadati di individuazione.

La libreria di convalida dei token di Microsoft include tutti i dettagli sulle specifiche della convalida dei token documentata oppure può essere verificata dall'esplorazione del codice sorgente. Per un esempio, vedere Esempi di Azure.

Al termine della convalida, è possibile usare il payload delle attestazioni per ottenere i dettagli dell'utente e il relativo tenant.

Chiamata id Microsoft Entra al provider di identità esterno

Microsoft Entra ID usa il flusso implicito OIDC per comunicare con il provider di identità esterno. Usando questo flusso, la comunicazione con il provider viene eseguita esclusivamente usando l'endpoint di autorizzazione del provider. Per informare il provider dell'utente per il quale Microsoft Entra ID sta effettuando la richiesta, Microsoft Entra ID passa un token tramite il parametro id_token_hint .

Questa chiamata viene eseguita tramite una richiesta POST perché l'elenco di parametri passati al provider è di grandi dimensioni. Un elenco di grandi dimensioni impedisce l'uso di browser che limitano la lunghezza di una richiesta GET.

I parametri della richiesta di autenticazione sono elencati nella tabella seguente.

Esempio di URI di reindirizzamento

Gli URI (Uniform Resource Identifier) di reindirizzamento devono essere registrati con il provider fuori banda. Gli URI di reindirizzamento che possono essere inviati sono:

• Azure globale: https://login.microsoftonline.com/common/federation/externalauthprovider
• Azure per il governo degli Stati Uniti: https://login.microsoftonline.us/common/federation/externalauthprovider
• Microsoft Azure gestito da 21Vianet: https://login.partner.microsoftonline.cn/common/federation/externalauthprovider

Esempio di EAM che soddisfa l'autenticazione a più fattori

Ecco un esempio di autenticazione in cui un EAM soddisfa l'autenticazione a più fattori. Questo esempio consente a un provider di conoscere le attestazioni previste dall'ID Microsoft Entra.

La combinazione dei acr valori e amr viene usata da Microsoft Entra ID per convalidare:

• Il metodo di autenticazione usato per il secondo fattore soddisfa il requisito MFA
• Il metodo di autenticazione differisce in 'type' dal metodo usato per completare il primo fattore per l'accesso a Microsoft Entra ID

{
  "id_token": {
    "acr": {
      "essential": true,
      "values":["possessionorinherence"]
    },
    "amr": {
      "essential": true,
      "values": ["face", "fido", "fpt", "hwk", "iris", "otp", "pop", "retina", "sc", "sms", "swk", "tel", "vbm"]
    }
  }
}

Attestazioni di Id_token_hint predefinite

Questa sezione descrive il contenuto necessario del token passato come id_token_hint nella richiesta inviata al provider. Il token può contenere più attestazioni rispetto alla tabella seguente.

Per evitare che venga usato per qualsiasi elemento diverso da un suggerimento, il token viene emesso come scaduto. Il token è firmato e può essere verificato usando i metadati di individuazione di Microsoft Entra ID pubblicati.

Attestazioni facoltative da Microsoft Entra ID

Se un provider necessita di attestazioni facoltative da Microsoft Entra ID, è possibile configurare queste attestazioni facoltative per id_token. Per altre informazioni, vedere Attestazioni facoltative.

Uso consigliato delle attestazioni

Microsoft consiglia di associare gli account sul lato provider all'account in Azure AD usando l'oid e le attestazioni tid. Queste due attestazioni sono sicuramente univoche per l'account nel tenant.

Esempio di un id_token_hint

Di seguito è riportato un esempio di id_token_hint per un membro della directory:

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w"
}.{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0",
  "sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA",
  "aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "exp": 1536093790,
  "iat": 1536093791,
  "nbf": 1536093791,
  "name": "Test User 2",
  "preferred_username": "testuser2@contoso.com"
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
  }.

Di seguito è riportato un esempio dell'hint id_token per un utente guest nel tenant:

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w"
}.{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/9122040d-6c67-4c5b-b112-36a304b66dad/v2.0",
  "sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA",
  "aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "exp": 1536093790,
  "iat": 1536093791,
  "nbf": 1536093791,
  "name": "External Test User (Hotmail)",
  "preferred_username": "externaltestuser@hotmail.com",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
  }.

Azioni suggerite per provider di identità esterni

È consigliabile che i provider di identità esterni completino questi passaggi. L'elenco non è esaustivo e i provider devono completare altri passaggi di convalida in base alle esigenze.

1. Dalla richiesta:
   • Assicurarsi che il redirect_uri sia pubblicato nella chiamata MICROSOFT Entra ID al provider di identità esterno.
   • Assicurarsi che il client_id abbia un valore assegnato a Microsoft Entra ID, ad esempio ABCD.
   • Il provider deve prima convalidare il id_token_hint presentato da Microsoft Entra ID.
2. Dalle attestazioni nel id_token_hint:
   • Facoltativamente, possono effettuare una chiamata a Microsoft Graph per recuperare altri dettagli su questo utente. L'oid e le attestazioni tid nel id_token_hint è utile in questo senso. Per informazioni dettagliate sulle attestazioni fornite nella id_token_hint, vedere Attestazioni id_token_hint predefinite.
3. Eseguire quindi qualsiasi altra attività di autenticazione che viene creata dal prodotto del provider.
4. A seconda del risultato delle azioni dell'utente e di altri fattori, il provider crea e invia una risposta all'ID Microsoft Entra, come illustrato nella sezione successiva.

Elaborazione dell'ID Entra di Microsoft per la risposta del provider

Il provider deve inviare una risposta al redirect_uri. Per una risposta corretta, è necessario specificare i parametri seguenti:

In caso di esito positivo, il provider genererà quindi un id_token per l'utente. Microsoft Entra ID usa i metadati OIDC pubblicati per verificare che il token contenga le attestazioni previste ed esegue qualsiasi altra convalida del token richiesto da OIDC.

Attestazioni acr supportate

Attestazioni amr supportate

Microsoft Entra ID richiede che l'autenticazione a più fattori sia soddisfatta per rilasciare un token con attestazioni MFA. Di conseguenza, solo i metodi con un tipo diverso possono soddisfare il secondo requisito del fattore. Come accennato in precedenza, i diversi tipi di metodo che possono essere usati per soddisfare il secondo fattore sono conoscenza, possesso e inherenza.

Microsoft Entra ID convalida il mapping dei tipi in base alla tabella seguente.

Se non vengono rilevati problemi con il token, Microsoft Entra ID considera soddisfatta l'autenticazione a più fattori e rilascia un token all'utente finale. In caso contrario, la richiesta dell'utente finale ha esito negativo.

L'errore è indicato tramite l'emissione di parametri di risposta agli errori.

Microsoft Entra ID considera la richiesta riuscita se il parametro id_token è presente nella risposta e se il token è valido. In caso contrario, la richiesta viene considerata non riuscita. Microsoft Entra ID non riesce il tentativo di autenticazione originale a causa del requisito dei criteri di accesso condizionale.

Microsoft Entra ID abbandona lo stato del tentativo di autenticazione alla fine circa 10 minuti dopo il reindirizzamento al provider.

Gestione delle risposte degli errori di Microsoft Entra ID

I servizi di Microsoft Azure usano un correlationId per correlare le chiamate tra vari sistemi interni ed esterni. Funge da identificatore comune dell'intera operazione o flusso che potenzialmente implica più chiamate HTTP. Quando si verifica un errore durante una qualsiasi delle operazioni, la risposta contiene un campo denominato ID correlazione.

Quando si contatta il supporto Tecnico Microsoft o un servizio simile, fornire il valore di questo ID correlazione in quanto consente di accedere ai dati di telemetria e ai log più velocemente.

Ad esempio:

ENTRA IDSTS70002: errore durante la convalida delle credenziali. ENTRA IDSTS50012: token ID esterno dall'autorità di certificazione 'https://sts.XXXXXXXXX.com/auth/realms/XXXXXXXXXmfa' non riuscita verifica della firma. KeyID del token è 'A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u' Trace ID: 0000aaa-11bb-cccc-dd22-eeeeeee333 ID correlazione333: aaaa0000-bb11-2222-33cc-4444444dddd Timestamp: 2023-07-24 16:51:34Z

Controlli personalizzati ed EAMs

In Microsoft Entra ID, gli EAMs e i controlli personalizzati per l'accesso condizionale possono operare in parallelo mentre i clienti si preparano e e migrano a EAMs.

I clienti che attualmente usano un'integrazione con un provider esterno tramite controlli personalizzati possono continuare a usarli e tutti i criteri di accesso condizionale configurati per gestire l'accesso. Gli amministratori sono consigliati per creare un set parallelo di criteri di accesso condizionale durante il periodo di migrazione:

• I criteri devono usare il controllo Richiedi concessione autenticazione a più fattori anziché la concessione di controllo personalizzata.

  Nota

  Concedere controlli basati sui punti di forza di autenticazione, inclusa la forza MFA predefinita, non vengono soddisfatti dall'EAM. I criteri devono essere configurati solo con Richiedi autenticazione a più fattori. Microsoft sta lavorando attivamente per supportare gli EAM con i punti di forza di autenticazione.

• I nuovi criteri possono essere testati per primi con un subset di utenti. Il gruppo di test verrà escluso dai criteri che richiedono i controlli personalizzati e inclusi nei criteri che richiedono l'autenticazione a più fattori. Quando l'amministratore è a proprio agio che il criterio che richiede L'autenticazione a più fattori è soddisfatto dall'EAM, l'amministratore può includere tutti gli utenti necessari nei criteri con la concessione MFA e i criteri configurati per i controlli personalizzati possono essere spostati su Disattivato.

Supporto per l'integrazione

Se si verificano problemi durante la compilazione dell'integrazione EAM con Microsoft Entra ID, il fornitore di soluzioni indipendenti (ISV) di Microsoft Customer Experience Engineering (CxE) potrebbe essere in grado di assistere. Per contattare il team CxE ISV, inviare una richiesta di assistenza.

Riferimenti

• Specifica OAuth2.0 e OIDC

Glossario

Passaggi successivi

Per altre informazioni su come configurare un EAM nell'interfaccia di amministrazione di Microsoft Entra, vedere Gestire un metodo di autenticazione esterno in Microsoft (anteprima).For more information about how to configure an EAM in Microsoft Entra admin center, see Manage an external authentication method in Microsoft (Preview).