Condividi tramite

Stabilire applicazioni nell'ecosistema Microsoft Entra ID

Quando si creano applicazioni in Microsoft Entra ID, si stabilisce prima di tutto un'identità per un'applicazione. Un'app necessita di un'identità in Microsoft Entra ID per richiedere i token. Un'API (Application Programming Interface) richiede un'identità in Microsoft Entra ID per avere token emessi per consentire alle app di accedere alle risorse.

Questo articolo illustra come registrare le app in un tenant di Microsoft Entra ID nell'interfaccia di amministrazione di Microsoft Entra o con l'API Microsoft Graph. Si tratta del secondo di una serie di articoli sul modo in cui i fornitori di software indipendenti (ISV) possono creare e ottimizzare le applicazioni per Microsoft Entra ID. In questa serie sono disponibili altre informazioni sugli argomenti seguenti:

  • Microsoft Entra ID per Fornitori di software indipendenti descrive come utilizzare questo servizio di gestione delle identità e degli accessi basato sul cloud per consentire ai dipendenti di accedere alle risorse con l'applicazione.
  • Autenticare le applicazioni e gli utenti descrive il modo in cui le applicazioni usano Microsoft Entra ID per autenticare utenti e applicazioni.
  • Autorizzazione di applicazioni, risorse e carichi di lavoro tratta il tema dell'autorizzazione nei casi in cui degli individui interagiscono con un'applicazione e la dirigono,quando le API agiscono per conto di un utente e le applicazioni o i servizi funzionano in modo indipendente.
  • Personalizzazione dei token descrive come sia possibile integrare la sicurezza nelle applicazioni con i token ID e i token di accesso di Microsoft Entra ID. Vengono illustrate le informazioni che è possibile ricevere nei token di Microsoft Entra ID e come sia possibile personalizzarle.

Registrare le applicazioni

Gli sviluppatori possono registrare applicazioni come app multi-tenant e a tenant singolo. Per gli ISV, è consigliabile usare app multi-tenant. Un'app multi-tenant ha una singola registrazione dell'app che un ISV controlla e registra completamente nel tenant. Informazioni su come creare un tenant di Microsoft Entra ID per registrare l'app.

Per fornire soluzioni a qualsiasi cliente che esegue Microsoft Entra ID e avere un'esperienza perfetta per l'onboarding nel tenant Microsoft Entra ID del cliente, passare all'interfaccia di amministrazione di Microsoft Entra, Registrazioni app, Registra un'applicazione. In questa nuova registrazione dell'app selezionare Tipi di account supportati, Account in qualsiasi directory organizzativa (qualsiasi tenant Microsoft Entra ID--Multitenant) o Account in qualsiasi directory organizzativa (Qualsiasi tenant-Multitenant Microsoft Entra ID) e account Microsoft personali (ad esempio, Skype, Xbox).

Screenshot delle opzioni di configurazione dell'applicazione nell'interfaccia di amministrazione di Microsoft Entra.

L'onboarding di un'app multi-tenant in un tenant esterno può essere semplice come l'esecuzione di un'app e l'accesso dell'utente all'app. Quando il tenant permette il consenso utente (gli utenti possono accedere alle app senza che un amministratore approvi un'app in precedenza), l'onboarding di un'app richiede solo che un utente ci acceda. Questo workshop sulle identità per sviluppatori (time code da 1:05:20 a 1:08:00) mostra un'app di cui viene eseguito l'onboarding in un tenant quando un utente accede a un'app.

Quando si registra un'app in un tenant di Microsoft Entra ID, questa riceve un ID applicazione (ID app) noto anche come ID client per un'app. È come un userid per un utente poichè identifica in modo univoco un'app. L'ID app è globalmente univoco nel cloud di Microsoft Entra ID e non è modificabile. Tutte le interazioni tra un'app e l'ID Microsoft Entra includono l'ID app.

Oltre all'ID app, una registrazione delle app contiene informazioni sull'app che gli sviluppatori di app conoscono o devono conoscere. Ad esempio, uno sviluppatore di app deve conoscere l'ID app per interagire con Microsoft Entra ID. Lo sviluppatore conosce il tipo di applicazione che sta creando (app Web, nativa, a pagina singola, per dispositivi mobili o desktop). I tipi di applicazione hanno attributi obbligatori.

