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 mostra anche come configurare la federazione in modo da non interferire con la tua capacità di consolidare gli account consumer esistenti.
Interazione tra federazione e consolidamento degli account utente
In una configurazione federata, connetti Cloud Identity o Google Workspace a un'origine autorevole esterna in modo che l'origine autorevole possa eseguire automaticamente il provisioning degli account utente in Cloud Identity o Google Workspace.
Queste invarianti in genere valgono per una configurazione federata:
- L'origine autorevole è 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 (SSO) di Google per identità diverse da quelle per cui l'origine autorevole ha effettuato il provisioning degli account utente.
Sebbene queste invarianti riflettano le best practice per la federazione Google Cloud con un provider di identità esterno, causano problemi quando vuoi eseguire la migrazione di account consumer esistenti:
- Gli account consumer esistenti non provengono dall'origine autorevole. Questi account esistono già e ora devono essere collegati a un'identità nota all'origine autorevole.
- Gli account consumer esistenti, una volta migrati a Cloud Identity o Google Workspace, sono account utente che non sono stati sottoposti al provisioning dall'origine autorevole. L'origine autorevole 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 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 la federazione sicura per il consolidamento degli account
La tabella seguente elenca i requisiti da considerare per rendere la federazione sicura 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. Una volta completata la migrazione degli account consumer 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 acconsentire al trasferimento. In qualità di amministratore, hai
un controllo limitato su quando verrà espresso il consenso e quindi su quando
verrà effettuato il trasferimento.
Una volta che il proprietario esprime il consenso e il trasferimento è completato, tutti i successivi accessi sono soggetti al Single Sign-On utilizzando l'IdP esterno. Perché il Single Sign-On funzioni, indipendentemente da quando viene completato il trasferimento, assicurati che il tuo IdP esterno consenta i Single Sign-On per le identità di tutti gli account consumer che intendi 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, la sua configurazione e tutti i dati associati a Cloud Identity o Google Workspace.
Il comportamento predefinito di molti IdP esterni è quello di 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 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 tua capacità di eseguire la migrazione di questi account consumer.
| Requisito | Motivazione |
|---|---|
| Impedire l'eliminazione degli account sottoposti a migrazione senza un'identità corrispondente nel provider di identità esterno | Se hai un account utente in Cloud Identity o Google Workspace che non ha un'identità corrispondente nel tuo IdP esterno, quest'ultimo potrebbe considerare questo account utente orfano e potrebbe sospenderlo o eliminarlo. |
Rendere federata Microsoft Entra ID (in precedenza Azure AD) sicura 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 Google Workspace Gallery.
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 migrati senza un'identità corrispondente nell'IdP esterno è sempre soddisfatto.
A seconda di come configuri l'app Galleria, devi comunque assicurarti di fare quanto segue:
- Consenti il Single Sign-On per le identità con account consumer.
- Impedisci 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
Con questo approccio, configuri l'app galleria per gestire 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 aver bisogno di accedere ai servizi Google, anche se i loro account consumer esistenti sono ancora soggetti a migrazione.
Per un utente che ha un account consumer esistente, 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 e sia 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 è di 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 disattivato. Assegnando utenti a questa app, controlli quali account vengono sottoposti al 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 utenti a questa app, controlli quali utenti sono autorizzati ad accedere.
Utilizzando queste due app, assegna gli utenti nel seguente modo:
- Assegna tutte le identità che alla fine devono 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 devono accedere ai servizi Google, ma escludi tutte le identità che hanno un account consumer 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, è consigliabile utilizzare un account super amministratore dedicato a questo scopo, perché gli account super amministratore sono esenti dal Single Sign-On (ovvero, qualsiasi configurazione SSO non si applica a loro; 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, uno che non consenta a Microsoft Entra ID di creare utenti. In questo modo, puoi impedire ad Azure di eseguire automaticamente il provisioning degli account utente per le identità con account consumer, indipendentemente dagli utenti assegnati all'app di provisioning.
Un account utente amministratore con accesso limitato in Cloud Identity o Google Workspace deve disporre solo dei 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 riepiloga gli approcci.
| Consenti 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 sottoposti a migrazione senza un'identità corrispondente nel provider di identità esterno | Provisioning automatico di 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 fare quanto segue:
- 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 nel provider di identità esterno.
Esistono diversi modi per soddisfare questi requisiti. Ciascun approccio presenta vantaggi e svantaggi.
Approccio 1: disattiva GCDS
Con 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 criterio di controllo dell'accesso personalizzato in AD FS e assegna tutte le identità che potrebbero aver bisogno di accedere ai servizi Google, anche se i loro account consumer esistenti sono ancora soggetti a migrazione.
Per un utente che ha un account consumer esistente, 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 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: GCDS con assegnazione manuale
Con questo approccio, superi la limitazione di dover creare manualmente account utente in Cloud Identity o Google Workspace per gli utenti che non hanno un account esistente:
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 aver 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 alla fine devono accedere ai servizi Google, ma escludi tutte le identità che hanno un account consumer esistente.
Configura GCDS in modo da eseguire il provisioning degli account utente solo per le identità che sono membri di questo gruppo. In questo modo, impedisci 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 migrati senza un'identità corrispondente nel provider di identità esterno. Pertanto, l'approccio è applicabile solo se non hai account consumer senza un'identità corrispondente nell'IdP esterno.
Approccio 3: impedisci a GCDS di creare utenti
Quando configuri il provisioning, devi autorizzare GCDS ad accedere a Cloud Identity o Google Workspace. In genere, è consigliabile utilizzare un account super amministratore dedicato a questo scopo, perché questi account sono esenti dal Single Sign-On (ovvero, qualsiasi configurazione SSO non si applica a loro, che continueranno a utilizzare le password per l'accesso).
Tuttavia, per questo scenario, puoi fare in modo che GCDS utilizzi un account più limitato per la migrazione, che non consenta la creazione di 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 accesso limitato in Cloud Identity o Google Workspace deve disporre solo dei 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 riepiloga gli approcci.
| Consenti 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 sottoposti a migrazione senza un'identità corrispondente nel provider di identità esterno | Provisioning automatico di 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: impedisci 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 delle app 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 tutti 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 migrati 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.
- Impedisci 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 Google Workspace per gestire il Single Sign-On, ma non configuri 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 aver bisogno di accedere ai servizi Google, anche se i loro 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 ha un account consumer esistente, 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 e sia 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: provisioning con assegnazione manuale
Con questo approccio, configuri l'app Google Workspace per gestire il single sign-on e il provisioning, ma attivi solo le seguenti funzionalità di provisioning:
- Crea utenti
- Aggiorna gli attributi utente
- Disattivare gli utenti
Quando assegni identità all'app, includi le identità che alla fine devono accedere ai servizi Google, ma escludi tutte le identità che hanno un account consumer esistente. In questo modo, impedisci il provisioning automatico degli utenti per le identità con account consumer.
Non appena un utente accetta una richiesta di trasferimento, assegnagli l'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 migrati. Dopo aver accettato una richiesta di trasferimento, un utente deve eseguire tutti 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 utente disattivata
Con questo approccio, configuri Google Workspace per gestire il Single Sign-On e il provisioning, ma attivi solo le seguenti funzionalità di provisioning:
- Aggiornare gli attributi utente
- Disattivare gli utenti
Lascia disattivata l'opzione Crea utenti e assegna all'app tutte le identità che alla fine devono 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 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 ha un account consumer esistente, 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 l'account utente sia funzionante a questo punto, Okta potrebbe non visualizzare ancora un'icona nella home page dell'utente e potrebbe continuare a visualizzare il messaggio di errore nell'interfaccia utente amministrativa. Per risolvere il problema, riprova l'attività di assegnazione nella dashboard di amministrazione Okta.
Questo approccio impedisce a Okta di eseguire automaticamente il provisioning 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 è che per gli utenti senza 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à Single Sign-On dell'app non viene utilizzata. Assegnando utenti a questa app, controlli quali account vengono sottoposti al provisioning in Cloud Identity o Google Workspace. Puoi assicurarti che questa app sia effettivamente nascosta 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. Assegnando gli utenti a questa app, controlli chi è autorizzato ad accedere.
Utilizzando queste due app, assegna gli utenti nel seguente modo:
- Assegna tutte le identità che alla fine devono 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 devono accedere ai servizi Google, ma escludi tutte le identità che hanno un account consumer 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, assegnalo anche all'app.
Federazione con Okta: confronto
La tabella seguente riepiloga gli approcci.
| Consenti 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 sottoposti a migrazione senza un'identità corrispondente nel provider di identità esterno | Provisioning automatico di nuovi account | Aggiornare automaticamente gli account sottoposti a migrazione | |
|---|---|---|---|---|---|
| Approccio 1: nessun provisioning | ✅ | ✅ | ✅ | X | X |
| Approccio 2: provisioning con assegnazione manuale | X | Rischiose | ✅ | ✅ | ✅ |
| Approccio 3: provisioning con creazione utente disattivata | ✅ | ✅ | ✅ | X | ✅ |
| Approccio 4: due app con assegnazione manuale | ✅ | Rischiose | ✅ | ✅ | ✅ |
Passaggi successivi
- Esamina come puoi configurare la federazione con Active Directory o Microsoft Entra ID.
- Inizia la procedura di onboarding preparando gli account Cloud Identity o Google Workspace.