Se prevedi di federare Cloud Identity o Google Workspace con un provider di identità (IdP) esterno, ma devi comunque consolidare gli account consumer esistenti, questo documento ti aiuta a comprendere e valutare l'interazione tra federazione e consolidamento. Questo documento illustra anche come configurare la federazione in modo che non interferisca con la possibilità di consolidare gli account consumer esistenti.
Interazione tra la federazione e il consolidamento degli account utente
In una configurazione federata, colleghi Cloud Identity o Google Workspace a un'origine attendibile esterna in modo che l'origine attendibile possa eseguire automaticamente il provisioning degli account utente in Cloud Identity o Google Workspace.
Questi invarianti in genere valgono per una configurazione federata:
- L'origine attendibile è l'unica origine per le identità.
- In Cloud Identity o Google Workspace non sono presenti account utente diversi da quelli di cui è stato eseguito il provisioning dall'origine autorevole.
- Il provider di identità SAML non consente il Single Sign-On di Google per altre identità diverse da quelle per le quali l'origine attendibile ha eseguito il provisioning degli account utente.
Sebbene queste invariabili riflettano le best practice per la federazione di Google Cloud con un provider di identità esterno, causano problemi quando vuoi eseguire la migrazione degli account consumer esistenti:
- Gli account consumer esistenti non provengono dalla fonte autorevole. Questi account esistono già e ora devono essere collegati a un'identità nota dall'autorità di riferimento.
- Gli account consumer esistenti, una volta eseguita la migrazione a Cloud Identity o Google Workspace, sono account utente per i quali non è stato eseguito il provisioning dall'origine attendibile. La fonte autorevole deve riconoscere e "adottare" questi account di cui è stata eseguita la migrazione.
- Le identità degli account consumer esistenti potrebbero non essere note al provider di identità SAML, ma devono comunque essere autorizzate 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 provider di identità esterno, ma devi comunque consolidare gli account dei consumatori esistenti, devi assicurarti che la tua configurazione soddisfi inizialmente questi requisiti. Una volta completata la migrazione degli account dei consumatori esistenti, puoi modificare la configurazione perché i requisiti non sono più validi.
| Requisito | Motivazione |
|---|---|
| Consentire il Single Sign-On per le identità con account consumer | La migrazione di un account consumer richiede un trasferimento dell'account. Un amministratore di Cloud Identity o Google Workspace avvia il trasferimento dell'account, ma per completarlo il proprietario dell'account consumer deve dare il consenso. In qualità di amministratore, hai un controllo limitato sul momento in cui viene espresso il consenso e, di conseguenza, sul momento in cui viene eseguito il trasferimento.
Una volta che il proprietario ha espresso il consenso e il trasferimento è stato completato, tutti gli accessi successivi sono soggetti all'accesso singolo utilizzando il tuo IdP esterno. Affinché il Single Sign-On vada a buon fine, indipendentemente dal momento in cui viene completato il trasferimento, assicurati che il tuo IdP esterno consenta i Single Sign-On per le identità di tutti gli account consumer di cui vuoi 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 consumatore, la relativa configurazione e tutti i dati associati a Cloud Identity o Google Workspace.
Il comportamento predefinito di molti IdP esterni è creare in modo proattivo account utente in Cloud Identity o Google Workspace. Questo comportamento può causare inavvertitamente la creazione di account in conflitto. Se impedisci il provisioning automatico degli utenti per le identità con account consumer esistenti, eviti di creare inavvertitamente account in conflitto e garantisci che gli account consumer possano essere trasferiti correttamente. |
Se hai identificato account consumer senza un'identità corrispondente nell'IdP esterno che ritieni 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 tua capacità di eseguire la migrazione di questi account consumer.
| Requisito | Motivazione |
|---|---|
| Impedire 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
potrebbe sospenderlo o eliminarlo.
Se impedisci all'IDP esterno di sospendere o eliminare gli account sottoposti a migrazione senza corrispondenza dell'identità nell'IDP esterno, eviti di perdere la configurazione e i dati associati agli account interessati e ti assicuri 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 federare Cloud Identity o Google Workspace con Microsoft Entra ID (in precedenza Azure AD), puoi utilizzare l'app 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, pertanto il requisito di impedire l'eliminazione degli account di cui è stata eseguita la migrazione senza un'identità corrispondente nell'IdP esterno viene sempre soddisfatto.
A seconda di come configuri l'app Galleria, devi comunque assicurarti di svolgere 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, configuri l'app Galleria in modo che gestisca il Single Sign-On, ma non configuri 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 eventualmente avere bisogno di accedere ai servizi Google, anche se la migrazione dei loro account consumer esistenti è ancora in corso.
Per un utente che ha già un account consumer, l'account utente Cloud Identity o Google Workspace corrispondente viene creato automaticamente quando la richiesta di trasferimento viene accettata. L'utente può quindi utilizzare immediatamente Single Sign-On.
Per gli utenti che non dispongono di un account utente in Cloud Identity o Google Workspace, devi crearne uno manualmente.
Sebbene questo approccio soddisfi i requisiti ed è il meno complesso da configurare, presenta la limitazione che eventuali modifiche agli attributi o sospensioni degli utenti eseguite in Microsoft Entra ID non verranno propagate a Cloud Identity o Google Workspace.
Approccio 2: due app con assegnazione manuale
Con questo approccio, superi la limitazione 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 Single Sign-On:
- La prima app viene utilizzata esclusivamente per il provisioning di utenti e gruppi e ha il Single Sign-On disattivato. Se assegni gli utenti a questa app, puoi controllare quali account vengono configurati 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. Se assegni utenti a questa app, puoi controllare quali utenti sono autorizzati ad accedere.
Utilizzando queste due app, assegna gli utenti come segue:
- Assegna tutte le identità che potrebbero dover accedere ai servizi Google all'app Single Sign-On. 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 avranno bisogno di accedere ai servizi Google, ma escludi tutte le identità di cui è noto che hanno un account consumatore esistente. In questo modo, impedisci il provisioning automatico degli utenti per le identità con account consumer.
Approccio 3: due app con la creazione di 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. In genere, è meglio utilizzare un account super amministratore dedicato a questo scopo, perché gli account super amministratore sono esenti dal Single Sign On (ovvero non si applicano a loro eventuali configurazioni SSO; continueranno a utilizzare le password per l'accesso).
Tuttavia, per questo scenario, puoi fare in modo che Microsoft Entra ID utilizzi un account più limitato per la migrazione, che non consenta a Microsoft Entra ID di creare utenti. In questo modo, impedisci 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 con limitazioni in Cloud Identity o Google Workspace deve avere solo i seguenti privilegi:
- Unità organizzative > Lettura
- Utenti > Lettura
- 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 tabella seguente riassume gli approcci.
| Consentire il Single Sign-On per le identità con account consumer | Impedire il provisioning automatico degli utenti per le identità con account consumer | Impedire l'eliminazione degli account di cui è stata eseguita la migrazione senza un'identità corrispondente nell'IDP esterno | Eseguire il provisioning automatico dei nuovi account | Aggiornare automaticamente gli account sottoposti a migrazione | |
|---|---|---|---|---|---|
| Approccio 1: nessun provisioning | ✅ | ✅ | ✅ | X | X |
| Approccio 2: due app con assegnazione manuale | ✅ | Soggetto a errori manuali | ✅ | ✅ | ✅ |
| Approccio 3: due app con la creazione di utenti disattivata | ✅ | ✅ | ✅ | X | ✅ |
Rendere sicura la federazione di Active Directory per l'account
Se prevedi di federare Cloud Identity o Google Workspace con Active Directory, puoi utilizzare Google Cloud Directory Sync (GCDS) e Active Directory Federation Services (AD FS). Quando configuri GCDS e AD FS, devi assicurarti di svolgere quanto segue:
- 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 sottoposti a migrazione senza un'identità corrispondente nell'IDP esterno.
Esistono diversi modi per soddisfare questi requisiti. Ciascun approccio presenta vantaggi e svantaggi.
Approccio 1: disattiva GCDS
In questo approccio, configuri il Single Sign-On con AD FS, ma non attivi GCDS finché non hai completato la migrazione degli account utente non gestiti. Se disattivi GCDS, impedisci 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 regolamento di controllo dell'accesso personalizzato in AD FS e assegnalo a tutte le identità che potrebbero eventualmente avere bisogno di accedere ai servizi Google, anche se la migrazione dei loro account consumer esistenti è ancora in corso.
Per un utente che ha già un account consumer, l'account utente Cloud Identity o Google Workspace corrispondente viene creato automaticamente quando la richiesta di trasferimento viene accettata. Utilizzando il criterio di controllo dell'accesso personalizzato, ti assicuri che l'utente possa utilizzare immediatamente il Single Sign-On.
Per gli utenti che non dispongono di un account utente in Cloud Identity o Google Workspace, devi crearne uno manualmente.
Sebbene questo approccio soddisfi i requisiti ed è il meno complesso da configurare, presenta la limitazione che eventuali modifiche agli attributi o sospensioni degli utenti eseguite in Active Directory non verranno propagate a Cloud Identity o Google Workspace.
Approccio 2: GCDS con assegnazione manuale
Con questo approccio, superi la limitazione di dover creare manualmente gli account utente in Cloud Identity o Google Workspace per gli utenti che non hanno un account esistente:
Analogamente all'approccio 1, puoi consentire 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 eventualmente avere bisogno di accedere ai servizi Google, anche se i loro account consumer esistenti sono ancora soggetti alla migrazione.
Crea un gruppo in Active Directory che rifletta gli account utente di cui vuoi eseguire il provisioning automatico in GCDS. Nell'elenco dei membri, includi le identità che avranno eventualmente bisogno di accedere ai servizi Google, ma escludi tutte le identità di cui è noto che hanno un account consumer esistente.
Configura GCDS in modo da eseguire il provisioning degli account utente solo per le identità che fanno parte di questo gruppo. In questo modo, 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 GCDS di creare utenti
Quando configuri il provisioning, devi autorizzare GCDS ad accedere a Cloud Identity o Google Workspace. In genere, è meglio utilizzare un account super amministratore dedicato a questo scopo, perché questi account sono esenti dal Single Sign On (ovvero non si applicano a loro configurazioni SSO; continueranno a utilizzare le password per l'accesso).
Tuttavia, per questo scenario, puoi chiedere a GCDS di utilizzare un account più limitato per la migrazione, che non consenta di creare utenti. In questo modo, impedisci a GCDS 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 con limitazioni in Cloud Identity o Google Workspace deve avere solo i seguenti privilegi:
- Unità organizzative
- Utenti > Lettura
- 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 tabella seguente riassume gli approcci.
| Consentire il Single Sign-On per le identità con account consumer | Impedire il provisioning automatico degli utenti per le identità con account consumer | Impedire l'eliminazione degli account di cui è stata eseguita la migrazione senza un'identità corrispondente nell'IDP esterno | Eseguire il provisioning automatico dei nuovi account | Aggiornare automaticamente gli account sottoposti a migrazione | |
|---|---|---|---|---|---|
| Approccio 1: non configurare il provisioning | ✅ | ✅ | ✅ | X | X |
| Approccio 2: GCDS con assegnazione manuale | ✅ | Soggetto a errori manuali | X | ✅ | ✅ |
| Approccio 3: non consentire a GCDS di creare utenti | ✅ | ✅ | ✅ | X | ✅ |
Rendere sicura la federazione di 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 di Okta. Questa app può gestire il Single Sign-On e il provisioning di utenti e gruppi in 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, pertanto il requisito di impedire l'eliminazione degli account di cui è stata eseguita la migrazione senza un'identità corrispondente nell'IdP esterno viene sempre soddisfatto.
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, configuri l'app Google Workspace per gestire il Single Sign-On, ma non configuri affatto 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 eventualmente avere bisogno di accedere ai servizi Google, anche se la migrazione dei loro account consumer esistenti è ancora in corso. 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 lato Google.
Per un utente che ha già un account consumer, l'account utente Cloud Identity o Google Workspace corrispondente viene creato automaticamente quando la richiesta di trasferimento viene accettata. L'utente può quindi utilizzare immediatamente Single Sign-On.
Sebbene questo approccio soddisfi i requisiti ed è il meno complesso da configurare, presenta la limitazione che eventuali modifiche agli 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 gli account in Cloud Identity o Google Workspace per tutti gli utenti che non hanno un account consumer esistente.
Approccio 2: esegui il provisioning con l'assegnazione manuale
In questo approccio, configuri l'app Google Workspace per gestire l'accesso singolo e il provisioning, ma attivi solo le seguenti funzionalità di provisioning:
- Crea utenti
- Aggiorna gli attributi utente
- Disattivare gli utenti
Quando assegni le identità all'app, includi quelle che potrebbero aver bisogno di accedere ai servizi Google, ma escludi tutte le identità di cui è noto che hanno un account consumatore esistente. In questo modo, 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 commesso nell'assegnazione può portare immediatamente alla creazione di un account in conflitto, il che rende questo approccio molto più rischioso di altri.
Un altro svantaggio di questo approccio è che causa blocchi temporanei degli account sottoposti a migrazione. Dopo aver accettato una richiesta di trasferimento, un utente deve eseguire eventuali 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 la creazione di utenti disattivata
In questo approccio, configuri Google Workspace per gestire il Single Sign-On e il provisioning, ma attivi solo le seguenti funzionalità di provisioning:
- Aggiorna gli attributi utente
- Disattivare gli utenti
Lascia disattivata l'opzione Crea utenti e assegna all'app tutte le identità che eventualmente dovranno 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.
Se non consenti a Okta di creare account, impedisci a Okta di eseguire il provisioning automatico degli account utente per le identità con account consumer. Allo stesso tempo, questa configurazione consente comunque a Okta di propagare le modifiche agli attributi e le sospensioni degli utenti a Cloud Identity o Google Workspace per gli utenti che dispongono di un Account Google corrispondente.
Per le identità che non dispongono di un account utente corrispondente in Cloud Identity o Google Workspace, Okta potrebbe mostrare un messaggio di errore nella Console di amministrazione Okta:
Per un utente che ha già un account consumer, l'account utente Cloud Identity o Google Workspace corrispondente viene creato automaticamente quando la richiesta di trasferimento viene accettata. L'utente può quindi utilizzare immediatamente Single Sign-On. Anche se l'account utente è funzionale a questo punto, Okta potrebbe non mostrare ancora un'icona nella home page dell'utente e potrebbe invece continuare a mostrare il messaggio di errore nell'interfaccia utente Amministrazione. Per risolvere il problema, riprova l'attività di assegnazione nella dashboard di amministrazione di Okta.
Questo approccio impedisce a Okta di eseguire il provisioning automatico degli account utente per le identità con account consumer, ma consente comunque di eseguire ilSingle Sign-On per le identità con account consumer. Inoltre, è meno soggetto a errori di configurazione accidentali rispetto al secondo approccio. Un aspetto negativo è che, per gli utenti che non dispongono di account consumer esistenti, devi creare manualmente gli account utente in Cloud Identity o Google Workspace.
Approccio 4: due app con assegnazione manuale
Puoi superare 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à di Single Sign-On dell'app non viene utilizzata. Se assegni gli utenti a questa app, puoi controllare quali account vengono configurati in Cloud Identity o Google Workspace. Puoi assicurarti che questa app sia effettivamente nascosta agli utenti attivando l'opzione Non mostrare agli utenti l'icona dell'applicazione.
- Configura un'altra istanza dell'app Google Workspace solo per il Single Sign-On. Se assegni gli utenti a questa app, puoi controllare chi è autorizzato ad accedere.
Utilizzando queste due app, assegna gli utenti come segue:
- Assegna tutte le identità che potrebbero dover accedere ai servizi Google all'app Single Sign-On. 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 avranno bisogno di accedere ai servizi Google, ma escludi tutte le identità di cui è noto che hanno un account consumatore esistente. In questo modo, impedisci il provisioning automatico degli utenti per le identità con account consumer.
Ogni volta che un utente accetta una richiesta di trasferimento, assegnilo anche all'app.
Federazione con Okta: confronto
La tabella seguente riassume gli approcci.
| Consentire il Single Sign-On per le identità con account consumer | Impedire il provisioning automatico degli utenti per le identità con account consumer | Impedire l'eliminazione degli account di cui è stata eseguita la migrazione senza un'identità corrispondente nell'IDP esterno | Eseguire il provisioning automatico dei nuovi account | Aggiornare automaticamente gli account sottoposti a migrazione | |
|---|---|---|---|---|---|
| Approccio 1: nessun provisioning | ✅ | ✅ | ✅ | X | X |
| Approccio 2: esegui il provisioning con l'assegnazione manuale | X | Rischiose | ✅ | ✅ | ✅ |
| Approccio 3: provisioning con la creazione di utenti disattivata | ✅ | ✅ | ✅ | X | ✅ |
| Approccio 4: due app con assegnazione manuale | ✅ | Rischiose | ✅ | ✅ | ✅ |
Passaggi successivi
- Scopri come configurare la federazione con Active Directory o Microsoft Entra ID.
- Per iniziare la procedura di onboarding, prepara gli account Cloud Identity o Google Workspace.