Tutti i servizi Google, inclusi Google Cloud, Google Marketing Platform e Google Ads, si basano su Google Sign-In per autenticare gli utenti. Questo documento spiega il modello di dominio su cui si basa Google Sign-In per l'autenticazione e la gestione delle identità. Il modello di dominio ti aiuta a capire come funziona Google Sign-In in un contesto aziendale, come vengono gestite le identità e come puoi facilitare un'integrazione con un provider di identità (IdP) esterno. Il seguente diagramma mostra l'interazione tra queste entità.
Come mostra questo diagramma, al centro del modello c'è l'identità Google, utilizzata da Google Sign-In. L'identità Google è correlata a una serie di altre entità pertinenti nel contesto della gestione delle identità:
- Google per i consumatori contiene le entità pertinenti per l'utilizzo dei servizi Google come Gmail da parte dei consumatori.
- 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.
- Esterno contiene entità pertinenti se integri Google con un IdP esterno.
Le frecce piene nel diagramma indicano che le entità si riferiscono l'una all'altra o si contengono a vicenda. Al contrario, le frecce tratteggiate indicano 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 utilizzati in modo intercambiabile. Tuttavia, nel contesto della gestione delle identità, è utile distinguere tra i concetti:
Un'identità è un nome che identifica in modo univoco la persona che interagisce con un servizio Google. Google utilizza gli indirizzi email per questo scopo. L'indirizzo email di una persona è considerato la sua identità Google.
La procedura di verifica dell'associazione tra una persona e un'identità è chiamata autenticazione o accesso, in cui la persona deve dimostrare 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 come se avesse più identità.
Un account utente è una struttura di dati che tiene traccia di attributi, attività e configurazioni da applicare ogni volta che una determinata identità interagisce con un servizio Google. Gli account utente non vengono creati al volo, ma devono essere sottoposti al provisioning prima del primo accesso.
Gli account utente sono identificati da un ID non esposto esternamente. Pertanto, le interfacce utente o le API richiedono di fare riferimento all'account utente indirettamente tramite la sua identità associata, ad esempio
alice@gmail.com. Nonostante questa indirezione, tutti i dati e i dettagli di configurazione sono associati all'account utente, non all'identità.
Nella maggior parte dei casi, esiste una relazione uno a uno tra gli account utente e le identità, il che rende facile confonderli. Tuttavia, non è sempre così, come illustrano i seguenti casi limite:
La relazione tra account utente e 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 Bob (bob@example.com), Alice utilizzerebbe l'account utente precedente di Bob e Bob utilizzerebbe l'account utente precedente di Alice. Poiché i dati e la configurazione sono associati all'account utente e non all'identità, anche Alice ora utilizzerebbe la configurazione e i dati esistenti di Bob (e Bob utilizzerebbe la configurazione e i dati di Alice). La figura seguente mostra questa relazione.
In una configurazione non federata, dovresti anche reimpostare le password per consentire ad Alice e Bob di 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.
Il rapporto tra identità e utenti potrebbe non essere 1:1. Un account consumer può essere intenzionalmente associato a più identità, come nel seguente diagramma.
È 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 viene visualizzata una schermata di selezione dell'account utente da utilizzare.
Google distingue due tipi di account utente: account utente consumer e account utente gestiti. Le sezioni seguenti descrivono in dettaglio entrambi i tipi di account utente e le relative entità.
Google per i consumatori
Se possiedi un indirizzo email Gmail come alice@gmail.com, il tuo account Gmail è un account consumer. Allo stesso modo, se utilizzi il link Crea account
nella pagina di accesso di Google e durante la registrazione fornisci un indirizzo email
personalizzato di tua proprietà, ad esempio alice@example.com, l'account risultante è
anch'esso un account consumer.
Account consumer
Gli account consumer vengono creati in modalità 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 utilizzato dalla persona durante la registrazione diventa l'indirizzo email principale dell'account consumer e funge da identità. Questa persona può aggiungere indirizzi email all'account consumatore. Questi indirizzi email fungono da identità aggiuntive e possono essere utilizzati anche per l'accesso.
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, è consigliabile utilizzare account utente gestiti. Questi account sono chiamati gestiti perché il loro ciclo di vita e la loro configurazione possono essere controllati completamente 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 alla nozione di tenant.
Cloud Identity e Google Workspace condividono una piattaforma tecnica comune. Entrambi i prodotti utilizzano lo stesso insieme 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 considerati equivalenti.
Un account contiene gruppi e una o più unità organizzative.
Unità organizzativa
Un'unità organizzativa è un sottocontenitore per gli account utente che ti consente di segmentare gli account utente definiti nell'account Cloud Identity o Google Workspace in insiemi disgiunti per semplificarne la gestione.
Le unità organizzative sono organizzate in modo gerarchico. Ogni account Cloud Identity o Google Workspace ha un'unità organizzativa principale, sotto la quale puoi creare altre unità organizzative in base alle esigenze. Puoi anche nidificare le tue OU.
Cloud Identity e Google Workspace ti 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 dell'UO e vengono ereditate anche dalle UO secondarie. Pertanto, le unità organizzative svolgono un ruolo chiave nella gestione della configurazione di Cloud Identity e Google Workspace.
Un account utente non può appartenere a più di un'unità organizzativa, il che rende le unità organizzative diverse dai gruppi. Sebbene le unità organizzative siano utili per applicare la configurazione agli account utente, non sono destinate a essere utilizzate per la gestione dell'accesso. Per gestire l'accesso, ti consigliamo di utilizzare i gruppi.
Sebbene le UO assomiglino alle cartelle, le due entità hanno scopi diversi e non sono correlate tra loro.Google Cloud
Account utente gestito
Gli account utente gestiti funzionano in modo simile agli account utente consumer, ma possono essere controllati completamente dagli amministratori dell'account Cloud Identity o Google Workspace.
L'identità di un account utente gestito è definita dal suo indirizzo email principale.
L'indirizzo email principale deve utilizzare un dominio che corrisponda 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 in un'unità organizzativa e possono far parte di un numero qualsiasi di gruppi.
Gli account utente gestiti sono destinati all'utilizzo da parte di utenti umani anziché di utenti macchina. 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 macchina, Google Cloud fornisce service account. Gli account di servizio vengono trattati 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 controllo dell'accesso o la configurazione comuni 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 corrispondere a una casella di posta, a meno che
il gruppo non venga utilizzato come mailing list. L'autenticazione avviene comunque utilizzando l'email dell'utente anziché l'email del gruppo, quindi un utente non può accedere utilizzando un indirizzo email di gruppo.
Un gruppo può avere le seguenti entità come membri:
- Utenti (account utente gestiti o account consumer)
- Altri gruppi
- Account di servizio
A differenza di un'unità organizzativa, i gruppi non fungono da contenitore:
- Un utente o un gruppo può essere membro di un numero qualsiasi di gruppi, non solo di uno.
- L'eliminazione di un gruppo non comporta l'eliminazione di utenti o gruppi membri.
I gruppi possono contenere membri di qualsiasi account Cloud Identity o Google Workspace, nonché account consumer. Puoi utilizzare l'impostazione Non consentire membri esterni all'organizzazione per limitare i membri agli account utente dello stesso account Cloud Identity o Google Workspace.
Identità esterne
Se federi un account Cloud Identity o Google Workspace con un IdP esterno, puoi consentire ai dipendenti di utilizzare le proprie credenziali e identità esistenti per accedere ai servizi Google.
Al livello più elementare, la federazione comporta la
configurazione del Single Sign-On utilizzando SAML, che collega le identità in Cloud Identity o Google Workspace alle identità gestite dal tuo IdP esterno. Per collegare un'identità come
alice@example.com e abilitarla per il Single Sign-On a Google, devi soddisfare
due prerequisiti:
- Il tuo IdP esterno deve riconoscere l'identità
alice@example.come consentirne 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 accesso 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 è quella di sincronizzare tutti o un sottoinsieme di utenti e gruppi da un'origine autorevole esterna a Cloud Identity o Google Workspace.
A seconda dell'IdP scelto, il Single Sign-On basato su SAML e il provisioning automatico degli utenti potrebbero essere gestiti dallo stesso componente software o potrebbero richiedere componenti separati. Il modello di dominio distingue quindi tra un provider di identità SAML e un'origine autorevole esterna.
Provider di identità SAML esterno
L'IdP esterno è l'unico sistema di autenticazione e offre un'esperienza di Single Sign-On per i tuoi dipendenti che si estende a tutte le applicazioni. È esterno a Google e pertanto viene definito provider di identità esterno.
Quando configuri il Single Sign-On, Cloud Identity o Google Workspace inoltra le decisioni di autenticazione a un IdP SAML. In termini SAML, Cloud Identity o Google Workspace funge da service provider che si affida al provider di identità SAML per verificare l'identità di un utente per suo conto.
Gli IdP esterni più utilizzati includono Active Directory Federation Services (AD FS), Entra ID, Okta o Ping Identity.
Fonte autorevole esterna
L'origine autorevole delle identità è l'unico sistema che utilizzi per creare, gestire ed eliminare le identità dei tuoi dipendenti. È esterno a Google e pertanto viene definito fonte autorevole esterna.
Dalla fonte autorevole esterna, gli account utente e i gruppi possono essere sottoposti a provisioning automatico in Cloud Identity o Google Workspace. Il provisioning può essere gestito dalla stessa origine autorevole o tramite middleware di provisioning.
Affinché il provisioning automatico degli utenti sia efficace, gli utenti devono essere sottoposti al provisioning
con un'identità riconosciuta dal tuo IdP SAML. Se esegui la mappatura tra identità
(ad esempio, se esegui la mappatura dell'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 un account utente che tiene traccia del nome, degli attributi e della configurazione.
L'origine autorevole (o il middleware di provisioning) deve eseguire il provisioning di tutti (o di un sottoinsieme) gli account utente esterni in Cloud Identity o Google Workspace per facilitare l'esperienza di 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 per limitare la ridondanza dei dati.
Gruppo esterno
Se il tuo IdP esterno supporta il concetto di gruppo, puoi facoltativamente mappare questi gruppi a gruppi in Cloud Identity o Google Workspace.
La mappatura e il provisioning automatico dei gruppi sono facoltativi e non necessari 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 Google Sign-In 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 il concetto di nodi organizzativi, cartelle e progetti. Queste entità vengono utilizzate principalmente per gestire l'accesso e la configurazione, pertanto sono rilevanti solo in modo tangenziale nel contesto della gestione dell'identità. Tuttavia, Google Cloud include anche un tipo aggiuntivo di account utente: i service account. I service account appartengono ai progetti e svolgono un ruolo fondamentale nella gestione delle identità.
Nodo organizzazione
Un'organizzazione è il nodo radice della gerarchia di risorseGoogle Cloud e un contenitore 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 Google Cloud e possono contenere progetti, altre cartelle o una combinazione di entrambi. Utilizzi le cartelle per raggruppare le risorse che condividono criteri IAM (Identity and Access Management) o criteri dell'organizzazione comuni. Questi criteri vengono applicati automaticamente a tutti i progetti nella cartella e vengono ereditati anche dalle cartelle secondarie.
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 e ad applicare configurazioni o criteri comuni ai progetti. Google Cloud
Progetto
Un progetto è un contenitore per le risorse. I progetti svolgono un ruolo fondamentale nella gestione di API, fatturazione e accesso alle risorse.
Nel contesto della gestione delle identità, i progetti sono importanti perché sono i container per i service account.
Service account
Un service account (o Google Cloud service account) è un tipo speciale di account utente destinato a essere utilizzato da applicazioni e altri tipi di utenti macchina.
Ogni account di servizio appartiene a un Google Cloud progetto. Come nel caso degli account utente gestiti, gli amministratori possono controllare completamente il ciclo di vita e la configurazione di un service account.
Anche i service account utilizzano un indirizzo email come identità, ma a differenza degli account utente gestiti, l'indirizzo email utilizza sempre un dominio di proprietà di Google, ad esempio developer.gserviceaccount.com.
I service account non partecipano alla federazione e non hanno una password. Su Google Cloud, puoi utilizzare IAM per controllare l'autorizzazione di un account di servizio per una risorsa di calcolo come una macchina virtuale (VM) o una funzione Cloud Run, eliminando la necessità di gestire le credenziali. Al di fuori di Google Cloud, puoi utilizzare le chiavi del service account per consentire a un'applicazione di autenticarsi utilizzando un account di servizio.
Service account Kubernetes
Gli account di servizio Kubernetes sono un concetto di Kubernetes e sono pertinenti quando utilizzi Google Kubernetes Engine (GKE). Simili ai service account Google Cloud , gli account di servizio Kubernetes sono destinati a essere utilizzati dalle applicazioni, non dalle persone.
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 utilizzati al di fuori del cluster. Non sono riconosciuti da alcuna API Google e non sostituiscono un service account Google Cloud .
Quando esegui il deployment di un'applicazione come pod Kubernetes, puoi associare il pod a un service account. Questa associazione consente all'applicazione di utilizzare l'API Kubernetes senza dover configurare o gestire certificati o altre credenziali.
Utilizzando Workload Identity, puoi collegare un account di servizio Kubernetes a un service account Google Cloud . Questo link consente a un'applicazione di autenticarsi anche alle API di Google, sempre senza dover gestire certificati o altre credenziali.
Passaggi successivi
- Consulta le nostre architetture di riferimento per la gestione delle identità.