Panoramica dei provider di identità per l'hub di Azure Stack

  • Articolo

L'hub di Azure Stack richiede Microsoft Entra ID o Active Directory Federation Services (AD FS), supportato da Active Directory come provider di identità. La scelta di un provider è una decisione una tantum da prendere quando si distribuisce l'hub di Azure Stack per la prima volta. I concetti e i dettagli relativi all'autorizzazione in questo articolo consentono di scegliere tra provider di identità.

La scelta di Microsoft Entra ID o AD FS è determinata dalla modalità in cui si distribuisce l'hub di Azure Stack:

  • Quando la si distribuisce in modalità connessa, è possibile usare Microsoft Entra ID o AD FS.
  • Quando viene distribuito in modalità disconnessa, ovvero senza una connessione a Internet, è supportato solo AD FS.

Per altre informazioni sulle opzioni, che dipendono dall'ambiente dell'hub di Azure Stack, vedere gli articoli seguenti:

Importante

Azure AD Graph è deprecato e verrà ritirato il 30 giugno 2023. Per altre informazioni, vedere questa sezione.

Concetti comuni per i provider di identità

Le sezioni successive illustrano i concetti comuni relativi ai provider di identità e al relativo uso nell'hub di Azure Stack.

Terminologia per i provider di identità

Tenant di directory e organizzazioni

Una directory è un contenitore che contiene informazioni su utenti, applicazioni, gruppi ed entità servizio.

Un tenant di directory è un'organizzazione, ad esempio Microsoft o la propria azienda.

  • Microsoft Entra ID supporta più tenant e può supportare più organizzazioni, ognuna nella propria directory. Se si usa Microsoft Entra ID e si hanno più tenant, è possibile concedere ad app e utenti da un tenant l'accesso ad altri tenant della stessa directory.
  • AD FS supporta solo un singolo tenant e, pertanto, una singola organizzazione.

Utenti e gruppi

Gli account utente (identità) sono account standard che autenticano gli utenti usando un ID utente e una password. I gruppi possono includere utenti o altri gruppi.

La modalità di creazione e gestione di utenti e gruppi dipende dalla soluzione di gestione delle identità usata.

Nell'hub di Azure Stack gli account utente:

  • Vengono creati nel formato username@domain . Anche se AD FS esegue il mapping degli account utente a un'istanza di Active Directory, AD FS non supporta l'uso del formato \<domain>\<alias> .
  • Può essere configurato per l'uso dell'autenticazione a più fattori.
  • Sono limitati alla directory in cui vengono registrati per la prima volta, ovvero la directory dell'organizzazione.
  • Possono essere importati dalle directory locali. Per altre informazioni, vedere Integrare le directory locali con Microsoft Entra ID.

Quando si accede al portale utenti dell'organizzazione, si usa l'URL https://portal.local.azurestack.external. Quando si accede al portale dell'hub di Azure Stack da domini diversi da quello usato per registrare l'hub di Azure Stack, il nome di dominio usato per registrare l'hub di Azure Stack deve essere aggiunto all'URL del portale. Ad esempio, se l'hub di Azure Stack è stato registrato con fabrikam.onmicrosoft.com e l'account utente che esegue l'accesso è admin@contoso.com, l'URL da usare per accedere al portale utenti sarà: https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.

Utenti guest

Gli utenti guest sono account utente di altri tenant di directory a cui è stato concesso l'accesso alle risorse presenti nella directory. Per supportare gli utenti guest, usare Microsoft Entra ID e abilitare il supporto per la multi-tenancy. Quando il supporto è abilitato, è possibile invitare gli utenti guest ad accedere alle risorse nel tenant di directory, che a sua volta consente la collaborazione con organizzazioni esterne.

Per invitare utenti guest, gli operatori cloud e gli utenti possono usare Microsoft Entra Collaborazione B2B. Gli utenti invitati ottengono l'accesso a documenti, risorse e app dalla directory e mantengono il controllo sulle risorse e sui dati personali.

Gli utenti guest possono accedere al tenant di directory di un'altra organizzazione. A tale scopo, è necessario aggiungere il nome della directory dell'organizzazione all'URL del portale. Ad esempio, se si appartiene all'organizzazione Contoso e si vuole accedere alla directory Fabrikam, si usa https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.

App

È possibile registrare le app per Microsoft Entra ID o AD FS e quindi offrire le app agli utenti dell'organizzazione.

