Tutti i servizi Google, inclusi Google Cloud, Google Marketing Platform e Google Ads, si basano su Accedi con Google per autenticare gli utenti. Questo documento spiega il modello di dominio su cui si basa Accedi con Google per l'autenticazione e la gestione delle identità. Il modello di dominio ti aiuta a capire come funziona Accedi con Google in un contesto aziendale, come vengono gestite le identità e come è possibile facilitare l'integrazione con un provider di identità esterno (IdP). Il seguente diagramma mostra l'interazione di queste entità.
Come mostra questo diagramma, al centro del modello c'è l'identità Google, che viene utilizzata da Accedi con Google. L'identità Google è correlata a una serie di altre entità, tutte pertinenti nel contesto della gestione delle identità:
- Google per i consumatori include le entità pertinenti per l'utilizzo dei servizi Google orientato ai consumatori, come Gmail.
- Google per le organizzazioni contiene entità gestite da Cloud Identity o Google Workspace. Queste entità sono le più pertinenti per la gestione delle identità aziendali.
- Google Cloud contiene le entità specifiche di Google Cloud.
- Il valore Esterno contiene entità pertinenti se integri Google con un IdP esterno.
Le frecce continue nel diagramma indicano che le entità fanno riferimento l'una all'altra o si contengono. Le frecce tratteggiate indicano invece una relazione di federazione.
Identità Google
Identità, utenti e account utente svolgono un ruolo fondamentale nella gestione delle identità. I tre termini sono strettamente correlati e a volte vengono anche utilizzati in modo intercambiabile. Tuttavia, nel contesto della gestione delle identità, vale la pena distinguere tra i concetti:
Un'identità è un nome che identifica in modo univoco la persona che interagisce con un servizio Google. A questo scopo, Google utilizza gli indirizzi email. L'indirizzo email di una persona è considerato l'identità Google di una persona.
Il processo di verifica dell'associazione tra una persona e un'identità si chiama autenticazione o accesso, facendo in modo che la persona dimostri che si tratta effettivamente della sua identità.
Una persona potrebbe avere più indirizzi email. Poiché i servizi Google utilizzano un indirizzo email come identità, una persona di questo tipo viene considerata avere più identità.
Un account utente è una struttura di dati che tiene traccia di attributi, attività e configurazioni che devono essere applicati ogni volta che una determinata identità interagisce con un servizio Google. Gli account utente non vengono creati all'istante, ma devono essere sottoposti a provisioning prima del primo accesso.
Gli account utente sono identificati da un ID non esposto all'esterno. Le interfacce utente o le API richiedono quindi di fare riferimento all'account utente indirettamente tramite l'identità associata, ad esempio
alice@gmail.com. Nonostante questa indiretta, tutti i dettagli di dati e configurazione sono associati all'account utente, non all'identità.
Nella maggior parte dei casi, esiste una relazione one-to-one tra account utente e identità, che li rende facili da confondere. Tuttavia, non è sempre così, come illustrato nei seguenti casi limite:
La relazione tra gli account utente e le identità non è fissa. Puoi modificare l'indirizzo email principale di un account utente, che associa un'identità diversa all'utente.
In qualità di amministratore di Cloud Identity o Google Workspace, puoi anche scambiare gli indirizzi email principali di due utenti. Ad esempio, se hai scambiato gli indirizzi email principali di Alice (
alice@example.com) e di Roberto (bob@example.com), Alice utilizzerà l'account utente precedente di Roberto mentre Mario utilizzerà l'account utente precedente di Alice. Poiché i dati e la configurazione sono associati all'account utente e non all'identità, Alice ora utilizzerà anche la configurazione e i dati esistenti di Bob (e Bob ora utilizzerà la configurazione e i dati di Alice). La figura seguente mostra questa relazione.
In una configurazione non federata, dovresti anche reimpostare le password affinché Alice e Bob possano scambiare gli account utente. In una configurazione federata in cui Alice e Bob utilizzano un IdP esterno per l'autenticazione, non è necessario reimpostare le password.
La relazione tra identità e utenti potrebbe non essere 1:1. Un account consumer può essere associato intenzionalmente a più identità, come nel diagramma seguente.
È anche possibile che un'identità si riferisca a due account utente diversi. Ti consigliamo di evitare questa situazione, ma può verificarsi nel caso di un account utente in conflitto. In questo caso, durante l'autenticazione, un utente visualizza una schermata elettorale in cui seleziona l'account utente da utilizzare.
Google distingue tra due tipi di account utente: account utente consumer e account utente gestiti. Le seguenti sezioni descrivono in modo più dettagliato entrambi i tipi di account utente e le relative entità correlate.
Google per i consumatori
Se possiedi un indirizzo email Gmail, come alice@gmail.com, il tuo account Gmail è un account consumer. Analogamente, se utilizzi il link Crea account nella pagina Accedi con Google e durante la registrazione fornisci un indirizzo email personalizzato di tua proprietà, ad esempio alice@example.com, l'account risultante sarà anche un account consumer.
Account consumer
Gli account consumer sono creati tramite self-service e sono destinati principalmente a essere utilizzati per scopi privati. La persona che ha creato l'account consumer ha il pieno controllo dell'account e di tutti i dati creati utilizzando l'account. L'indirizzo email che quella persona ha utilizzato durante la registrazione diventa l'indirizzo email principale dell'account consumer e serve da identità. Questa persona può aggiungere indirizzi email all'account consumer. Questi indirizzi email fungono da identità aggiuntive e possono essere utilizzati anche per accedere.
Quando un account consumer utilizza un indirizzo email principale che corrisponde al dominio principale o secondario di un account Cloud Identity o Google Workspace, l'account consumer viene anche definito account utente non gestito.
Un account consumer può essere membro di un numero qualsiasi di gruppi.
Google per le organizzazioni
Se la tua organizzazione utilizza i servizi Google, ti consigliamo di utilizzare account utente gestiti. Questi account vengono definiti gestiti perché il loro ciclo di vita e la configurazione possono essere completamente controllati dall'organizzazione.
Gli account utente gestiti sono una funzionalità di Cloud Identity e Google Workspace.
Account Cloud Identity o Google Workspace
Un account Cloud Identity o Google Workspace è il contenitore di primo livello per utenti, gruppi, configurazione e dati. Un account Cloud Identity o Google Workspace viene creato quando un'azienda si registra a Cloud Identity o Google Workspace e corrisponde al concetto di tenant.
Cloud Identity e Google Workspace condividono una piattaforma tecnica comune. Entrambi i prodotti utilizzano lo stesso set di API e strumenti amministrativi e condividono la nozione di account come contenitore per utenti e gruppi; questo contenitore è identificato da un nome di dominio. Ai fini della gestione di utenti, gruppi e autenticazione, i due prodotti possono essere in gran parte considerati equivalenti.
Un account contiene gruppi e una o più unità organizzative.
Unità organizzativa
Un'unità organizzativa (UO) è un sottocontenitore per gli account utente che ti consente di segmentare gli account utente definiti nell'account Cloud Identity o Google Workspace in insiemi separati per facilitarne la gestione.
Le unità organizzative sono organizzate in modo gerarchico. Ogni account Cloud Identity o Google Workspace ha una UO principale, in cui puoi creare altre UO in base alle tue esigenze. Puoi anche nidificare le UO.
Cloud Identity e Google Workspace consentono di applicare determinate configurazioni per unità organizzativa, ad esempio l'assegnazione delle licenze o la verifica in due passaggi. Queste impostazioni vengono applicate automaticamente a tutti gli utenti della UO e vengono ereditate dalle UO secondarie. Le unità organizzative svolgono quindi un ruolo chiave nella gestione della configurazione di Cloud Identity e Google Workspace.
Un account utente non può appartenere a più di una UO, il che rende le UO diverse dai gruppi. Sebbene le UO siano utili per applicare la configurazione agli account utente, non sono destinate a essere utilizzate per gestire l'accesso. Per gestire l'accesso, ti consigliamo di usare i gruppi.
Sebbene le UO siano simili alle cartelle di Google Cloud, le due entità hanno scopi diversi e non sono correlate a un'altra.
Account utente gestito
Gli account utente gestiti funzionano in modo simile agli account utente consumer, ma possono essere completamente controllati dagli amministratori dell'account Cloud Identity o Google Workspace.
L'identità di un account utente gestito viene definita dal suo indirizzo email principale.
L'indirizzo email principale deve utilizzare un dominio corrispondente a uno dei domini principali, secondari o alias aggiunti all'account Cloud Identity o Google Workspace. Gli account utente gestiti possono avere indirizzi email alias aggiuntivi e un indirizzo email di recupero, ma questi indirizzi non sono considerati identità e non possono essere utilizzati per l'accesso. Ad esempio, se Alice utilizza alice@example.com come indirizzo email principale
e ha configurato ally@example.com come indirizzo email alias e
alice@gmail.com come indirizzo email di recupero, l'unico indirizzo email che Alice può utilizzare per accedere è alice@example.com.
Gli account utente gestiti sono contenuti da un'unità organizzativa e possono essere membri di un numero qualsiasi di gruppi.
Gli account utente gestiti sono destinati a essere utilizzati da utenti umani anziché utenti di macchine. Un account utente macchina è un tipo speciale di account utilizzato da un'applicazione o da un'istanza di macchina virtuale (VM), non da una persona. Per gli utenti delle macchine, Google Cloud fornisce account di servizio. Gli account di servizio vengono discussi in modo più dettagliato più avanti in questo documento.
Gruppo
I gruppi ti consentono di raggruppare più utenti. Puoi utilizzare i gruppi per gestire una mailing list o per applicare una configurazione o controllo dell'accesso comune a più utenti.
Cloud Identity e Google Workspace identificano i gruppi in base all'indirizzo email, ad esempio billing-admins@example.com. Analogamente all'indirizzo email principale di un utente, l'indirizzo email del gruppo deve utilizzare uno dei domini principali, secondari o alias dell'account Cloud Identity o Google Workspace. L'indirizzo email non deve necessariamente corrispondere a una casella di posta, a meno che il gruppo non venga utilizzato come mailing list. L'autenticazione viene comunque eseguita utilizzando l'indirizzo email dell'utente anziché l'indirizzo email del gruppo, quindi un utente non può accedere utilizzando un indirizzo email di gruppo.
Un gruppo può avere come membri le seguenti entità:
- Utenti (utenti gestiti o account consumer)
- Altri gruppi
- Account di servizio
A differenza di un'unità organizzativa, i gruppi non funzionano come contenitori:
- Un utente o gruppo può essere membro di un numero qualsiasi di gruppi, non solo di uno.
- L'eliminazione di un gruppo non comporta l'eliminazione di alcun utente o gruppo membro.
I gruppi possono contenere membri di qualsiasi account Cloud Identity o Google Workspace, nonché account consumer. Puoi utilizzare l'impostazione Non consentire l'accesso ai membri esterni alla tua organizzazione per limitare i membri agli account utente dello stesso account Cloud Identity o Google Workspace.
Identità esterne
Federando un account Cloud Identity o Google Workspace con un IdP esterno, puoi consentire ai dipendenti di utilizzare la loro identità e le loro credenziali esistenti per accedere ai servizi Google.
Al livello più elementare, la federazione prevede la configurazione del Single Sign-On tramite SAML, che collega le identità in Cloud Identity o Google Workspace alle identità gestite dall'IdP esterno. Per collegare un'identità come alice@example.com e abilitarla per il Single Sign-On a Google, devi soddisfare due prerequisiti:
- L'IdP esterno deve riconoscere l'identità
alice@example.come autorizzarne l'utilizzo per il Single Sign-On. - Il tuo account Cloud Identity o Google Workspace deve contenere un account utente che utilizza
alice@example.comcome identità. Questo account utente deve esistere prima del primo tentativo di Single Sign-On.
Anziché creare e gestire manualmente gli account utente in Cloud Identity o Google Workspace, puoi automatizzare il processo combinando il Single Sign-On basato su SAML con il provisioning automatico degli utenti. L'idea del provisioning automatico degli utenti è sincronizzare tutti o un sottoinsieme degli utenti e dei gruppi da una fonte autorevole esterna a Cloud Identity o Google Workspace.
A seconda dell'IdP che scegli, il Single Sign-On e il provisioning automatico degli utenti basato su SAML potrebbero essere gestiti dallo stesso componente software o richiedere componenti separati. Il modello di dominio distingue quindi tra un provider di identità SAML e una fonte autorevole esterna.
Provider di identità SAML esterno
L'IdP esterno è l'unico sistema per l'autenticazione e fornisce ai dipendenti un'esperienza Single Sign-On per tutte le applicazioni. Non è un provider di identità esterno a Google e pertanto viene definito provider di identità esterno.
Quando abiliti il Single Sign-On, Cloud Identity o Google Workspace inoltra le decisioni di autenticazione all'IdP SAML. In termini di SAML, Cloud Identity o Google Workspace agisce come fornitore di servizi che considera attendibile l'IdP SAML per verificare l'identità di un utente per suo conto.
Ogni account Cloud Identity o Google Workspace può fare riferimento a un solo IdP esterno. Più account Cloud Identity o Google Workspace possono fare riferimento a IdP SAML diversi, ma non è possibile avere un singolo account Cloud Identity o Google Workspace che utilizza più IdP SAML.
Gli IdP esterni comunemente utilizzati includono Active Directory Federation Services (ADFS), Azure AD, Okta o Ping Identity.
Fonte autorevole esterna
La fonte ufficiale delle identità è l'unico sistema che utilizzi per creare, gestire ed eliminare le identità per i tuoi dipendenti. Non fa parte di Google e pertanto viene indicata come una fonte autorevole esterna.
È possibile eseguire automaticamente il provisioning automatico di account utente e gruppi da una fonte autorevole esterna in Cloud Identity o Google Workspace. Il provisioning può essere gestito dalla fonte autorevole stessa o tramite il middleware di provisioning.
Affinché il provisioning automatico degli utenti sia efficace, gli utenti devono disporre di un'identità riconosciuta dall'IdP SAML. Se esegui la mappatura tra identità (ad esempio, se mappi l'identità alice@example.com in Cloud Identity o Google Workspace a u12345@corp.example.com nel tuo IdP SAML), sia l'IdP SAML sia il middleware di provisioning devono eseguire la stessa mappatura.
Account utente esterno
Si presume che i provider di identità esterni abbiano il concetto di account utente che tiene traccia di nome, attributi e configurazione.
La fonte autorevole (o il provisioning del middleware) deve eseguire il provisioning di tutti gli account utente esterni (o di un sottoinsieme di) in Cloud Identity o Google Workspace per facilitare l'accesso. In molti casi, è sufficiente propagare solo un sottoinsieme degli attributi dell'utente (ad esempio indirizzo email, nome e cognome) a Cloud Identity o Google Workspace, in modo da limitare la ridondanza dei dati.
Gruppo esterno
Se il tuo IdP esterno supporta la nozione di gruppo, puoi facoltativamente mappare questi gruppi a gruppi in Cloud Identity o Google Workspace.
La mappatura e il provisioning dei gruppi sono facoltativi e non sono obbligatori per il Single Sign-On, ma entrambi i passaggi possono essere utili se vuoi riutilizzare i gruppi esistenti per controllare l'accesso in Google Workspace o Google Cloud.
Google Cloud
Come altri servizi Google, Google Cloud si basa su Accedi con Google per autenticare gli utenti. Google Cloud, inoltre, si integra strettamente con Google Workspace e Cloud Identity per consentirti di gestire le risorse in modo efficiente.
Google Cloud introduce la nozione di nodi, cartelle e progetti dell'organizzazione. Queste entità vengono utilizzate principalmente per gestire l'accesso e la configurazione, quindi sono pertinenti solo tangenzialmente nel contesto della gestione delle identità. Tuttavia, Google Cloud include anche un tipo aggiuntivo di account utente: gli account di servizio. Gli account di servizio appartengono ai progetti e svolgono un ruolo fondamentale nella gestione delle identità.
Nodo organizzazione
Un'organizzazione è il nodo radice nella gerarchia delle risorse di Google Cloud e un container per progetti e cartelle. Le organizzazioni ti consentono di strutturare le risorse in modo gerarchico e sono fondamentali per gestirle in modo centralizzato ed efficiente.
Ogni organizzazione appartiene a un singolo account Cloud Identity o Google Workspace. Il nome dell'organizzazione deriva dal nome di dominio principale dell'account Cloud Identity o Google Workspace corrispondente.
cartella
Le cartelle sono nodi nella gerarchia delle risorse di Google Cloud e possono contenere progetti, altre cartelle o una combinazione di entrambi. Puoi utilizzare le cartelle per raggruppare le risorse che condividono criteri di Identity and Access Management (IAM) o criteri dell'organizzazione comuni. Questi criteri si applicano automaticamente a tutti i progetti nella cartella e vengono ereditati anche dalle cartelle figlio.
Le cartelle sono simili, ma non correlate, alle unità organizzative. Le unità organizzative ti aiutano a gestire gli utenti e ad applicare configurazioni o criteri comuni agli utenti, mentre le cartelle ti aiutano a gestire i progetti Google Cloud e ad applicare configurazioni o criteri comuni ai progetti.
progetto
Un progetto è un container per le risorse. I progetti svolgono un ruolo fondamentale per la gestione delle API, della fatturazione e dell'accesso alle risorse.
Nel contesto della gestione delle identità, i progetti sono pertinenti perché sono i container per gli account di servizio.
Account di servizio
Un account di servizio (o account di servizio Google Cloud) è un tipo speciale di account utente destinato a essere utilizzato da applicazioni e altri tipi di utenti delle macchine.
Ogni account di servizio appartiene a un progetto Google Cloud. Come nel caso degli account utente gestiti, gli amministratori possono controllare completamente il ciclo di vita e la configurazione di un account di servizio.
Anche gli account di servizio utilizzano un indirizzo email come identità, ma a differenza degli account utente gestiti, l'indirizzo email utilizza sempre un dominio di proprietà di Google come developer.gserviceaccount.com.
Gli account di servizio non fanno parte della federazione e inoltre non hanno una password. Su Google Cloud, utilizzi IAM per controllare l'autorizzazione di un account di servizio per una risorsa di computing, ad esempio una macchina virtuale (VM) o una Cloud Function, eliminando la necessità di gestire le credenziali. Al di fuori di Google Cloud, puoi utilizzare le chiavi degli account di servizio per consentire a un'applicazione di eseguire l'autenticazione utilizzando un account di servizio.
Account di servizio Kubernetes
Gli account di servizio Kubernetes sono un concetto di Kubernetes e sono pertinenti quando utilizzi Google Kubernetes Engine (GKE). Analogamente agli account di servizio Google Cloud, gli account di servizio Kubernetes sono concepiti per essere utilizzati dalle applicazioni, non dagli esseri umani.
Gli account di servizio Kubernetes possono essere utilizzati per l'autenticazione quando un'applicazione chiama l'API Kubernetes di un cluster Kubernetes, ma non possono essere usati al di fuori del cluster. Non sono riconosciuti dalle API di Google e non sostituiscono un account di servizio Google Cloud.
Quando esegui il deployment di un'applicazione come pod Kubernetes, puoi associare il pod a un account di servizio. Questa associazione consente all'applicazione di utilizzare l'API Kubernetes senza dover configurare o mantenere certificati o altre credenziali.
Con Workload Identity puoi collegare un account di servizio Kubernetes a un account di servizio Google Cloud. Questo link consente a un'applicazione anche di eseguire l'autenticazione nelle API di Google, senza dover gestire certificati o altre credenziali.
Passaggi successivi
- Consulta le nostre architetture di riferimento per la gestione delle identità.