Personalizzare i token

In qualità di sviluppatore, l'interazione principale con Microsoft Entra ID consiste nel richiedere un token per identificare l'utente. È anche necessario richiedere un token per ottenere l'autorizzazione per chiamare un'API Web. Il token API Web determina le operazioni che l'API può eseguire quando esegue la gestione di una determinata richiesta. In questo articolo vengono fornite informazioni sulle informazioni che è possibile ricevere nei token e su come personalizzare i token. Queste procedure consigliate per gli sviluppatori Zero Trust migliorano la flessibilità e il controllo aumentando la sicurezza delle applicazioni con privilegi minimi.

I motivi per personalizzare i token dell'applicazione dipendono dal processo usato per ottenere un'autorizzazione più granulare nelle applicazioni e nelle API. Ad esempio, potresti avere ruoli utente, livelli di accesso e funzionalità diversi nell'app che si basano sulle informazioni dei token.

L'API Microsoft Graph offre un set affidabile di informazioni e dati sulla directory in Microsoft 365. È possibile sviluppare un sistema di autorizzazione con granularità fine e avanzata basandosi sui dati in Microsoft Graph. Ad esempio, è possibile accedere alle informazioni dall'appartenenza al gruppo dell'utente, dai dati dettagliati del profilo, da SharePoint e Outlook da usare nelle decisioni di autorizzazione. È anche possibile includere i dati di autorizzazione nel token da Microsoft Entra ID.

Autorizzazione a livello di applicazione

È possibile che i professionisti IT aggiungano l'autorizzazione a livello di app senza personalizzare il token né avere lo sviluppatore ad aggiungere codice.

I professionisti IT possono impedire che i token vengano rilasciati a qualsiasi app nel tenant usando il flag richiesto di assegnazione utente per garantire che solo un set di utenti sia in grado di accedere all'applicazione. Senza questo flag, tutti gli utenti di un tenant possono accedere all'applicazione. Con questo flag, solo gli utenti e i gruppi assegnati possono accedere all'applicazione. Quando un utente assegnato accede all'app, l'app riceve un token. Se l'utente non ha un'assegnazione, l'app non riceve un token. Ricordarsi di gestire sempre correttamente le richieste di token che non ricevono token.

Metodi di personalizzazione dei token

Esistono due modi per personalizzare i token: attestazioni facoltative e mapping delle attestazioni.

Attestazioni facoltative

Le attestazioni facoltative specificano le attestazioni da inviare all'applicazione tramite l'ID Entra microsoft nei token. Le attestazioni facoltative possono essere usate per:

• Selezionare altre attestazioni da includere nei token dell'applicazione.
• Modificare il comportamento delle attestazioni restituite da Microsoft Identity Platform nei token.
• Aggiungere e accedere ad attestazioni personalizzate per l'applicazione.

Le attestazioni facoltative si bloccano dall'oggetto di registrazione dell'applicazione con uno schema definito. Si applicano all'applicazione indipendentemente dalla posizione in cui è in esecuzione. Quando si scrive un'applicazione multi-tenant, le attestazioni facoltative funzionano correttamente perché sono coerenti in ogni tenant in Microsoft Entra ID. Ad esempio, un indirizzo IP non è specifico del tenant, mentre un'applicazione ha un indirizzo IP.

Per impostazione predefinita, gli utenti guest in un tenant possono anche accedere all'app. Se si vuole bloccare gli utenti guest, acconsentire esplicitamente all'attestazione facoltativa (acct). Se è 1, l'utente ha una classificazione guest. Se si vuole bloccare i guest, bloccare i token con acct==1.

Criteri di mapping delle attestazioni

In Microsoft Entra ID gli oggetti criteri rappresentano set di regole per singole applicazioni o per tutte le applicazioni di un'organizzazione. Un criterio di mapping delle attestazioni modifica le attestazioni che Microsoft Entra ID rilascia nei token per applicazioni specifiche.

Si usa il mapping delle attestazioni per informazioni specifiche del tenant che non hanno uno schema, ad esempio EmployeeID, DivisionName. Il mapping delle attestazioni si applica a livello di entità servizio che l'amministratore tenant controlla. Il mapping delle attestazioni corrisponde all'app aziendale o all'entità servizio per l'applicazione. Ogni tenant può avere il proprio mapping delle attestazioni.

