Concetti relativi ad AD FS OpenID Connect/OAuth

Si applica ad Active Directory Federation Services (AD FS) 2016 e versioni successive

Attori di autenticazione moderni

Il diagramma seguente fornisce la relazione più semplice tra gli attori:

Tipi di applicazione

Gruppo di applicazioni

È necessario associare un gruppo di applicazioni a ogni client OAuth nativo o app Web o a una risorsa API Web configurata con AD FS. Configurare i client in un gruppo di applicazioni per accedere alle risorse nello stesso gruppo. Un gruppo di applicazioni può avere più client e risorse.

Token di sicurezza

L'autenticazione moderna usa i seguenti tipi di token:

• id_token: token JWT rilasciato dal server di autorizzazione (AD FS) e utilizzato dal client. Le attestazioni nel token ID contengono informazioni sull'utente in modo che il client possa usarlo.
• access_token: token JWT rilasciato dal server di autorizzazione (AD FS) e destinato a essere utilizzato dalla risorsa. L'attestazione 'aud' o audience di questo token deve corrispondere all'identificatore della risorsa o dell'API Web.
• refresh_token: rilasciato da AD FS per il client da usare quando deve aggiornare il id_token e access_token. Il token è opaco per il client e utilizzato solo da AD FS.

Durata dei token di aggiornamento

• Accesso semplice, senza KMSI, dispositivo non registrato: AD FS applica SsoLifetime e DeviceUsageWindowInDays. Il primo token di aggiornamento ha lifetime=DeviceUsageWindowInDays o SsoLifetime, in base al campo inferiore ma non vengono rilasciati altri token di aggiornamento.
• Accesso KMSI, EnableKmsi=true in AD FS conf e kmsi=true passati come parametro: AD FS applica KmsiLifetimeMins con DeviceUsageWindowInDays. Il primo token di aggiornamento ha lifetime=DeviceUsageWindowInDays e ogni richiesta di grant_type=refresh_token successiva ottiene un nuovo token di aggiornamento. Questo processo avviene solo con client nativi o client riservati e l'autenticazione del dispositivo.
• Dispositivi registrati, autenticazione del dispositivo: AD FS usa PersistentSsoLifetimeMins e DeviceUsageWindowInDays simili a KMSI. I client nativi e riservati devono ottenere nuovi token di aggiornamento, in base all'autenticazione del dispositivo.

Per altre informazioni, vedere la documentazione sull'accesso Single Sign-On di AD FS.

Ambiti

Quando si registra una risorsa in AD FS, è possibile configurare gli ambiti per consentire ad AD FS di eseguire azioni specifiche. Oltre a configurare l'ambito, è necessario inviare il valore di ambito nella richiesta di AD FS per eseguire l'azione. Ad esempio, un amministratore configura l'ambito come openid durante la registrazione delle risorse e l'applicazione (client) deve inviare scope = openid nella richiesta di autenticazione per AD FS per rilasciare il token ID. Di seguito sono riportati i dettagli sugli ambiti disponibili in AD FS:

• aza - Se si usano le estensioni del protocollo OAuth 2.0 per i client broker e se il parametro di ambito contiene l'ambito aza, il server rilascia un nuovo token di aggiornamento primario. Imposta il token nel campo refresh_token della risposta e imposta refresh_token_expires_in field sulla durata del nuovo token di aggiornamento primario, se ne viene applicata una.
• openid : consente all'applicazione di richiedere l'uso del protocollo di autenticazione di connessione openid.
• logon_cert - Consente a un'applicazione di richiedere certificati di accesso che è possibile usare per accedere in modo interattivo agli utenti autenticati. Il server AD FS omette il parametro access_token dalla risposta e fornisce invece una catena di certificati CMS con codifica Base64 o una risposta PKI completa CMC. Per altre informazioni, vedere MS-OAPX: estensioni del protocollo OAuth 2.0.
• user_impersonation - Richiede un token di accesso on-behalf-of da AD FS. Per informazioni dettagliate su come usare questo ambito, vedere Creare un'applicazione multilivello usando On-Behalf-Of (OBO) usando OAuth con AD FS 2016.
• allatclaims - Consente all'applicazione di richiedere anche le attestazioni nel token di accesso da aggiungere al token ID.
• vpn_cert - Consente a un'applicazione di richiedere certificati VPN, che stabiliscono connessioni VPN usando l'autenticazione EAP-TLS. Questa funzionalità non è più supportata.
• email - Consente all'applicazione di richiedere un'attestazione di posta elettronica per l'utente connesso.
• profile - Consente all'applicazione di richiedere attestazioni correlate al profilo per l'utente connesso.

Richieste di rimborso

I token di sicurezza (token di accesso e ID) emessi da AD FS contengono attestazioni o asserzioni di informazioni sull'oggetto autenticato. Le applicazioni possono usare le attestazioni per varie attività, tra cui:

• Convalidare il token
• Identificare il tenant di directory dell'oggetto
• Visualizzare le informazioni utente
• Determinare l'autorizzazione dell'oggetto

Le attestazioni presenti in un determinato token di sicurezza dipendono dal tipo di token, dal tipo di credenziali usate per autenticare l'utente e dalla configurazione dell'applicazione.

Flusso di autenticazione di AD FS di alto livello