Le app includono:

  • App Web: esempi includono il portale di Azure e Azure Resource Manager. Supportano le chiamate API Web.
  • Client nativo: esempi includono Azure PowerShell, Visual Studio e l'interfaccia della riga di comando di Azure.

Le app possono supportare due tipi di tenancy:

  • Tenant singolo: supporta utenti e servizi solo della stessa directory in cui è registrata l'app.

    Nota

    Dal momento che AD FS supporta solo una singola directory, le app create in una topologia AD FS sono, per impostazione predefinita, app a tenant singolo.

  • Multi-tenant: supporta l'uso da parte di utenti e servizi sia dalla directory in cui l'app è registrata che da altre directory del tenant. Con le app multi-tenant, gli utenti di un'altra directory tenant (un altro tenant Microsoft Entra) possono accedere all'app.

    Per altre informazioni sulla multi-tenancy, vedere Abilitare la multi-tenancy.

    Per altre informazioni sullo sviluppo di un'app multi-tenant, vedere App multi-tenant.

Quando si registra un'app, si creano due oggetti:

  • Oggetto applicazione: rappresentazione globale dell'app in tutti i tenant. Si tratta di una relazione uno-a-uno con l'app software ed esiste solo nella directory in cui l'app viene registrata per la prima volta.

  • Oggetto entità servizio: credenziali create per un'app nella directory in cui l'app viene registrata per la prima volta. Viene creata un'entità servizio anche nella directory di ogni tenant aggiuntivo in cui viene usata l'app. Può essere una relazione uno-a-molti con l'app software.

Per altre informazioni sugli oggetti app e entità servizio, vedere Oggetti applicazione e entità servizio in Microsoft Entra ID.

Entità servizio

Un'entità servizio è costituita da un set di credenziali per un'app o un servizio che concede l'accesso alle risorse nell'hub di Azure Stack. Un'entità servizio consente di separare le autorizzazioni dell'app dalle autorizzazioni dell'utente dell'app.

Viene creata un'entità servizio in ogni tenant in cui viene usata l'app. L'entità servizio stabilisce un'identità per l'accesso e l'accesso alle risorse (ad esempio gli utenti) protette da tale tenant.

  • Un'app a tenant singolo include una sola entità servizio, che si trova nella directory in cui viene creata per la prima volta. Questa entità servizio viene creata e concede il consenso all'uso durante la registrazione dell'app.
  • Un'app Web multi-tenant o un'API include un'entità servizio che viene creata in ogni tenant in cui un utente di tale tenant concede il consenso all'uso dell'app.

Le credenziali per le entità servizio possono essere una chiave generata tramite il portale di Azure o un certificato. Il certificato costituisce la soluzione adatta per l'automazione perché i certificati sono considerati più sicuri delle chiavi.

Nota

Quando si usa AD FS con l'hub di Azure Stack, solo l'amministratore può creare entità servizio. Con AD FS, le entità servizio richiedono certificati e vengono create tramite l'endpoint con privilegi (PEP). Per altre informazioni, vedere Usare un'identità dell'app per accedere alle risorse.

Per informazioni sulle entità servizio per l'hub di Azure Stack, vedere Creare entità servizio.

Servizi

I servizi nell'hub di Azure Stack che interagiscono con il provider di identità vengono registrati come app con il provider di identità. Analogamente alle app, la registrazione consente a un servizio di eseguire l'autenticazione con il sistema di identità.

Tutti i servizi di Azure usano protocolli OpenID Connect e token Web JSON per stabilire la propria identità. Poiché Microsoft Entra ID e AD FS usano in modo coerente i protocolli, è possibile usare Microsoft Authentication Library (MSAL) per ottenere un token di sicurezza per autenticare in locale o in Azure (in uno scenario connesso). Con MSAL è anche possibile usare strumenti come Azure PowerShell e l'interfaccia della riga di comando di Azure per la gestione delle risorse tra cloud e locali.

Identità e sistema di identità

Le identità per l'hub di Azure Stack includono account utente, gruppi ed entità servizio.

Quando si installa l'hub di Azure Stack, diversi servizi e app predefiniti vengono registrati automaticamente con il provider di identità nel tenant di directory. Alcuni servizi registrati vengono usati per l'amministrazione. Altri servizi sono disponibili per gli utenti. Le registrazioni predefinite offrono ai servizi di base identità che possono interagire tra loro e con identità aggiunte in un secondo momento.

