Tipi di identità e account per app a tenant singolo e multi-tenant

Articolo
05/18/2024

Questo articolo spiega in che modo, in qualità di sviluppatore, può scegliere se l'app consente solo agli utenti del tenant di Microsoft Entra, a qualsiasi tenant di Microsoft Entra o agli utenti con account Microsoft personali. È possibile configurare l'app come tenant singolo o multi-tenant durante la registrazione dell'app in Microsoft Entra. Verificare il principio Zero Trust dell'accesso con privilegi minimi in modo che l'app richieda solo le autorizzazioni necessarie.

Microsoft Identity Platform offre supporto per tipi di identità specifici:

Account aziendali o dell'istituto di istruzione quando l'entità ha un account in un ID Microsoft Entra
Account personali Microsoft (MSA) per chiunque abbia account in Outlook.com, Hotmail, Live, Skype, Xbox e così via.
Identità esterne in Microsoft Entra ID per i partner (utenti esterni all'organizzazione)
Microsoft Entra Business to Customer (B2C) che consente di creare una soluzione che consenta ai clienti di inserire altri provider di identità. Le applicazioni che usano Azure AD B2C o sono sottoscritte a Microsoft Dynamics 365 Fraud Protection con Azure Active Directory B2C possono valutare attività potenzialmente fraudolente seguendo i tentativi di creare nuovi account o accedere all'ecosistema del client.

Una parte richiesta della registrazione dell'applicazione in Microsoft Entra ID è la selezione dei tipi di account supportati. Mentre i professionisti IT nei ruoli di amministratore decidono chi può fornire il consenso alle app nel tenant, l'utente, in qualità di sviluppatore, specifica chi può usare l'app in base al tipo di account. Quando un tenant non consente di registrare l'applicazione in Microsoft Entra ID, gli amministratori forniscono un modo per comunicare tali dettagli tramite un altro meccanismo.

È possibile scegliere tra le opzioni seguenti per il tipo di account supportato durante la registrazione dell'applicazione.

Accounts in this organizational directory only (O365 only - Single tenant)
Accounts in any organizational directory (Any Azure AD directory - Multitenant)
Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)
Personal Microsoft accounts only

Solo account in questa directory organizzativa - tenant singolo

Quando si seleziona Account solo in questa directory organizzativa (solo O365 - Tenant singolo), è possibile consentire solo gli utenti e gli utenti guest dal tenant in cui lo sviluppatore ha registrato l'app. Questa opzione è la più comune per le applicazioni Line of Business (LOB).

Account solo in qualsiasi directory organizzativa - multi-tenant

Quando si seleziona Account in qualsiasi directory organizzativa (qualsiasi directory Microsoft Entra - Multitenant), si consente a qualsiasi utente di qualsiasi directory di Microsoft Entra di accedere all'applicazione multi-tenant. Se si vuole consentire solo agli utenti di tenant specifici, filtrare questi utenti nel codice controllando che l'attestazione tid nel id_token sia nell'elenco di tenant consentiti. L'applicazione può usare l'endpoint delle organizzazioni o l'endpoint comune per consentire agli utenti di accedere al tenant principale dell'utente. Per supportare gli utenti guest che accedono all'app multi-tenant, usare l'endpoint tenant specifico per il tenant in cui l'utente è un guest per accedere all'utente.

Account in qualsiasi account aziendale e account Microsoft personali

Quando si seleziona Account in qualsiasi account aziendale e account Microsoft personali (qualsiasi directory Microsoft Entra - Multi-tenant) e account Microsoft personali (ad esempio Skype, Xbox), si consente a un utente di accedere all'applicazione con la propria identità nativa da qualsiasi tenant o account consumer di Microsoft Entra. Lo stesso filtro del tenant e l'utilizzo degli endpoint si applicano a queste app come fanno alle app multi-tenant descritte in precedenza.

Solo account Microsoft personali

Quando si seleziona Solo account Microsoft personali, si consente solo agli utenti con account consumer di usare l'app.

Applicazioni rivolte ai clienti

Quando si crea una soluzione in Microsoft Identity Platform che si rivolge ai clienti, in genere non si vuole usare la directory aziendale. Si vuole invece che i clienti si trovino in una directory separata in modo che non possano accedere alle risorse aziendali dell'azienda. Per soddisfare questa esigenza, Microsoft offre microsoft Entra Business al cliente (B2C).

Azure AD B2C fornisce un'identità business-to-customer come servizio. Puoi consentire agli utenti di avere un nome utente e una password solo per la tua app. B2C supporta i clienti con identità di social networking per ridurre le password. È possibile supportare i clienti aziendali tramite la federazione della directory di Azure AD B2C all'ID Microsoft Entra dei clienti o a qualsiasi provider di identità che supporti SAML (Security Assertion Markup Language) in OpenID Connessione. A differenza di un'app multi-tenant, l'app non usa la directory aziendale del cliente in cui proteggono le risorse aziendali. I clienti possono accedere al servizio o alle funzionalità senza concedere all'app l'accesso alle risorse aziendali.

Non spetta solo allo sviluppatore

