Se prevedi di federare Cloud Identity o Google Workspace con un provider di identità (IdP) esterno, ma hai ancora bisogno di consolidare gli account consumer esistenti, questo documento ti aiuta a comprendere e valutare l'interazione tra federazione e consolidamento. Questo documento illustra inoltre come configurare la federazione in modo da non interferire con la capacità di consolidare gli account consumer esistenti.
Interazione tra federazione e consolidamento degli account utente
In una configurazione federata, devi collegare Cloud Identity o Google Workspace a una fonte autorevole esterna in modo che quest'ultima possa eseguire automaticamente il provisioning degli account utente in Cloud Identity o Google Workspace.
Questi valori non varianti in genere sono validi per una configurazione federata:
- La fonte ufficiale è l'unica fonte di identità.
- In Cloud Identity o Google Workspace non sono presenti account utente diversi da quelli di cui è stato eseguito il provisioning dalla fonte autorevole.
- Il provider di identità SAML non consente il servizio Single Sign-On di Google per identità diverse da quelle per cui la fonte ufficiale ha eseguito il provisioning degli account utente.
Sebbene questi valori invarianti riflettano le best practice per la federazione di Google Cloud con un provider di identità esterno, causano problemi quando si esegue la migrazione di account consumer esistenti:
- Gli account consumer esistenti non provengono da una fonte autorevole. Questi account esistono già e ora devono essere collegati a un'identità nota dalla fonte autorevole.
- Una volta eseguita la migrazione a Cloud Identity o Google Workspace, gli account consumer esistenti sono account utente di cui non è stato eseguito il provisioning da parte di una fonte autorevole. La fonte ufficiale deve riconoscere e "adottare" questi account di cui è stata eseguita la migrazione.
- Le identità degli account consumer esistenti potrebbero essere sconosciute al provider di identità SAML, ma dovranno comunque essere autorizzati a utilizzare il Single Sign-On.
Per consentire il consolidamento degli account consumer esistenti, devi configurare temporaneamente la federazione in modo sicuro per il consolidamento degli account.
Rendere sicura la federazione per il consolidamento degli account
La tabella seguente elenca i requisiti da considerare per rendere sicura la federazione per il consolidamento degli account. Se prevedi di utilizzare un IdP esterno, ma devi comunque consolidare gli account consumer esistenti, devi assicurarti che la configurazione soddisfi inizialmente questi requisiti. Dopo aver completato la migrazione degli account consumer esistenti, puoi modificare la configurazione perché i requisiti non saranno più validi.
| Requisito | Motivazione |
|---|---|
| Consentire il Single Sign-On per le identità con account consumer | La migrazione di un account consumer richiede il trasferimento dell'account. Un amministratore di Cloud Identity o Google Workspace avvia il trasferimento dell'account, ma per completare il trasferimento il proprietario dell'account consumer deve acconsentire al trasferimento. In qualità di amministratore, hai un controllo limitato su quando verrà espresso il consenso e, pertanto, quando viene effettuato il trasferimento.
Una volta che il proprietario esprime il consenso e il trasferimento è completo, tutti gli accessi successivi sono soggetti al Single Sign-On che utilizza il tuo IdP esterno. Affinché il Single Sign-On vada a buon fine, indipendentemente dal momento in cui il trasferimento è completato, assicurati che l'IdP esterno consenta i Single Sign-On per le identità di tutti gli account consumer di cui prevedi di eseguire la migrazione. |
| Impedire il provisioning automatico degli utenti per le identità con account consumer | Se esegui il provisioning di un account utente per un'identità che ha già un account consumer, crei un account in conflitto. Un account in conflitto ti impedisce di trasferire la proprietà dell'account consumer, della sua configurazione e degli eventuali dati associati a Cloud Identity o Google Workspace.
Il comportamento predefinito di molti IdP esterni è la creazione proattiva degli account utente in Cloud Identity o Google Workspace. Questo comportamento può causare inavvertitamente la creazione di account in conflitto. Impedendo il provisioning automatico degli utenti per le identità con account consumer esistenti, eviti di creare inavvertitamente account in conflitto e ti assicuri che gli account consumer possano essere trasferiti correttamente. |
Se hai identificato account consumer senza un'identità corrispondente nell'IdP esterno che consideri legittimi e di cui vuoi eseguire la migrazione a Cloud Identity o Google Workspace, devi assicurarti che la configurazione della federazione non interferisca con la possibilità di eseguire la migrazione di questi account consumer.
| Requisito | Motivazione |
|---|---|
| Impedisci l'eliminazione degli account di cui è stata eseguita la migrazione senza un'identità corrispondente nell'IdP esterno | Se hai un account utente in Cloud Identity o Google Workspace che non ha un'identità corrispondente nel tuo IdP esterno, l'IdP potrebbe considerare questo account utente orfano e sospenderlo o eliminarlo.
Se impedisci all'IdP esterno di sospendere o eliminare gli account di cui è stata eseguita la migrazione senza far corrispondere l'identità nell'IdP esterno, eviterai di perdere la configurazione e i dati associati agli account interessati e potrai assicurarti di poter riconciliare manualmente gli account. |
Rendere sicura la federazione di Microsoft Entra ID (in precedenza Azure AD) per il consolidamento degli account
Se prevedi di federe Cloud Identity o Google Workspace con Microsoft Entra ID (in precedenza Azure AD), puoi utilizzare l'app della galleria di Google Workspace.
Quando attivi il provisioning, Microsoft Entra ID ignora gli account esistenti in Cloud Identity o Google Workspace che non hanno una controparte in Microsoft Entra ID, per cui viene sempre soddisfatto il requisito di impedire l'eliminazione degli account migrati senza un'identità corrispondente nell'IdP esterno.
A seconda di come configuri l'app Galleria, devi comunque assicurarti di eseguire le seguenti operazioni:
- Consenti il Single Sign-On per le identità con account consumer.
- Impedire il provisioning automatico degli utenti per le identità con account consumer.
Esistono diversi modi per soddisfare questi requisiti. Ciascun approccio presenta vantaggi e svantaggi.
Approccio 1: non configurare il provisioning
In questo approccio, configurerai l'app Gallery per la gestione del Single Sign-On, ma non il provisioning automatico degli utenti. Se non configuri il provisioning degli utenti, impedisci il provisioning automatico degli utenti per le identità con account consumer.
Per consentire il Single Sign-On per le identità con account consumer, assegna l'app a tutte le identità che potrebbero richiedere l'accesso ai servizi Google, anche se gli account consumer esistenti sono ancora soggetti a migrazione.
Per un utente che dispone di un account consumer esistente, l'account utente Cloud Identity o Google Workspace corrispondente viene creato automaticamente quando viene accettata la richiesta di trasferimento. Questo utente può quindi utilizzare immediatamente il Single Sign-On.
Per gli utenti che non hanno un account utente in Cloud Identity o Google Workspace, devi crearne uno manualmente.
Sebbene questo approccio soddisfi i requisiti e sia il meno complesso da configurare, ha la limitazione che eventuali modifiche degli attributi o sospensioni degli utenti eseguite in Microsoft Entra ID non verranno propagate a Cloud Identity o Google Workspace.
Metodo 2: due app con assegnazione manuale
Con questo approccio, superi il limite di dover creare manualmente account utente in Google Workspace o Cloud Identity per gli utenti che non hanno un account esistente. L'idea è utilizzare due app galleria, una per il provisioning e una per il Single Sign-On:
- La prima app viene utilizzata esclusivamente per il provisioning di utenti e gruppi e ha il Single Sign-On disabilitato. Assegnando utenti a questa app, puoi controllare gli account di cui viene eseguito il provisioning in Cloud Identity o Google Workspace.
- La seconda app viene utilizzata esclusivamente per il Single Sign-On e non è autorizzata a eseguire il provisioning degli utenti. Assegnando gli utenti a questa app, puoi stabilire a quali utenti è consentito accedere.
Utilizzando queste due app, assegna gli utenti nel seguente modo:
- Assegna all'app Single Sign-On tutte le identità che hanno bisogno di accedere ai servizi Google. Includi le identità con account consumer esistenti in modo da consentire il Single Sign-On per le identità con account consumer.
- Quando assegni le identità all'app di provisioning, includi le identità che alla fine necessitano dell'accesso ai servizi Google, ma escludi tutte quelle note per avere un account consumer esistente. In questo modo, puoi impedire il provisioning automatico degli utenti per le identità con account consumer.
Approccio 3: due app in cui la creazione utenti è disattivata
Quando configuri il provisioning, devi autorizzare Microsoft Entra ID ad accedere a Cloud Identity o Google Workspace utilizzando un account Cloud Identity o Google Workspace. Normalmente, a questo scopo, è preferibile utilizzare un account super amministratore dedicato, poiché gli account super amministratore sono esenti dall'accesso Single Sign-On (ovvero, qualsiasi configurazione SSO non è applicabile, pertanto continueranno a utilizzare le password per l'accesso).
Tuttavia, in questo scenario puoi fare in modo che Microsoft Entra ID utilizzi un account più limitato per la migrazione, che non consente a Microsoft Entra ID di creare utenti. In questo modo, puoi impedire efficacemente ad Azure di eseguire il provisioning automatico degli account utente per le identità con account consumer, indipendentemente dagli utenti assegnati all'app di provisioning.
Un account utente amministratore limitato in Cloud Identity o Google Workspace deve avere solo i seguenti privilegi:
- Unità organizzative > Lettura
- Utenti > Letti
- Utenti > Aggiorna
- Gruppi
Uno svantaggio di questo approccio è che, per gli utenti senza account non gestiti, devi creare manualmente gli account in Cloud Identity o Google Workspace.
Federazione con Microsoft Entra ID: confronto
La seguente tabella riassume gli approcci.
| Consenti il Single Sign-On per le identità con account consumer | Impedisci il provisioning automatico degli utenti per le identità con account consumer | Impedisci l'eliminazione degli account di cui è stata eseguita la migrazione senza un'identità corrispondente nell'IdP esterno | Esegui automaticamente il provisioning di nuovi account | Aggiorna automaticamente gli account di cui è stata eseguita la migrazione | |
|---|---|---|---|---|---|
| Approccio 1: nessun provisioning | ✅ | ✅ | ✅ | X | X |
| Metodo 2: due app con assegnazione manuale | ✅ | Probabile errore manuale | ✅ | ✅ | ✅ |
| Approccio 3: due app in cui la creazione utenti è disattivata | ✅ | ✅ | ✅ | X | ✅ |
Rendere sicura la federazione di Active Directory per il consolidamento degli account
Se prevedi di federe Cloud Identity o Google Workspace con Active Directory, puoi utilizzare Google Cloud Directory Sync e AD FS (Active Directory Federation Services). Quando configuri Google Cloud Directory Sync e AD FS, devi assicurarti di:
- Consenti il Single Sign-On per le identità con account consumer.
- Impedire il provisioning automatico degli utenti per le identità con account consumer.
- Impedisci l'eliminazione degli account di cui è stata eseguita la migrazione senza un'identità corrispondente nell'IdP esterno.
Esistono diversi modi per soddisfare questi requisiti. Ciascun approccio presenta vantaggi e svantaggi.
Approccio 1: disattivazione di Google Cloud Directory Sync
Con questo approccio, configurerai il Single Sign-On con AD FS, ma non abiliti Google Cloud Directory Sync finché non hai completato la migrazione degli account utente non gestiti. Disattivando Google Cloud Directory Sync puoi impedire il provisioning automatico degli utenti per le identità con account consumer.
Per consentire il Single Sign-On per le identità con account consumer, crea un criterio di controllo dell'accesso personalizzato in AD FS e assegna tutte le identità che potrebbero richiedere l'accesso ai servizi Google, anche se gli account consumer esistenti sono ancora soggetti a migrazione.
Per un utente che dispone di un account consumer esistente, l'account utente Cloud Identity o Google Workspace corrispondente viene creato automaticamente quando viene accettata la richiesta di trasferimento. L'uso del criterio di controllo dell'accesso personalizzato garantisce che l'utente possa utilizzare immediatamente il servizio Single Sign-On.
Per gli utenti che non hanno un account utente in Cloud Identity o Google Workspace, devi crearne uno manualmente.
Sebbene questo approccio soddisfi i requisiti e sia il meno complesso da configurare, presenta la limitazione che eventuali modifiche degli attributi o sospensioni degli utenti eseguite in Active Directory non verranno propagate a Cloud Identity o Google Workspace.
Approccio 2: Google Cloud Directory Sync con assegnazione manuale
Con questo approccio, superi il limite di dover creare manualmente account utente in Cloud Identity o Google Workspace per gli utenti che non hanno un account esistente:
In modo equivalente all'approccio 1, consenti il Single Sign-On per le identità con account consumer creando un criterio di controllo dell'accesso personalizzato in AD FS e assegnando tutte le identità che potrebbero richiedere l'accesso ai servizi Google, anche se gli account consumer esistenti sono ancora soggetti a migrazione.
Crea un gruppo in Active Directory che rifletta gli account utente di cui vuoi eseguire automaticamente il provisioning in Google Cloud Directory Sync. Nell'elenco dei membri, includi le identità che hanno bisogno di accedere ai servizi Google, ma escludi tutte quelle che sono note per avere un account consumer esistente.
Configura Google Cloud Directory Sync in modo da eseguire il provisioning degli account utente solo per le identità che sono membri di questo gruppo. In questo modo, puoi impedire il provisioning automatico degli utenti per le identità con account consumer.
Un limite fondamentale di questo approccio è che non puoi impedire l'eliminazione degli account di cui è stata eseguita la migrazione senza un'identità corrispondente nell'IdP esterno. L'approccio è quindi applicabile solo se non hai account consumer senza un'identità corrispondente nell'IdP esterno.
Approccio 3: non consentire a Google Cloud Directory Sync di creare utenti
Quando configuri il provisioning, devi autorizzare Google Cloud Directory Sync ad accedere a Cloud Identity o Google Workspace. Normalmente, a questo scopo, è preferibile utilizzare un account super amministratore dedicato, poiché questi account sono esenti dall'accesso Single Sign-On (ovvero, qualsiasi configurazione SSO non è applicabile, ma continueranno a utilizzare le password per l'accesso).
Tuttavia, in questo scenario puoi fare in modo che Google Cloud Directory Sync utilizzi un account più limitato per la migrazione, che non consente la creazione di utenti. In questo modo, puoi impedire a Google Cloud Directory Sync di eseguire automaticamente il provisioning degli account utente per le identità con account consumer e di eliminare gli account di cui è stata eseguita la migrazione senza un'identità corrispondente nell'IdP esterno.
Un account utente amministratore limitato in Cloud Identity o Google Workspace deve avere solo i seguenti privilegi:
- Unità organizzative
- Utenti > Letti
- Utenti > Aggiorna
- Gruppi
- Gestione schemi
- Gestione del dominio
Uno svantaggio di questo approccio è che, per gli utenti senza account non gestiti, devi creare manualmente gli account in Cloud Identity o Google Workspace.
Federazione con Active Directory: confronto
La seguente tabella riassume gli approcci.
| Consenti il Single Sign-On per le identità con account consumer | Impedisci il provisioning automatico degli utenti per le identità con account consumer | Impedisci l'eliminazione degli account di cui è stata eseguita la migrazione senza un'identità corrispondente nell'IdP esterno | Esegui automaticamente il provisioning di nuovi account | Aggiorna automaticamente gli account di cui è stata eseguita la migrazione | |
|---|---|---|---|---|---|
| Approccio 1: non configurare il provisioning | ✅ | ✅ | ✅ | X | X |
| Approccio 2: GCDS con assegnazione manuale | ✅ | Probabile errore manuale | X | ✅ | ✅ |
| Approccio 3: non consentire a GCDS di creare utenti | ✅ | ✅ | ✅ | X | ✅ |
Rendere sicura la federazione Okta per il consolidamento degli account
Per federare Cloud Identity o Google Workspace con Okta, puoi utilizzare l'app Google Workspace dal catalogo di app Okta. Questa app può gestire il Single Sign-On e il provisioning di utenti e gruppi a Cloud Identity o Google Workspace.
Quando utilizzi l'app Google Workspace per il provisioning, Okta ignora gli utenti esistenti in Cloud Identity o Google Workspace che non hanno una controparte in Okta, perciò viene sempre soddisfatto il requisito di impedire l'eliminazione degli account migrati senza un'identità corrispondente nell'IdP esterno.
A seconda di come configuri Okta, devi comunque eseguire le seguenti operazioni:
- Consenti il Single Sign-On per le identità con account consumer.
- Impedire il provisioning automatico degli utenti per le identità con account consumer.
Esistono diversi modi per soddisfare questi requisiti. Ogni approccio presenta vantaggi e svantaggi.
Approccio 1: non configurare il provisioning
In questo approccio, si configura l'app Google Workspace in modo da gestire il Single Sign-On, ma non il provisioning. Se non configuri il provisioning degli utenti, impedisci il provisioning automatico degli utenti per le identità con account consumer.
Per consentire il Single Sign-On per le identità con account consumer, assegna l'app a tutte le identità che potrebbero richiedere l'accesso ai servizi Google, anche se gli account consumer esistenti sono ancora soggetti a migrazione. Le icone di Google Workspace o Google Cloud vengono visualizzate nella home page di Okta di tutte le identità assegnate all'app. Tuttavia, l'accesso non andrà a buon fine a meno che non esista un account utente corrispondente sul lato Google.
Per un utente che dispone di un account consumer esistente, l'account utente Cloud Identity o Google Workspace corrispondente viene creato automaticamente quando viene accettata la richiesta di trasferimento. Questo utente può quindi utilizzare immediatamente il Single Sign-On.
Sebbene questo approccio soddisfi i requisiti e sia il meno complesso da configurare, ha la limitazione che eventuali modifiche degli attributi o sospensioni degli utenti eseguite in Okta non verranno propagate a Cloud Identity o Google Workspace. Un altro svantaggio di questo approccio è che devi creare manualmente account in Cloud Identity o Google Workspace per tutti gli utenti che non hanno un account consumer esistente.
Metodo 2: provisioning con assegnazione manuale
In questo approccio, configurerai l'app Google Workspace per gestire il Single Sign-On e il provisioning, ma attiverai solo le seguenti funzionalità di provisioning:
- Crea utenti
- Aggiorna attributi utente
- Disattivare gli utenti
Quando assegni le identità all'app, includi le identità che hanno bisogno di accedere ai servizi Google, ma escludi tutte quelle che sono note per avere un account consumer esistente. In questo modo, puoi impedire il provisioning automatico degli utenti per le identità con account consumer.
Non appena un utente accetta una richiesta di trasferimento, assegnalo all'app in modo che possa utilizzare il Single Sign-On e accedere a Google Workspace o Google Cloud.
Uno svantaggio di questo approccio è che qualsiasi errore che commetti nell'assegnazione può portare immediatamente alla creazione di un account in conflitto, il che rende questo approccio molto più rischioso rispetto ad altri.
Un altro aspetto negativo di questo approccio è che causa blocchi temporanei degli account di cui è stata eseguita la migrazione. Dopo aver accettato una richiesta di trasferimento, l'utente deve eseguire gli accessi successivi tramite Okta. Questi tentativi di accesso non andranno a buon fine finché non avrai assegnato l'utente all'app in Okta.
Approccio 3: provisioning con creazione utenti disabilitata
In questo approccio, configurerai Google Workspace per gestire il Single Sign-On e il provisioning, ma attiverai solo le seguenti funzionalità di provisioning:
- Aggiorna attributi utente
- Disattivare gli utenti
Lascia disattivata l'opzione Crea utenti e assegna tutte le identità che alla fine devono accedere ai servizi Google all'app. Includi le identità con account consumer esistenti in modo da consentire il Single Sign-On per le identità con account consumer.
Se impedisci a Okta di creare account, impedisci a Okta di eseguire automaticamente il provisioning degli account utente per le identità con account consumer. Allo stesso tempo, questa configurazione consente comunque a Okta di propagare le modifiche degli attributi e le sospensioni degli utenti a Cloud Identity o Google Workspace per gli utenti che hanno un Account Google corrispondente.
Per le identità che non hanno un account utente corrispondente in Cloud Identity o Google Workspace, Okta potrebbe visualizzare un messaggio di errore nella Console di amministrazione Okta:
Per un utente che dispone di un account consumer esistente, l'account utente Cloud Identity o Google Workspace corrispondente viene creato automaticamente quando viene accettata la richiesta di trasferimento. Questo utente può quindi utilizzare immediatamente il Single Sign-On. Sebbene l'account utente sia funzionante, Okta potrebbe non mostrare ancora un'icona nella home page dell'utente e continuare a mostrare il messaggio di errore nell'interfaccia utente amministratore. Per risolvere il problema, riprova a eseguire l'attività di assegnazione nella dashboard dell'amministratore di Okta.
Questo approccio impedisce a Okta di eseguire con successo il provisioning automatico degli account utente per le identità con account consumer, ma consente comunque il Single Sign-On per le identità con account consumer. Inoltre, questo approccio è meno soggetto a errori di configurazione accidentali rispetto al secondo. Uno svantaggio è comunque che per gli utenti senza account consumer esistenti, devi creare manualmente gli account utente in Cloud Identity o Google Workspace.
Metodo 4: due app con assegnazione manuale
Puoi risolvere alcuni degli svantaggi degli approcci precedenti utilizzando due app, una per il provisioning e una per il Single Sign-On:
- Configura un'istanza dell'app Google Workspace per gestire solo il provisioning. La funzionalità Single Sign-On dell'app non viene utilizzata. Assegnando gli utenti a questa app, puoi controllare quali account di cui viene eseguito il provisioning in Cloud Identity o Google Workspace. Puoi assicurarti che questa app sia nascosta in modo efficace ai tuoi utenti attivando l'opzione Non mostrare l'icona dell'applicazione agli utenti.
- Configura un'altra istanza dell'app Google Workspace solo per scopi di Single Sign-On. Se assegni gli utenti a questa app, puoi stabilire chi è autorizzato ad accedere.
Utilizzando queste due app, assegna gli utenti nel seguente modo:
- Assegna all'app Single Sign-On tutte le identità che hanno bisogno di accedere ai servizi Google. Includi le identità con account consumer esistenti in modo da consentire il Single Sign-On per le identità con account consumer.
Quando assegni le identità all'app di provisioning, includi le identità che alla fine necessitano dell'accesso ai servizi Google, ma escludi tutte quelle note per avere un account consumer esistente. In questo modo, puoi impedire il provisioning automatico degli utenti per le identità con account consumer.
Ogni volta che un utente accetta una richiesta di trasferimento, assegna l'utente anche all'app.
Federazione con Okta: confronto
La seguente tabella riassume gli approcci.
| Consenti il Single Sign-On per le identità con account consumer | Impedisci il provisioning automatico degli utenti per le identità con account consumer | Impedisci l'eliminazione degli account di cui è stata eseguita la migrazione senza un'identità corrispondente nell'IdP esterno | Esegui automaticamente il provisioning di nuovi account | Aggiorna automaticamente gli account di cui è stata eseguita la migrazione | |
|---|---|---|---|---|---|
| Approccio 1: nessun provisioning | ✅ | ✅ | ✅ | X | X |
| Metodo 2: provisioning con assegnazione manuale | X | Rischiosi | ✅ | ✅ | ✅ |
| Approccio 3: provisioning con creazione utenti disabilitata | ✅ | ✅ | ✅ | X | ✅ |
| Metodo 4: due app con assegnazione manuale | ✅ | Rischiosi | ✅ | ✅ | ✅ |
Passaggi successivi
- Scopri come configurare la federazione con Active Directory o Microsoft Entra ID.
- Inizia la procedura di onboarding preparando gli account Cloud Identity o Google Workspace.