Se si configura Microsoft Entra ID con multi-tenancy, alcune app vengono propagate alle nuove directory.

Autenticazione e autorizzazione

Autenticazione da parte di app e utenti

Identità tra livelli dell'hub di Azure Stack

Per le app e gli utenti, l'architettura dell'hub di Azure Stack è descritta da quattro livelli. Le interazioni tra ognuno di questi livelli possono usare diversi tipi di autenticazione.

Livello Autenticazione tra livelli
Strumenti e client, ad esempio il portale di amministrazione Per accedere o modificare una risorsa nell'hub di Azure Stack, gli strumenti e i client usano un token Web JSON per eseguire una chiamata ad Azure Resource Manager.
Azure Resource Manager convalida il token Web JSON e visualizza le attestazioni nel token emesso per stimare il livello di autorizzazione che l'utente o l'entità servizio hanno nell'hub di Azure Stack.
Azure Resource Manager e i relativi servizi di base Azure Resource Manager comunica con i provider di risorse per trasferire le comunicazioni dagli utenti.
I trasferimenti usano chiamate imperative dirette o chiamate dichiarative tramite modelli di Resource Manager di Azure.
Provider di risorse Le chiamate passate ai provider di risorse sono protette con l'autenticazione basata su certificati.
Azure Resource Manager e il provider di risorse rimangono quindi in comunicazione tramite un'API. Per ogni chiamata ricevuta da Azure Resource Manager, il provider di risorse convalida la chiamata con tale certificato.
Infrastruttura e logica di business I provider di risorse comunicano con la logica di business e l'infrastruttura usando una modalità di autenticazione a loro scelta. I provider di risorse predefiniti che vengono forniti con l'hub di Azure Stack usano l'autenticazione di Windows per proteggere la comunicazione.

Informazioni necessarie per l'autenticazione

Eseguire l'autenticazione in Azure Resource Manager

Per eseguire l'autenticazione con il provider di identità e ricevere un token JSON Web, è necessario disporre delle informazioni seguenti:

  1. URL per il sistema di identità (autorità): URL tramite cui è possibile raggiungere il provider di identità. Ad esempio: https://login.windows.net.
  2. URI ID app per Azure Resource Manager: identificatore univoco per Azure Resource Manager registrato con il provider di identità. È anche univoco per ogni installazione dell'hub di Azure Stack.
  3. Credenziali: credenziali usate per l'autenticazione con il provider di identità.
  4. URL per Azure Resource Manager: l'URL corrisponde alla posizione del servizio Azure Resource Manager. Ad esempio, https://management.azure.com o https://management.local.azurestack.external.

Quando un'entità (client, app o utente) effettua una richiesta di autenticazione per accedere a una risorsa, la richiesta deve includere:

  • Credenziali dell'entità.
  • URI ID app della risorsa a cui l'entità vuole accedere.

Le credenziali vengono convalidate dal provider di identità. Il provider di identità verifica anche che l'URI ID app sia relativo a un'app registrata e che l'entità disponga dei privilegi corretti per ottenere un token per tale risorsa. Se la richiesta è valida, viene concesso un token JSON Web.

Il token deve quindi passare l'intestazione di una richiesta ad Azure Resource Manager. Azure Resource Manager esegue le operazioni seguenti, senza un ordine specifico:

  • Convalida l'attestazione dell'autorità di certificazione (iss) per verificare che il token provenga dal provider di identità corretto.
  • Convalida l'attestazione dei destinatari (aud) per verificare che il token sia stato rilasciato per Azure Resource Manager.
  • Verifica che il token JSON Web sia firmato con un certificato configurato tramite OpenID e noto ad Azure Resource Manager.
  • Esamina le attestazioni relative a luogo di rilascio (iat) e scadenza (exp) per verificare che il token sia attivo e possa essere accettato.

Al termine di tutte le convalide, Azure Resource Manager usa l'ID oggetto (oid) e le attestazioni dei gruppi per creare un elenco di risorse a cui l'entità può accedere.

Diagramma del protocollo di scambio dei token

Nota

Dopo la distribuzione, non è necessaria l'autorizzazione amministratore globale Microsoft Entra. Tuttavia, alcune operazioni possono richiedere le credenziali di amministratore globali, ad esempio uno script del programma di installazione del provider di risorse o una nuova funzionalità che richiede un'autorizzazione da concedere. È possibile ripetere temporaneamente le autorizzazioni di amministratore globale dell'account o usare un account amministratore globale separato proprietario della sottoscrizione del provider predefinito.

