Pianificare la strategia di registrazione delle applicazioni line-of-business

  • 2 minuti

Questa unità esamina perché le applicazioni si integrano con Microsoft Entra ID. Aggiungere le applicazioni a Microsoft Entra ID per sfruttare uno o più dei servizi offerti, tra cui:

  • Autenticazione e autorizzazione delle applicazioni.
  • Autenticazione e autorizzazione degli utenti.
  • Accesso Single Sign-On (SSO) tramite federazione o password.
  • Provisioning e sincronizzazione degli utenti.
  • Controllo degli accessi in base al ruolo: usare la directory per definire i ruoli applicazione al fine di eseguire i controlli di autorizzazione in base al ruolo in un'applicazione.
  • Servizi di autorizzazione OAuth: servizi usati da Microsoft 365 e altre applicazioni Microsoft per autorizzare l'accesso ad API e risorse.
  • Proxy e pubblicazione delle applicazioni: pubblicare un'applicazione in Internet da una rete privata.
  • Attributi dell'estensione dello schema della directory: estendere lo schema delle entità servizio e degli oggetti utente per archiviare dati aggiuntivi in Microsoft Entra ID.

In Microsoft Entra ID ci sono due rappresentazioni delle applicazioni: gli oggetti applicazione e le entità servizio. Le due sezioni seguenti illustrano ognuna di queste rappresentazioni e il modo in cui interagiscono tra loro nel portale di Azure.

Cosa sono gli oggetti applicazione e da dove provengono?

È possibile gestire gli oggetti applicazione nel portale di Azure tramite l'esperienza Registrazioni per l'app. Gli oggetti applicazione definiscono e descrivono l'applicazione in Microsoft Entra ID per consentire al provider di identità di sapere come rilasciare i token per l'applicazione in base alle relative impostazioni. L'oggetto applicazione è disponibile solo nella relativa directory home, anche se si tratta di un'applicazione multi-tenant che supporta entità servizio in altre directory. L'oggetto applicazione include qualsiasi elemento seguenti (come anche informazioni aggiuntive non menzionate qui):

  • Nome, logo ed editore
  • URI di reindirizzamento
  • Segreti (chiavi simmetriche e/o asimmetriche usate per autenticare l'applicazione)
  • Dipendenze API (OAuth)
  • API/risorse/ambiti pubblicati (OAuth)
  • Ruoli app (Controllo degli accessi in base al ruolo)
  • Configurazione e metadati SSO
  • Metadati e configurazione del provisioning utenti
  • Metadati e configurazione proxy

È possibile creare oggetti applicazione in diversi modi, tra cui:

  • Registrazioni delle applicazioni nel portale di Azure.
  • Creazione di una nuova applicazione con Visual Studio e configurazione dell'applicazione per l'uso dell'autenticazione di Microsoft Entra.
  • Aggiunta di un'applicazione dalla raccolta di app da parte di un amministratore (in questo caso viene creata anche un'entità servizio).
  • Uso dell'API Microsoft Graph o di PowerShell per creare una nuova applicazione.
  • Molti altri metodi, incluse le diverse esperienze di sviluppo in Azure e le esperienze in Esplora API nei centri per sviluppatori.

Cosa sono le entità servizio e da dove provengono?

È possibile gestire le entità servizio nel portale di Azure tramite l'esperienza Applicazioni aziendali. Le entità servizio governano un'applicazione che si connette a Microsoft Entra ID e possono essere considerate come l'istanza dell'applicazione nella directory. Per ogni applicazione specifica possono esserci al massimo un oggetto applicazione (registrato in una "home" directory) e uno o più oggetti entità servizio che rappresentano le istanze dell'applicazione in ogni directory in cui è in funzione.

L'entità servizio può includere:

  • Un riferimento a un oggetto applicazione tramite la proprietà ID applicazione.

  • Record delle assegnazioni di ruolo dell'applicazione a gruppi e utenti locali.

  • Record delle autorizzazioni amministratore e utente locali concesse all'applicazione.

    • Ad esempio, l'autorizzazione dell'applicazione ad accedere a un indirizzo e-mail di un utente specifico.

  • Record dei criteri locali, inclusi i criteri di accesso condizionale.

  • Record delle impostazioni locali alternative per un'applicazione.

    • Regole di trasformazione delle attestazioni.
    • Mapping degli attributi (provisioning utenti).
    • Ruoli dell'app specifici della directory (se l'applicazione supporta i ruoli personalizzati).
    • Nome o logo specifico della directory.