Ad esempio, un attributo dell'applicazione obbligatorio è un URI (Redirect Uniform Resource Identifier). L'attributo indica a Microsoft Entra ID l'indirizzo Web o l'indirizzo dell'app nativa da inviare a un utente dopo l'autenticazione o l'autorizzazione. Lo sviluppatore conosce gli URI di reindirizzamento di un'applicazione in base al tipo di app e alla posizione in cui viene eseguita.

Il manifesto di un'app (a cui si accede dall'interfaccia di amministrazione di Microsoft Entra o con un'API Microsoft Graph) archivia i numerosi attributi dell'applicazione. Informazioni sul manifesto dell'app Microsoft Entra per informazioni sugli attributi dell'app e sui relativi valori consentiti.

Esempi di codice di riferimento per l'autenticazione e l'autorizzazione di Microsoft Identity Platform per individuare le impostazioni consigliate per le app in fase di sviluppo. Trovare un esempio di applicazione simile all'app che si sta creando e leggere la relativa documentazione. Esempi di dettaglio delle impostazioni di registrazione dell'app necessarie per tipo di app. Ad esempio, se si sta creando un'API in Node.js, è possibile trovare esempi che portano a queste istruzioni di registrazione.

Una registrazione dell'app comunica ciò che uno sviluppatore sa. In ogni tenant da cui gli utenti possono eseguire l'autenticazione all'app multi-tenant, gli amministratori tenant configurano il modo in cui le applicazioni vengono eseguite nel tenant. Ad esempio, un amministratore tenant può impostare criteri di accesso condizionale che limitano un'app a percorsi di rete specifici. Inoltre, possono essere presenti criteri di accesso condizionale per richiedere l'autenticazione a più fattori (MFA) e consentire a un utente di accedere a un'app o alle impostazioni dell'app che consentono a utenti o gruppi specifici di usarla.

Per abilitare tali limitazioni, gli amministratori del tenant devono avere punti di controllo per le app nel tenant. Microsoft Entra ID crea automaticamente un'applicazione aziendale in ogni tenant in cui un utente autentica un'app. Nell'interfaccia di amministrazione di Microsoft Entra sono denominate Applicazioni aziendali, ma gli oggetti sono entità servizio. Altre informazioni sulle app e sulle entità servizio in Microsoft Entra ID.

Dopo che un utente autentica un'app, Microsoft Entra ID crea un'entità servizio nel tenant da cui l'utente ha eseguito l'autenticazione. Gli amministratori tenant possono usare l'oggetto entità servizio in Microsoft Graph (o nell'interfaccia di amministrazione di Microsoft Entra, Applicazioni aziendali) per configurare il funzionamento di un'app nel tenant.

Le entità servizio non sono copie di una registrazione dell'app anche se hanno molti degli stessi attributi. Un'entità servizio collega invece alla registrazione dell'app. È possibile visualizzare gli aggiornamenti alle registrazioni delle app nelle applicazioni aziendali collegate. Per le app multi-tenant, il cliente non ha accesso alle registrazioni delle app che rimangono nel tenant dell'ISV. Tuttavia, un'applicazione può accedere all'entità servizio usando Microsoft Graph anche quando tale entità servizio si trova in un tenant diverso. Un'app può quindi accedere agli attributi relativi all'applicazione aziendale, ad esempio se richiede l'assegnazione dell'utente a un'app o degli utenti a un ruolo nell'app.

Sebbene sia consigliabile usare app multi-tenant per la registrazione delle app per ISV, un'app a tenant singolo è un'altra opzione per la registrazione delle app. Invece di una singola registrazione dell'app nel tenant dell'ISV in cui l'ISV controlla completamente la registrazione, è possibile chiedere ai clienti di registrare l'app nel tenant per l'app. Al termine della registrazione, il cliente configura l'istanza dell'app con i dettagli della sua registrazione. È consigliabile usare questo approccio per le app a tenant singolo principalmente per le applicazioni line-of-business sviluppate per aziende specifiche.

A causa del sovraccarico dovuto alla registrazione e alla configurazione dell'applicazione da parte dei clienti, non è consigliabile usare app a tenant singolo per ISV. Esistono tuttavia scenari per i quali un'app multi-tenant non è possibile per l'app.