Usare il controllo degli accessi in base al ruolo

Role-Based Controllo di accesso (RBAC) nell'hub di Azure Stack è coerente con l'implementazione in Microsoft Azure. È possibile gestire l'accesso alle risorse assegnando il ruolo RBAC appropriato agli utenti, ai gruppi e alle app. Per informazioni sull'uso del controllo degli accessi in base al ruolo con l'hub di Azure Stack, vedere gli articoli seguenti:

Eseguire l'autenticazione con Azure PowerShell

Informazioni dettagliate sull'uso di Azure PowerShell per l'autenticazione con l'hub di Azure Stack sono disponibili in Configurare l'ambiente PowerShell dell'hub di Azure Stack.

Eseguire l'autenticazione con l'interfaccia della riga di comando di Azure

Per informazioni sull'uso di Azure PowerShell per l'autenticazione con l'hub di Azure Stack, vedere Installare e configurare l'interfaccia della riga di comando di Azure per l'uso con l'hub di Azure Stack.

Criteri di Azure

Criteri di Azure consente di imporre standard aziendali e di valutare la conformità su larga scala. Tramite il dashboard di conformità, fornisce una visualizzazione aggregata per valutare lo stato complessivo dell'ambiente, con la possibilità di eseguire il drill-down in base alla granularità per risorsa, per criterio. Consente inoltre di ottenere la conformità delle risorse tramite la correzione in blocco per le risorse esistenti e la correzione automatica per le nuove risorse.

I casi d'uso comuni per Criteri di Azure includono l'implementazione della governance per la coerenza delle risorse, la conformità alle normative, la sicurezza, i costi e la gestione. Le definizioni dei criteri per questi casi d'uso comuni sono già incorporate nell'ambiente di Azure per iniziare.

Nota

Criteri di Azure attualmente non è supportato nell'hub di Azure Stack.

Microsoft Azure AD Graph

Microsoft Azure ha annunciato la deprecazione di Azure AD Graph il 30 giugno 2020 e la data di ritiro del 30 giugno 2023. Microsoft ha informato i clienti tramite posta elettronica su questa modifica. Per informazioni più dettagliate, vedere il blog sul ritiro di Azure AD Graph e sul modulo Powershell Deprecation .

La sezione seguente descrive come questa deprecazione influisce sull'hub di Azure Stack.

Il team dell'hub di Azure Stack sta lavorando strettamente con il team di Azure Graph per garantire che i sistemi continuino a lavorare oltre il 30 giugno 2023, se necessario, per garantire una transizione uniforme. L'azione più importante consiste nel garantire la conformità ai criteri di manutenzione dell'hub di Azure Stack. I clienti riceveranno un avviso nel portale di amministratore dell'hub di Azure Stack e saranno necessari per aggiornare la home directory e tutte le directory guest caricate.

La maggior parte della migrazione stessa verrà eseguita dall'esperienza di aggiornamento del sistema integrato; sarà necessario un passaggio manuale richiesto dai clienti per concedere nuove autorizzazioni a tali applicazioni, che richiederanno autorizzazioni di amministratore globali in ogni directory Microsoft Entra usata con gli ambienti dell'hub di Azure Stack. Al termine dell'installazione del pacchetto di aggiornamento con queste modifiche, viene generato un avviso nel portale di amministrazione per completare questo passaggio usando l'interfaccia utente multi-tenancy o gli script di PowerShell. Si tratta della stessa operazione eseguita durante l'onboarding di directory o provider di risorse aggiuntivi; per altre informazioni, vedere Configurare la multi-tenancy nell'hub di Azure Stack.

Se si usa AD FS come sistema di identità con l'hub di Azure Stack, queste modifiche di Graph non influisceranno direttamente sul sistema. Tuttavia, le versioni più recenti degli strumenti, ad esempio l'interfaccia della riga di comando di Azure, Azure PowerShell e così via, richiedono le nuove API Graph e non funzioneranno. Assicurarsi di usare solo le versioni di questi strumenti che sono supportate in modo esplicito con la compilazione dell'hub di Azure Stack specificata.

Oltre all'avviso nel portale di amministrazione, comunichiamo le modifiche tramite le note sulla versione degli aggiornamenti e comunicherà quale pacchetto di aggiornamento richiede l'aggiornamento della home directory e tutte le directory guest caricate.

Passaggi successivi