Mentre definisci nella registrazione dell'applicazione chi può accedere all'app, la parola finale proviene dal singolo utente o dagli amministratori del tenant principale dell'utente. Gli amministratori tenant spesso vogliono avere un maggiore controllo su un'app rispetto a chi può accedere. Ad esempio, potrebbero voler applicare criteri di accesso condizionale all'app o controllare il gruppo che consentono di usare l'applicazione. Per consentire agli amministratori tenant di avere questo controllo, è presente un secondo oggetto in Microsoft Identity Platform: l'app Enterprise. Le app aziendali sono note anche come entità servizio.

App con utenti in altri tenant o altri account consumer

Come illustrato nel diagramma seguente usando un esempio di due tenant (per le organizzazioni fittizie, Adatum e Contoso), i tipi di account supportati includono l'opzione Account in qualsiasi directory organizzativa per un'applicazione multi-tenant in modo da consentire gli utenti della directory organizzativa. In altre parole, si consente a un utente di accedere all'applicazione con la propria identità nativa da qualsiasi ID Microsoft Entra. Un'entità servizio viene creata automaticamente nel tenant quando il primo utente da un tenant esegue l'autenticazione all'app.

Esiste solo una registrazione dell'applicazione o un oggetto applicazione. Tuttavia, è presente un'app aziendale o un'entità servizio (SP), in ogni tenant che consente agli utenti di accedere all'app. L'amministratore tenant può controllare il funzionamento dell'app nel tenant.

Considerazioni sulle app multi-tenant

Le app multi-tenant consentono agli utenti di accedere dal tenant principale dell'utente quando l'app usa l'endpoint comune o dell'organizzazione. L'app ha una registrazione dell'app, come illustrato nel diagramma seguente. In questo esempio l'applicazione viene registrata nel tenant Adatum. L'utente A di Adatum e l'utente B di Contoso possono accedere all'app con l'utente A previsto da Adatum accede ai dati Adatum e che l'utente B di Contoso accede ai dati contoso.

Gli sviluppatori hanno la responsabilità di mantenere separate le informazioni sul tenant. Ad esempio, se i dati contoso provengono da Microsoft Graph, l'utente B di Contoso visualizza solo i dati di Microsoft Graph di Contoso. Non è possibile consentire all'utente B da Contoso di accedere ai dati di Microsoft Graph nel tenant di Adatum perché Microsoft 365 ha una vera separazione dei dati.

Nel diagramma precedente l'utente B di Contoso può accedere all'applicazione e accedere ai dati contoso nell'applicazione. L'applicazione può usare gli endpoint comuni (o dell'organizzazione) in modo che l'utente accinga in modo nativo al tenant, senza richiedere alcun processo di invito. Un utente può eseguire e accedere all'applicazione e funziona dopo che l'utente o l'amministratore tenant concede il consenso.

Collaborazione con utenti esterni

Quando le aziende vogliono consentire agli utenti che non sono membri dell'azienda di accedere ai dati dall'azienda, usano la funzionalità Microsoft Entra Business to Business (B2B). Come illustrato nel diagramma seguente, le aziende possono invitare gli utenti a diventare utenti guest nel tenant. Dopo che l'utente accetta l'invito, può accedere ai dati protetti dal tenant che invita. L'utente non crea credenziali separate nel tenant.

Gli utenti guest eseguono l'autenticazione accedendo al tenant principale, all'account Microsoft personale o ad un altro account IDP (Identity Provider). Gli utenti guest possono anche eseguire l'autenticazione con un passcode monouso usando qualsiasi messaggio di posta elettronica. Dopo l'autenticazione degli utenti guest, l'ID Microsoft Entra del tenant che invita fornisce un token per l'accesso ai dati del tenant che invitano.

Gli sviluppatori devono tenere presenti queste considerazioni quando l'applicazione supporta gli utenti guest:

È necessario usare un endpoint specifico del tenant durante l'accesso all'utente guest. Non è possibile usare gli endpoint comuni, dell'organizzazione o degli utenti consumer.
L'identità dell'utente guest è diversa dall'identità dell'utente nel tenant principale o in un altro provider di identità. L'attestazione oid nel token per un utente guest è diversa dalla stessa persona oid nel tenant principale.

Passaggi successivi

Come e perché le app vengono aggiunte all'ID Microsoft Entra spiegano in che modo gli oggetti applicazione descrivono un'applicazione all'ID Microsoft Entra.
Le procedure consigliate per la sicurezza per le proprietà dell'applicazione in Microsoft Entra ID illustrano proprietà quali URI di reindirizzamento, token di accesso, certificati e segreti, URI ID applicazione e proprietà dell'applicazione.
La creazione di app con un approccio Zero Trust all'identità offre una panoramica delle autorizzazioni e delle procedure consigliate per l'accesso.
Acquisire l'autorizzazione per accedere alle risorse consente di comprendere come garantire al meglio Zero Trust durante l'acquisizione delle autorizzazioni di accesso alle risorse per l'applicazione.
Sviluppare una strategia di autorizzazioni delegate consente di implementare l'approccio migliore per gestire le autorizzazioni nell'applicazione e sviluppare usando i principi Zero Trust.
Sviluppare una strategia di autorizzazioni per le applicazioni consente di decidere l'approccio alle autorizzazioni dell'applicazione per la gestione delle credenziali.

Condividi tramite