Se l'app usa Security Assertion Markup Language 2.0 (SAML), anziché OpenID Connect (OIDC) o OAuth 2.0, segue un modello di registrazione delle app a tenant singolo. Per le app SAML, l'ordine di creazione di entità servizio e registrazione dell'app è l'opposto di un'app OIDC o OAuth 2.0, almeno per l'amministratore che aggiunge l'app SAML al tenant. Anziché registrare un'app e fare creare automaticamente l'entità servizio a Microsoft Entra ID, gli amministratori iniziano creando un'app Enterprise. Microsoft Entra ID crea automaticamente la registrazione dell'app. La raccolta di app Microsoft Entra ID, descritta nella sezione Pubblicazione di applicazioni, semplifica il processo di creazione dell'app SAML per gli amministratori.

Le limitazioni relative agli URI (Uniform Resource Identifier) di reindirizzamento possono impedire a un ISV di creare un'app multi-tenant. Un'app può avere al massimo 256 URI di reindirizzamento, senza caratteri jolly. Se l'applicazione richiede un URI di reindirizzamento univoco per ogni cliente e sono presenti più di 256 clienti che richiedono un'istanza univoca, potrebbe non essere possibile creare un'app multi-tenant. Non è possibile usare i caratteri jolly (*) negli URI di reindirizzamento Microsoft Entra ID per motivi di sicurezza. Un'opzione consiste nel disporre di un singolo URI di reindirizzamento per il servizio centrale (se è possibile un servizio centrale). L'URI di reindirizzamento centrale convalida il token e quindi reindirizza l'utente all'endpoint specifico del cliente.

Pubblicare applicazioni

Quando gli utenti autenticano inizialmente l'app o autorizzano un'app ad accedere a una risorsa per l'utente, decidono se considerano attendibile l'app. Gli amministratori possono prendere decisioni simili per tutti gli utenti nel tenant. Gli amministratori possono decidere se un utente accede a un'app e se un'app accede a risorse specifiche.

I metodi di pubblicazione dell'app seguenti consentono agli ISV di presentare le proprie app come meritevoli della fiducia degli utenti e degli amministratori.

  • Pubblicare l'app da un dominio verificato. Il dominio di pubblicazione informa gli utenti e gli amministratori delle posizioni che ricevono le informazioni. La pubblicazione da un dominio di pubblicazione verificato mostra che il tenant registrato di un'app ha il controllo del dominio elencato come autore di un'app.
  • Pubblicare l'app con la verifica dell'autore. Avere un dominio di pubblicazione verificato è un prerequisito per la verifica dell'autore, che va oltre il mostrare semplicemente che un autore di app ha il controllo su un dominio. La verifica dell'autore mostra che Microsoft ha verificato l'entità dietro il dominio e il tenant come autentica. Gli utenti che non sono amministratori spesso non considerano attendibili le app multi-tenant di autori non verificati. Gli amministratori possono configurare i tenant in modo che le app non provenienti da autori verificati richiedano sempre il consenso amministratore. La verifica dell'autore è principalmente per gli ISV che creano app multi-tenant in OAuth 2.0 e OIDC. Gli autori verificati sono membri del Programma Microsoft Cloud Partner. La verifica dell'autore non influisce sulle app a tenant singolo, ad esempio quelle che usano app SAML o Line of Business.
  • Pubblicare l'app nella raccolta di app Microsoft Entra ID. È possibile richiedere a Microsoft di elencare le app usando SAML 2.0 e quelle che usano OAuth 2.0 e OIDC nella raccolta di app Microsoft Entra ID. Gli amministratori trovano app preintegrate nella raccolta di app Microsoft Entra ID dall'interfaccia di amministrazione di Microsoft Entra, Applicazioni aziendali, Nuove applicazioni. La pubblicazione dell'app nella raccolta di app Microsoft Entra ID semplifica e riduce al minimo la relativa configurazione. Microsoft testa le applicazioni e fornisce la verifica della compatibilità, particolarmente utile per le app che usano SAML 2.0 e richiedono la configurazione prima dell'uso. È possibile usare l'implementazione di System for Cross-Domain Identity Management (SCIM) 2.0 dell'app per configurare l'app della raccolta di app per il provisioning Vedere la sezione Provisioning automatico. Per iniziare, inviare una richiesta per pubblicare l'applicazione. È possibile ottenere l'accesso Single Sign-On e il provisioning utenti usando SCIM con una singola applicazione nella raccolta di app.
  • Partecipare al programma di conformità delle app di Microsoft 365. L'uso di un dominio verificato indica che si ha il controllo sul dominio. La verifica dell'autore mostra che Microsoft ha verificato l'organizzazione come autentica. La presentazione dell'app nella raccolta di app Microsoft Entra ID mostra che l'app funziona con Microsoft Entra ID per semplificare l'onboarding. Il programma di conformità Microsoft 365 consente di informare i clienti sulla sicurezza e la conformità dell'app tramite l'attestazione dell'autore, la certificazione Microsoft 365 o con lo strumento di automazione della conformità delle app (ACAT) in Azure. Illustra come l'applicazione protegge le risorse a cui il cliente autorizza l'app ad accedere.