Analogamente agli oggetti applicazione, anche gli oggetti entità servizio possono essere creati in diversi modi, tra cui i seguenti:

  • Quando gli utenti accedono a un'applicazione di terze parti integrata con Microsoft Entra ID.

    • Durante la procedura di accesso, agli utenti viene chiesto di concedere all'applicazione l'autorizzazione ad accedere al proprio profilo e altri tipi di autorizzazioni. Quando viene dato il primo consenso da un utente, l'entità servizio che rappresenta l'applicazione viene aggiunta alla directory.

  • Quando gli utenti accedono ai servizi online Microsoft, ad esempio Microsoft 365.

    • Quando si effettua la sottoscrizione a Microsoft 365 o si avvia una versione di valutazione, vengono create una o più entità servizio nella directory che rappresentano i vari servizi usati per fornire tutte le funzionalità associate a Microsoft 365.
    • Alcuni servizi di Microsoft 365, ad esempio SharePoint, creano entità servizio in modo continuativo per consentire la comunicazione sicura tra i componenti, inclusi i flussi di lavoro.

  • Quando un amministratore aggiunge un'applicazione dalla raccolta di app (in questo caso viene creato anche un oggetto app sottostante).

  • Aggiunta di un'applicazione per l'uso di Application Proxy di Microsoft Entra.

  • Connessione di un'applicazione per SSO tramite SAML o accesso Single Sign-On con password.

  • A livello di codice tramite l'API Microsoft Graph o PowerShell.

Un'applicazione ha un oggetto applicazione nella propria home directory a cui fanno riferimento una o più entità servizio in ognuna delle directory in cui opera, inclusa la home directory dell'applicazione.

Diagram of the relationship between app objects and service principals.

Nel diagramma precedente Microsoft mantiene internamente due directory (visualizzate a sinistra) usate per pubblicare le applicazioni:

  • Una per le app Microsoft (directory di servizi Microsoft).
  • Una per le applicazioni di terze parti preintegrate (directory della raccolta di app).

I fornitori e gli editori di applicazioni che procedono all'integrazione con Microsoft Entra ID devono avere una directory di pubblicazione (illustrata a destra come directory SaaS).

Le applicazioni aggiunte dall'utente (indicate come app dell'utente al centro del diagramma) includono:

  • App sviluppate dall'utente (integrate con Microsoft Entra ID).
  • App connesse per l'accesso SSO.
  • App pubblicate dall'utente tramite Application Proxy di Microsoft Entra.

Note ed eccezioni per le entità servizio

Non tutte le entità servizio fanno riferimento a un oggetto applicazione. Al momento dello sviluppo inziale di Microsoft Entra ID, i servizi forniti alle applicazioni erano più limitati e l'entità servizio era sufficiente per stabilire l'identità di un'applicazione. L'entità servizio originale assomigliava più all'account del servizio di Windows Server Active Directory. Per questo motivo, è ancora possibile creare entità servizio tramite percorsi diversi, come PowerShell, senza prima creare un oggetto applicazione. L'API Microsoft Graph richiede che sia disponibile un oggetto applicazione prima di creare un'entità servizio.

Non tutte le informazioni riportate sopra sono al momento esposte a livello di codice. Le funzionalità seguenti sono disponibili solo nell'interfaccia utente:

  • Regole di trasformazione delle attestazioni
  • Mapping degli attributi (provisioning utenti)

Per informazioni dettagliate su entità servizio e oggetti applicazione, vedere la documentazione di riferimento dell'API Microsoft Graph:

  • Applicazione
  • Entità servizio

Aggiunta di una nuova registrazione di app

Diagram of the relationship between app objects and service principals, focusing on process flow.

Flusso di processo del diagramma

  1. L'utente richiede di registrare un'applicazione e viene emesso un token di richiesta.
  2. L'endpoint di autorizzazione restituisce un'autenticazione.
  3. L'utente acconsente alla registrazione dell'applicazione.
  4. Il servizio viene creato dall'applicazione.
  5. Il token viene restituito all'utente.

Chi ha l'autorizzazione per aggiungere applicazioni all'istanza di Microsoft Entra?

Anche se esistono alcune attività che solo gli Amministratori globali possono eseguire per impostazione predefinita, ad esempio l'aggiunta di applicazioni dalla raccolta di app e la configurazione di un'applicazione per l'uso del proxy applicazione, è anche possibile assegnare ruoli come Amministratore applicazioni e Amministratore applicazione cloud per eseguire queste attività. Tenere presente che per impostazione predefinita tutti gli utenti in una directory hanno i diritti per registrare gli oggetti dell'applicazione che stanno sviluppando e possono scegliere a loro discrezione quali applicazione condividere e per quali concedere l'accesso ai dati dell'organizzazione tramite consenso. Quando il primo utente nella directory si collega a un'applicazione e concede il consenso, si crea un'entita servizio. In caso contrario, le informazioni sulla concessione del consenso verranno archiviate nell'entità servizio esistente.