Se si sviluppa un'applicazione line-of-business, è possibile esaminare in modo specifico le operazioni del tenant (quali attestazioni specifiche sono disponibili per il tenant che è possibile usare nel token). Ad esempio, se un'organizzazione dispone della proprietà nome di divisione di un utente (non di un campo standard in MICROSOFT Entra ID) nel proprio Active Directory locale, è possibile usare Microsoft Entra Connessione per sincronizzarlo con Microsoft Entra ID.

È possibile usare uno degli attributi di estensione standard per contenere tali informazioni. È possibile definire il token con un'attestazione del nome di divisione che è possibile comporre dall'estensione corrispondente (anche se non si applica in ogni tenant). Ad esempio, un'organizzazione inserisce il nome della divisione nell'attributo di estensione 13.

Con il mapping delle attestazioni, è possibile renderlo funzionante per un altro tenant che inserisce il nome della divisione nell'attributo sette.

Pianificare la personalizzazione dei token

Il token personalizzato dipende dal tipo di applicazione: applicazione client o API. Non esiste alcuna differenza nelle operazioni che è possibile eseguire per personalizzare il token. Ciò che è possibile inserire nel token è lo stesso per ognuno di essi. Il token che si sceglie di personalizzare dipende dal token usato dall'app.

Personalizzare i token ID

Se si sviluppa un'applicazione client, si personalizza il token ID perché è il token richiesto per identificare l'utente. Un token appartiene all'app quando l'attestazione del gruppo di destinatari (aud) nel token corrisponde all'ID client dell'applicazione. Per un'applicazione client che chiama le API ma non le implementa, assicurarsi di personalizzare solo il token ID dell'app.

La portale di Azure e l'API Microsoft Graph consentono di personalizzare anche il token di accesso per l'app, ma tali personalizzazioni non hanno alcun effetto. Non è possibile personalizzare un token di accesso per un'API di cui non si è proprietari. Tenere presente che l'app non deve tentare di decodificare o controllare un token di accesso ricevuto dall'app client come autorizzazione per chiamare un'API.

Personalizzare i token di accesso

Se si sviluppa un'API, si personalizza il token di accesso perché l'API riceve i token di accesso come parte della chiamata del client all'API.

Le applicazioni client personalizzano sempre il token ID ricevuto per l'identità dell'utente. Le API personalizzano i token di accesso ricevuti dall'API come parte della chiamata all'API.

Gruppi e ruoli dell'app

Una delle tecniche di autorizzazione più comuni consiste nell'eseguire l'accesso in base all'appartenenza a un gruppo o ai ruoli assegnati di un utente. Configurare le attestazioni di gruppo e i ruoli dell'app nei token illustra come configurare le app con definizioni di ruolo dell'app e assegnare gruppi di sicurezza ai ruoli dell'app. Questi metodi consentono di migliorare la flessibilità e il controllo aumentando la sicurezza senza attendibilità delle applicazioni con privilegi minimi.

Passaggi successivi

• Il mapping delle attestazioni utente di Collaborazione B2B descrive il supporto di Microsoft Entra ID per personalizzare le attestazioni rilasciate nel token SAML (Security Assertion Markup Language) per gli utenti di Collaborazione B2B.
• Personalizzare le attestazioni del token SAML dell'app quando un utente esegue l'autenticazione a un'applicazione tramite Microsoft Identity Platform usando il protocollo SAML 2.0.
• Protezione API descrive le procedure consigliate per proteggere l'API tramite la registrazione, la definizione di autorizzazioni e il consenso e l'applicazione dell'accesso per raggiungere gli obiettivi zero trust.
• Le procedure consigliate per l'autorizzazione consentono di implementare i modelli di autorizzazione, autorizzazione e consenso ottimali per le applicazioni.
• Usare le procedure consigliate per lo sviluppo di identità Zero Trust e di gestione degli accessi nel ciclo di vita di sviluppo delle applicazioni per creare applicazioni sicure.