Provisioning automatico

Il provisioning delle app in Microsoft Entra ID può effettuare automaticamente il provisioning di identità utente, oggetti di gruppo e ruoli nelle applicazioni cloud a cui gli utenti devono accedere. Oltre a creare oggetti utente e gruppo, il provisioning automatico include la manutenzione e la rimozione dell'identità utente durante la modifica dello stato o dei ruoli. Il servizio di provisioning Di Microsoft Entra effettua automaticamente il provisioning di utenti e gruppi alle applicazioni chiamando un endpoint dell'API di gestione degli oggetti SCIM fornito da un'applicazione.

Per gli ISV, i vantaggi del provisioning delle app in Microsoft Entra ID includono quanto segue.

  • Il provisioning nell'applicazione con Microsoft Graph è possibile, la creazione di un endpoint SCIM consente il provisioning per l'uso con provider di identità (IdP) che supporta SCIM. La maggior parte degli IdP supporta il protocollo di provisioning SCIM.
  • Il provisioning è un'operazione di sincronizzazione in cui i dati si sincronizzano tra Microsoft Entra ID e un'applicazione. Per implementare una soluzione di sincronizzazione basata su Microsoft Graph, un'app richiede l'accesso a tutti gli attributi di tutti gli utenti e i gruppi nel tenant. Alcuni clienti di Microsoft Entra ID sono riluttanti a consentire un accesso così ampio. Con SCIM, un amministratore può selezionare gli attributi che Microsoft Entra ID sincronizza con un'applicazione. Molti amministratori preferiscono poter disporre di questo controllo con granularità fine disponibile solo con un'implementazione SCIM.
  • La creazione di un servizio di sincronizzazione Microsoft Graph per il provisioning significa che è necessario gestire tale servizio e implementare un modello di pull per monitorare Microsoft Entra ID per le modifiche. Quando si implementa un endpoint SCIM, Microsoft Entra ID gestisce la gestione del servizio di provisioning ed esegue il push delle modifiche all'app.

Usare SCIM, Microsoft Graph e Microsoft Entra ID per effettuare il provisioning degli utenti e arricchire le app con i dati fornisce indicazioni su quando usare SCIM e quando usare Microsoft Graph. Documentazione utente Microsoft per pianificare, compilaree convalidare l'endpoint SCIM con Microsoft Entra ID e risolvere i problemi noti relativi alla conformità SCIM.

Oltre a sincronizzare i dati con le applicazioni, Microsoft Entra ID offre il provisioning con applicazioni RU (risorse umane) basate sul cloud. Il provisioning basato su risorse umane è il processo di creazione di identità digitali basate su una soluzione di gestione delle risorse umane (RU). I sistemi RU diventano lo Start of Authority per queste nuove identità digitali create e rappresentano spesso il punto iniziale per numerosi processi di provisioning. Le soluzioni HR locali possono usare Microsoft Identity Manager per effettuare il provisioning degli utenti in un'istanza locale di Active Directory. Possono quindi eseguire la sincronizzazione a Microsoft Entra ID con Microsoft Entra Connect o direttamente a Microsoft Entra ID.

Con il provisioning in ingresso basato sulle API, gli ISV HR basati sul cloud possono offrire esperienze di sincronizzazione native in modo che le modifiche nel sistema HR vengano automaticamente propagate in Microsoft Entra ID e domini di Active Directory locali connessi. Ad esempio, un'app RU o un'app per i sistemi informatici degli studenti può inviare dati a Microsoft Entra ID non appena una transazione viene completata o come aggiornamento bulk di fine giornata. Per iniziare a conoscere i concetti relativi al provisioning in ingresso basato sulle API, esaminare la funzionalità bulkUpload in Microsoft Graph e acquisire familiarità con i concetti, gli scenari e le limitazioni del provisioning basati sulle API.

Passaggi successivi