Anche se il fatto di concedere agli utenti di registrarsi e dare il consenso alle applicazioni può inizialmente destare qualche preoccupazione, tenere presente quanto segue:

  • Le applicazioni hanno usato Windows Server Active Directory per autenticare gli utenti per anni senza richiedere la registrazione dell'applicazione nella directory. Ora le organizzazioni hanno maggiore visibilità sul numero esatto di applicazioni che usano la directory e sul relativo scopo.
  • Delegando queste responsabilità agli utenti si evita la necessità di un processo di pubblicazione e di registrazione dell'applicazione basato su amministratore. Con Active Directory Federation Services (AD FS) un amministratore doveva in genere aggiungere un'applicazione come relying party per conto degli sviluppatori. Ora gli sviluppatori possono distribuire se stessi (self-service).
  • L'accesso alle applicazioni da parte degli utenti per scopi lavorativi tramite un account aziendale è un fatto positivo. Se poi gli utenti lasceranno l'azienda, perderanno automaticamente l'accesso al proprio account nell'applicazione che usavano.
  • È positivo anche il fatto di poter tenere sotto controllo quali dati sono stati condivisi e con quali applicazioni. I dati sono più trasportabili che mai ed è quindi utile sapere chi ha condiviso determinati dati e con quali applicazioni.
  • I proprietari delle API, che usano Microsoft Entra ID per OAuth, decidono esattamente quali autorizzazioni gli utenti possono concedere alle applicazioni e quali autorizzazioni richiedono il consenso di un amministratore. Solo gli amministratori possono dare il consenso per ambiti più ampi e autorizzazioni più significative, mentre il consenso degli utenti è limitato alle funzionalità e ai dati degli utenti stessi.
  • Quando un utente aggiunge un'applicazione o consente all'applicazione di accedere ai propri dati, l'evento può essere controllato. È possibile visualizzare i report di controllo nel portale di Azure per determinare il modo in cui un'applicazione è stata aggiunta alla directory.

Se si vuole comunque impedire agli utenti nella directory di registrare le applicazioni e di accedere alle applicazioni senza l'approvazione dell'amministratore, ci sono due impostazioni che consentono di disattivare queste funzionalità:

Per impedire agli utenti di dare il consenso alle applicazioni per proprio conto:

  • Nel portale di Azure passare alla sezione Impostazioni utente in Applicazioni aziendali.

  • Impostare l'opzione Gli utenti possono fornire il consenso alle app che accedono ai dati aziendali per loro conto su No.

    Nota

    Se si decide di disattivare il consenso dell'utente, un amministratore dovrà fornire il consenso per qualsiasi nuova applicazione che un utente deve usare.

Per impedire agli utenti di registrare le proprie applicazioni:

  • Nel portale di Azure passare alla sezione Impostazioni utente in Microsoft Entra ID.
  • Impostare l'opzione Gli utenti possono registrare applicazioni su No.

Tenancy in Microsoft Entra ID

Microsoft Entra organizza gli oggetti come utenti e app in gruppi denominati tenant. I tenant consentono a un amministratore di impostare criteri per gli utenti all'interno dell'organizzazione e per le app di proprietà dell'organizzazione per soddisfare i criteri operativi e di sicurezza.

Chi può accedere all'app?

In fase di sviluppo, gli sviluppatori possono scegliere di configurare l'app come a tenant singolo o multi-tenant durante la registrazione dell'app nel portale di Azure.

  • Le app a tenant singolo sono disponibili solo nel tenant in cui sono state registrate, noto anche come tenant home.
  • Le app multi-tenant sono disponibili per gli utenti sia nel rispettivo tenant principale che in altri tenant.

Nel portale di Azure, è possibile configurare l'app come multi-tenant o a tenant singolo impostando i destinatari come descritto di seguito:

*Accesso ad app specifiche

Destinatari Tenant singolo/multi-tenant Chi può accedere
Account solo in questa directory Tenant singolo Tutti gli account utente e guest nella directory possono usare l'applicazione o l'API. Usare questa opzione se il gruppo di destinatari è interno all'organizzazione.
Account in qualsiasi directory di Microsoft Entra Multitenant Tutti gli utenti e gli utenti guest con un account Microsoft aziendale o dell'istituto di istruzione possono usare l'applicazione o l'API. Ciò include gli istituti di istruzione e le aziende che usano Microsoft 365. Usare questa opzione se i destinatari sono clienti aziendali o di istituti di istruzione.
Account in qualsiasi directory di Microsoft Entra e account Microsoft personali (ad esempio Skype, Xbox, Outlook.com) Multitenant Tutti gli utenti con un account Microsoft aziendale, dell'istituto di istruzione o personale possono usare l'applicazione o l'API. Ciò include gli istituti di istruzione e le aziende che usano Microsoft 365, nonché gli account personali usati per accedere a servizi come Xbox e Skype. Usare questa opzione per rivolgersi alla gamma più ampia di account Microsoft.

Procedure consigliate per le app multi-tenant

Creare app multi-tenant ottimali può essere difficile a causa del numero di criteri diversi che gli amministratori possono impostare nei loro tenant. Se si sceglie di creare un'app multi-tenant, seguire queste best practice:

  • Testare l'app in un tenant per cui sono configurati criteri di accesso condizionale.
  • Seguire il principio dell'accesso utente con privilegi minimi per assicurarsi che l'app richieda solo le autorizzazioni effettivamente necessarie.
  • Specificare nomi e descrizioni appropriati per tutte le autorizzazioni esposte come parte dell'app. In questo modo, utenti e amministratori sanno esattamente quello che stanno accettando quando tentano di usare le API dell'app. Per altre informazioni, vedere la sezione delle procedure consigliate nella guida alle autorizzazioni.