Di seguito è riportato un diagramma del flusso generale.

1. AD FS riceve la richiesta di autenticazione dal client.

2. AD FS convalida l'ID client nella richiesta di autenticazione con l'ID client ottenuto durante la registrazione del client e della risorsa in AD FS. Se si usa il client riservato, AD FS convalida anche il segreto client fornito nella richiesta di autenticazione. AD FS convalida anche l'URI di reindirizzamento del client.

3. AD FS identifica la risorsa a cui il client vuole accedere tramite il parametro della risorsa passato nella richiesta di autenticazione. Se si usa la libreria client MSAL, il parametro della risorsa non viene inviato. L'URL della risorsa viene invece inviato come parte del parametro scope: scope = [url risorsa]/[valori di ambito, ad esempio openid].

   Se la risorsa non viene passata usando i parametri della risorsa o dell'ambito, AD FS usa una risorsa predefinita urn:microsoft:userinfo i cui criteri, ad esempio, MFA, rilascio o criteri di autorizzazione, non possono essere configurati.

4. Ad FS verifica quindi se il client dispone delle autorizzazioni per accedere alla risorsa. AD FS convalida anche se gli ambiti passati nella richiesta di autenticazione corrispondono agli ambiti configurati durante la registrazione della risorsa. Se il client non dispone delle autorizzazioni o gli ambiti corretti non vengono inviati nella richiesta di autenticazione, il flusso di autenticazione termina.

5. Dopo aver convalidato le autorizzazioni e gli ambiti, AD FS autentica l'utente usando il metodo di autenticazione configurato.

6. Se è necessario un altro metodo di autenticazione in base ai criteri di risorsa o ai criteri di autenticazione globali, AD FS attiva l'autenticazione aggiuntiva.

7. AD FS utilizza l'autenticazione a più fattori di Microsoft Entra o l'autenticazione a più fattori di terze parti per eseguire l'autenticazione.

8. Dopo l'autenticazione dell'utente, AD FS applica le regole di attestazione. Le regole di attestazione determinano le attestazioni inviate alla risorsa come parte dei token di sicurezza. AD FS applica anche i criteri di controllo di accesso che confermano che l'utente soddisfa le condizioni necessarie per accedere alla risorsa.

9. AD FS genera quindi l'accesso e aggiorna i token. AD FS genera anche il token ID.

10. AD FS riceve la richiesta di autenticazione.

11. Se si include scope = allatclaims nella richiesta di autenticazione, il token ID viene personalizzato in modo da includere le attestazioni nel token di accesso in base alle regole di attestazione definite.

12. Dopo aver generato e personalizzato i token necessari, AD FS risponde al client e include i token. La risposta del token ID è inclusa nella risposta solo se la richiesta di autenticazione include scope = openid. Il client può sempre ottenere il token ID dopo l'autenticazione usando l'endpoint del token.

Tipi di librerie

Usare due tipi di librerie con AD FS:

• Librerie client: i client nativi e le app server usano librerie client per ottenere i token di accesso per chiamare una risorsa, ad esempio un'API Web. Microsoft Authentication Library (MSAL) è la libreria client più recente e consigliata quando si usa AD FS 2019.

• Librerie middleware server: le app Web usano librerie middleware server per l'accesso degli utenti. Le API Web usano librerie middleware server per convalidare i token inviati da client nativi o da altri server. Open Web Interface for .NET (OWIN) è la libreria middleware consigliata.

Personalizzare il token ID (attestazioni aggiuntive nel token ID)

In alcuni scenari, è possibile che il client dell'app Web richieda attestazioni aggiuntive in un token ID per facilitare la funzionalità. Configurare attestazioni aggiuntive in un token ID usando una delle opzioni seguenti:

Opzione 1: usare questa opzione quando si dispone di un client pubblico e l'app Web non dispone di una risorsa a cui sta provando ad accedere. Questa opzione richiede:

• response_mode è impostato come form_post
• L'identificatore della relying party (identificatore API Web) corrisponde all'identificatore client

Opzione 2: usare questa opzione quando l'app Web ha una risorsa a cui sta tentando di accedere e deve passare attestazioni aggiuntive tramite il token ID. È possibile usare client pubblici e riservati. Questa opzione richiede:

• response_mode è impostato come form_post

• KB4019472 è installato nei server AD FS

• L'ambito allatclaims viene assegnato alla coppia client - RP. È possibile assegnare l'ambito usando Grant-ADFSApplicationPermission. Usare Set-AdfsApplicationPermission se è già stato concesso una volta. Il cmdlet di PowerShell è indicato nell'esempio seguente:

  Grant-AdfsApplicationPermission -ClientRoleIdentifier "https://my/privateclient" -ServerRoleIdentifier "https://rp/fedpassive" -ScopeNames "allatclaims","openid"
  

Per comprendere meglio come configurare un'app Web in AD FS per ottenere un token ID personalizzato, vedere Token ID personalizzati in AD FS 2016 o versione successiva.

Disconnessione singola

La singola disconnessione termina tutte le sessioni client che usano l'ID sessione. AD FS 2016 e versioni successive supportano una singola disconnessione per OpenID Connect/OAuth. Per altre informazioni, vedere Disconnessione singola per OpenID Connect con AD FS.

Endpoint AD FS