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 spiega anche come configurare la federazione in modo che non interferisca con la tua capacità 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 servizio Single Sign-On di Google per nessuna identità diverse da quelle per le quali la fonte autorevole ha di cui è stato eseguito il provisioning.
Sebbene questi elementi invarianti riflettano best practice per la federazione di Google Cloud con un provider di identità esterno, ma ciò può causare problemi quando vuoi eseguire la migrazione di account consumer esistenti:
- Gli account consumer esistenti non provengono da fonti autorevoli sorgente. 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. L'autorevole la sorgente deve riconoscere e "adottare" a 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
Nella tabella seguente sono elencati i requisiti da prendere in considerazione per rendere e la federazione è sicura per il consolidamento degli account. Se hai intenzione di usa un IdP esterno ma ancora dover consolidare account consumer esistenti, bisogna poi assicurati che la configurazione iniziale soddisfi questi requisiti. Dopo aver ottenuto completato la migrazione degli account consumer esistenti, puoi modificare la configurazione perché i requisiti non saranno più validi.
| Requisito | Motivazione |
|---|---|
| Consenti 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 a disposizione
un controllo limitato su quando il consenso verrà espresso e quindi su quando
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 proattivamente account utente in Cloud Identity o Google Workspace. Questo comportamento può causare inavvertitamente la creazione di account in conflitto. Impedisce il provisioning automatico degli utenti per le identità con account di account consumer, si evita di creare inavvertitamente account in conflitto e garantire 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. |
Rendi sicura la federazione Microsoft Entra ID (in precedenza Azure AD) per il consolidamento degli account
Se hai intenzione di federate Cloud Identity o Google Workspace con Microsoft Entra ID (in precedenza Azure AD), puoi utilizzare 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, quindi il requisito impedire l'eliminazione degli account di cui è stata eseguita la migrazione senza un'identità corrispondente nell'IdP esterno viene sempre rispettato.
A seconda di come configuri l'app Galleria, devi comunque assicurarti di segui questi passaggi:
- 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 ha vantaggi e svantaggi.
Approccio 1: non configurare il provisioning
Con questo approccio configuri l'app Galleria per gestire il Single Sign-On, senza configurare il provisioning automatico degli utenti. Se non configuri il provisioning degli utenti, impedisci il provisioning automatico degli utenti per le identità con account consumer.
A consentire il Single Sign-On per le identità con account consumer, assegnare l'app a tutte le identità che potrebbero richiedere l'accesso a Google servizi, anche se i loro account consumer esistenti sono ancora soggetti a di cui è stata eseguita la migrazione.
Per un utente che dispone già di un account consumer, viene restituito il codice È stato creato un account utente di Cloud Identity o Google Workspace automaticamente quando la richiesta di trasferimento viene accettata. L'utente può quindi utilizzare immediatamente 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 ed è il meno complesso da impostare viene applicata la limitazione per cui le modifiche agli attributi o le sospensioni degli utenti eseguite in Microsoft Entra ID non verranno propagate in Cloud Identity Google Workspace.
Approccio 2: due app con assegnazione manuale
Con questo approccio, viene superato il limite di dover creare manualmente gli utenti in Google Workspace o Cloud Identity per gli utenti che non hai un account esistente. L'idea è quella di utilizzare due app galleria, una per e uno per Single Sign-On:
- La prima app viene utilizzata esclusivamente per il provisioning di utenti e gruppi e ha Single Sign-On disabilitato. 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 è autorizzati a eseguire il provisioning degli utenti. Assegnando gli utenti a questa app, controlli a cui gli utenti sono autorizzati ad accedere.
Utilizzando queste due app, assegna gli utenti come segue:
- Assegna tutte le identità che alla fine hanno bisogno di accedere ai servizi Google a l'app Single Sign-On. Includi identità con account consumer esistenti in modo da consentire il Single Sign-On per le identità con account consumer.
- Quando assegni identità all'app di provisioning, includi i identità che alla fine richiedono l'accesso ai servizi Google, ma escludono tutte identità note per avere un account consumatore esistente. In questo modo tu impedire 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, 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, in modo efficace impedire ad Azure di eseguire il provisioning automatico degli account utente per le identità con account consumer, a prescindere dagli utenti assegnati all'app di provisioning.
Avere un account utente amministratore con restrizioni in Cloud Identity oppure Google Workspace deve disporre solo dei seguenti privilegi:
- Unità organizzative > Letto
- 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.
Federata con Microsoft Entra ID: confronto
La seguente tabella riassume gli approcci.
| Consentire il Single Sign-On per le identità con account consumer | Impedisci il provisioning automatico degli utenti per le identità con consumer account | Impedisci l'eliminazione degli account di cui è stata eseguita la migrazione senza un'identità corrispondente nel 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 | ✅ | Soggetta a errori manuali | ✅ | ✅ | ✅ |
| Approccio 3: due app con la creazione di utenti disattivata | ✅ | ✅ | ✅ | X | ✅ |
Rendi sicura la federazione di Active Directory per l'account
Se hai intenzione di federate Cloud Identity o Google Workspace con Active Directory, puoi utilizzare Google Cloud Directory Sync (GCDS) e Active Directory Federation Services (ADFS). 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 di cui è stata eseguita la migrazione senza un'identità corrispondente nell'IdP esterno.
Esistono diversi modi per soddisfare questi requisiti. Ogni approccio ha vantaggi e svantaggi.
Approccio 1: disattivare 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 dispone già di un account consumer, viene restituito il codice È stato creato un account utente di Cloud Identity o Google Workspace 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 hanno 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 che per 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 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, in questo scenario, è possibile far usare a GCDS per la migrazione, un account che non consente 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 limitazioni in Cloud Identity o Google Workspace deve avere solo i seguenti privilegi:
- Unità organizzative
- Utenti > Letto
- 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 | Impedisci il provisioning automatico degli utenti per le identità con consumer account | Impedisci l'eliminazione degli account di cui è stata eseguita la migrazione senza un'identità corrispondente nel 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 | ✅ | Soggetta a errori manuali | X | ✅ | ✅ |
| Approccio 3: non consentire a GCDS di creare utenti | ✅ | ✅ | ✅ | X | ✅ |
Rendi 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 di Okta. Questa app può gestire Single Sign-On ed eseguire il provisioning di utenti e gruppi in Cloud Identity o Google Workspace.
Quando utilizzi l'app Google Workspace per il provisioning, Okta ignora qualsiasi per gli utenti esistenti in Cloud Identity o Google Workspace che non avere una controparte in Okta, quindi il requisito impedire l'eliminazione degli account di cui è stata eseguita la migrazione senza un'identità corrispondente nell'IdP esterno viene sempre rispettato.
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. Ogni approccio presenta vantaggi e svantaggi.
Approccio 1: non configurare il provisioning
In questo approccio, configuri Google Workspace per gestire il Single Sign-On, ma non configurare del 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 sono visualizzate sulla Home page di Okta di tutte le identità assegnate all'app. Tuttavia, l'accesso non riuscirà se non esiste un account utente corrispondente Lato Google.
Per un utente che dispone già di un account consumer, viene restituito il codice È stato creato un account utente di Cloud Identity o Google Workspace 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 dispongono di un account consumer esistente.
Approccio 2: eseguire 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 identità all'app, che includono le identità che alla fine hanno bisogno di accedere ai servizi Google, escludere tutte le identità note per avere un account consumatore 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, 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 provoca blocchi temporanei a cui è stata eseguita la 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é hanno assegnato l'utente all'app in Okta.
Approccio 3: eseguire il provisioning con la creazione utenti disattivata
Con questo approccio, configuri Google Workspace per gestire il Single Sign-On e il provisioning, ma attivare 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 impedisci a Okta di creare account, impedire 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 sospensioni degli utenti a Cloud Identity o Google Workspace per gli utenti che hanno 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. Sebbene l'account utente funzioni in questo punto, Okta potrebbe non mostrare ancora un'icona sulla home page dell'utente e continueranno a essere visualizzati il messaggio di errore nell'interfaccia utente amministratore. Per risolvere il problema, riprova a eseguire l'attività di assegnazione nella dashboard di amministrazione di Okta.
Questo approccio ha avuto successo impedisce a Okta di eseguire automaticamente il provisioning degli account utente per le identità con account consumer, ma ancora consente il Single 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 ovviare ad 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 per quali account viene eseguito Cloud Identity o Google Workspace. Puoi assicurarti che viene nascosta agli utenti in modo efficace attivando il pulsante Non visualizzare icona dell'applicazione per gli utenti.
- Configura un'altra istanza App Google Workspace solo per scopi Single Sign-On. Assegnando utenti a questa app, puoi stabilire chi può accedere.
Utilizzando queste due app, assegna gli utenti nel seguente modo:
- 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 tu 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 all'app .
Federata con Okta: confronto
La tabella seguente riassume gli approcci.
| Consentire il Single Sign-On per le identità con account consumer | Impedisci il provisioning automatico degli utenti per le identità con consumer account | Impedisci l'eliminazione degli account di cui è stata eseguita la migrazione senza un'identità corrispondente nel IdP esterno | Eseguire il provisioning automatico dei nuovi account | Aggiornare automaticamente gli account sottoposti a migrazione | |
|---|---|---|---|---|---|
| Approccio 1: nessun provisioning | ✅ | ✅ | ✅ | X | X |
| Approccio 2: eseguire 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 avviare la procedura di onboarding, preparazione degli account Cloud Identity o Google Workspace.